Skip to content

Latest commit

 

History

History
132 lines (106 loc) · 13.8 KB

README.md

File metadata and controls

132 lines (106 loc) · 13.8 KB
Raw

Long Range (LoRa) Radio Sensors for AKUINO

After connecting wired 17 sensors to a single AKUINO, we were convinced that wireless is very useful...

With the advent of LoRA transmission technology which ensures a really good indoor range, with the availability of ready to use modules like AdaFruit Feather M0 able to transmit data for years with simple batteries, we are convinced that a very performant solution can be created.

Hardware

Transmitters (working on batteries, collecting and transmitting sensors data, sleeping most of the time) are explained further here: https://github.com/AKUINO/RadioSensor/tree/master/transmitter

Receiver(s) (powered, collecting transmitted data, archiving it locally, transmitting on Internet, never sleeping) is explained further here: https://github.com/AKUINO/RadioSensor/tree/master/receiver

General design considerations:

Software

LoRa

Sensors

Each node can receive many kind of sensors and its firmware can be adapted for each situation: the USB programming port of the node can be used to either change the firmware or to access a terminal console and change parameters.

An important information is battery voltage: its value will always be read and transmitted (register 1).

I2C

I2C runs on 5V but also on 3.3V (not all sensors but most). Wires must be kept very short (20cm max, less is better).

The commands are different for each type of sensors: the bus cannot be really "auto discovered" like with 1-Wire (see below). The only possible thing is to associate I2C addresses with possible devices...

1-Wire

1-Wire ensures auto-configuration (devices can be "discovered" on the bus). Each 1-Wire device have a unique 64 bits address which can be auto-discovered by polling the 1-Wire bus (owdir on Linux, the equivalent will have to be programmed using libraries like https://www.pjrc.com/teensy/td_libs_OneWire.html ). The 8 first bits of this address indicates a generic device type which will have to be known by the firmware to adapt itself to the characteristics of each device type (e.g. number of values, polling protocol, parasitic powering...). The 8 last bits are a CRC8 checksum of the 7 previous bytes. It must be verified after each transmission (wire or radio) to ensure data integrity.

List of existing device types: http://owfs.org/index.php?page=family-code-list

The device types that we really need to support at first are:

  • 26 for the DS2438 Battery Monitor (used as an ADC for various types of sensors like RH, CO2...)
  • 28 for the DS18B20 Temperature Sensor; a library directly supporting this device seems to exist: https://github.com/milesburton/Arduino-Temperature-Control-Library This may be the best way to start supporting some sensors...
  • 01 for the DS1990 simulated by RFID badge reader

A central directory of 1-Wire devices will be kept locally but also in the Receiver (and in ELSA application).

Every minutes or 5 (or any delay set in configuration), the node will transmit the raw data (no scaling) read for the different sensors. The allocation table will be transmitted every hour (or delay set in configuration) or on request by the central node (after detection of a checksum mismatch with the allocation table).

Data will be processed by the sensor node to transmit only specific JSON data values like "temperature" and not all registers of the device.

Messages

  • Encryption: http://www.airspayce.com/mikem/arduino/RadioHead/classRHEncryptedDriver.html#details
  • Header with:
    • "FROM" (for sensors, the id of current node; for central node, id to distinguish the right central node)
      • encoded on one byte
    • "TO" (for sensors, id of their central node; for central node, 255 for broadcast or id of a specific node to be queried)
      • encoded on one byte
    • "ID", for a given "FROM"-"TO"-"FLAGS" combination, is a sequence ID of the message (overflow at 255): it allows the receiver to detect it has missed messages (and take action to correct this situation if needed).
    • "FLAGS" specifies the type of message: sensors data vs actuators (registers) setting; retransmission request (messages missed by receiver, the receiver signals which ID are missing); devices table to identify connected 1-Wire or I2C devices (from sensor node to central); relaying (MESH protocol, to be designed)
    • Sensors Data message: see below

Sensors Data Messages

There are many encoding formats (see bottom of https://github.com/AKUINO/JBCDIC/blob/master/README.md ).

Please look at our proposal, the project AKUINO/JBCDIC: https://github.com/AKUINO/JBCDIC !

Protocol

  • A potential source of inspiration: https://github.com/fredilarsen/ModuleInterface/blob/master/documentation/Protocol.md
  • A remote module (sensors) is sleeping most of the time (does not listen to radio) and awakens from time to time (around 3 minutes) to collect data and send it to the central module.
  • A central module is listening all the time and sends actuators settings (or retransmission requests) only just after receiving sensors data from a remote module.
  • The sender listen to the air and wait for silence (random delay) to avoid collision (this is done by the radio chip SX127x but needs to be configured. Looking at RadioHead library source code, it can be done: https://github.com/adafruit/RadioHead/blob/master/RH_RF95.h ). This is called LBT (Listen Before Talk).
  • The message is sent using RadioHead library (encrypted but no ACK required).
  • For remote module, the sender keeps listening for eventual input messages from the destination (actuators settings, sensors data retransmission requests) during a short period of time.
  • If a remote module notices that some actuators settings are missing, it requests their retransmission.
  • Sensor nodes send their 1-Wire / I2C Allocation table either periodically (about an hour), either when some connection changes is detected or whenever a request for it is received from the central node
  • Retransmission request: timestamp + pairs of bytes for each ID intervals ("begin ID"-"end ID") that needs to be (re)transmitted. Overflow may occur (increment of 255 is 0) and "end ID" can be lower than "begin ID".
  • Retransmission: message with exactly the same Header (TO, FROM, ID, FLAGS) and Payload than the one transmitted before

All nodes will be responsible to keep a buffer of the last messages (254 last messages for sensors and 254 last messages for actuators) they sent.

Redundancy of central module is possible: the two modules then share the same ID. A central module may not have received a package and therefore ask to retransmit a message well received by the other module: redundant transmissions are therefore discarded based on ID+timestamp.

Configuration

We will use a serial terminal (USB) to set the configuration parameters (ANSI character codes for colors). We have the necessary code in C++ for PIC32. The configuration will have to assign a key (0 to 31) to the physically connected ports:

  • Digital inputs: for a 1st version, we will statically map some GPIO as 0/1 ports
  • Analog inputs (12 bits): for a 1st version, we will statically map some ADC inputs including at least the battery level and 2 ADC lines
  • Digital outputs (PWM, pull-up, delays) to be SET (based on messages received from central): for a 1st version, we will statically map some PWM lines with basic local configuration attributes.
  • 1-Wire (multiple sensors: 1-Wire addresses AUTOMATICALLY mapped to different keys but a selection of registries may have to be done based on the device type. ABANDONED for now due to lack of 5V...)
  • Serial link (not for a 1st version except if a precise need arise)
  • Campbell SDI (not for a 1st version except if a precise need arise)
  • I2C device initialization command and register read: this is not well standardized but we will try to orthogonalize the possibilities. A basic polling cycle (e.g. 3 minutes) has to be set. Each key can be obtained either at each poll or at a configured multiple.

References