Simple Mesh Overview

Features

×

• 2.4 GHz 2 Mbps Mesh Network
  • tested with 300 packets / second
• Flash time automated database config
• Zero install time configuration
  • No association, No pairing, No factory resets
• Router = Coordinator = Repeater = Sniffer = CLI
• text serial line protocol
• Multiple Network endpoints
  • No single point of failure
• Server, Dongles, Sensors
  • Full Stack Open Source (no softdevices required)
  • HW On the shelves
  • optional DIY HW
• Alive trace routing
  • a heartbeat message that gives info about the age and RF tx/rx hops through the route

Description

• 2 Mbps (e.g. Zgibee is at 250 Kbps to have a higher range), lowering the bitrate does not improve the range enough to get rid of repeaters, and once you need repeaters these are continuous listeners and require permanent power anyway, so the strategy is to have a repeater for every slot of the house and those repeaters can have power amplifiers and the range problem is solved keeping the high bitrate feature.
• successfull stress tests including up to 300 packets / second.
• This nodes.json configuration file contains the short id for device unique identifier (uid64) and other configurations such as the channel, the sleep time, the required function,... Note that a python script using jLink API automate the flashing process as the uid is read every time from the attached device and matches the parameters to be flashed from the config file.
• As the short id (8 bits) is flashed, there is no association process required and all sensor devices can act as a pure beacons (no listening required) which considerably increases battery life time. We can keep arguing about the need of an acknowledged protocol for sensors logging, I do not think it is required as the feedback of battery level and rssi are both logged as well so the user knows if the sensor is in a healthy position or not.
• Router = Coordinator = Repeater = Sniffer = CLI : actually, a configuration activates the repeat functionality in case someone wants a completely stealth sniffer and this config does not require a different FW. There is nothing to coordinate as the mesh is fully dynamic with a flood and time to live concept. And every dongle has a CLI in text mode to report heard packets and takes commands as text input.
• A consequence of the simplified design allows to have multiple dongles in different locations listening to the network and reporting it to mqtt which avoids any single point of failure. By design there is no id 0 privileged coordinator and end devices do not require to know any particular associated address, they just wake up, broadcast and sleep.
• As visible in the gif animations below, Open Source SW is provided for all steps, devices firmware and server python code.

Static Demo

• UART : dongle firmware - directory
• USB : dongle firmware - directory

cu -l /dev/ttyACM0 -s 460800 

×

mosquitto_sub -t 'nrf/#' -v | ts

python3 nrf_mesh.py

×

×

Mesh Nodes

sensor tag

application/01_sensortag> make flash
application/01_sensortag> make paramw

×

• Status : deployed > 1 year
• nRF52832 module
• Temperature, Humidity, Pressure : BME280
• Light : MAX44009
• Smooth graphana logs with cyclic broadcast ~ 30 sec => battery life ~ 6 month on CR2032
• make paramw detects the device uid and writes the config parameters available in nodes.json

uart dongle

application/04_uart_dongle> make flash
application/04_uart_dongle> make paramw

×

• Status : deployed > 1 year
• buy : "nRF52832 BLE USB UART dongle"
• custom firmware and pogo-pins jtag adapter see below
• RF Mesh repeater + RF Mesh to Host interface
• make paramw detects the device uid and writes the config parameters available in nodes.json

usb dongle (nRF52840)

application/08_usb_dongle> make flash
application/08_usb_dongle> make paramw

×

• buy : "nRF52840 usb dongle"
• custom firmware for RF mesh
• RF Mesh repeater + RF Mesh to Host interface
• buffered USB CDC tx and rx
• make paramw detects the device uid and writes the config parameters available in nodes.json
• pogo-pins jtag adapter 3dprint :
  • Version two CAD Model
  • Version one Fusion360 CAD model

×

Protocol

• Sleepy nodes (low power) and router nodes (always listening)
• single layer ultra simple rpotocol. App into mac with unique ids to small ids mapping
• A simple alternative to the Bluetooth Mesh and Zigbee Thread IPV6

×

• Low power node : Mesh node that can be a sensor Tag that wakes up on RTC or on sensor value interrupt to log a parameter. Can also be a button that wakes up on a press PIO interrupt.
• Router node : Mesh node that cooperates with the Low power nodes, the router has to be a device that keeps listening permanently on the same RF channel, this might require ~ 13 mA. Example router devices are light controllers, server’s RF dongle or USB powered sensors and status devices.
• Server : A Raspberry pi running linux. The RF signals come through the serial port or with a USB adapter, then published on MQTT, from which Python scripts inject signals on the Database, connected to Grafana web server. Note that there can be multiple router dongles connected to servers.

Overview

Description

• 100% Open source Mesh RF Stack
• Ported on STM8L, STM32, nRF51 and nRF52
• Concept designed for Low Power Nodes and Router Nodes
• Same radio channel configured for the whole network
• Single channel allows maximum power save with unlimited sleep periods, and random wake up with button press or sensor event.
• Mesh with flooding broadcast, where every message has its own configurable time to live. This brings multiple advantages of usage simplicity.
• Short addresses allow efficient packets sizes. Possibility for extensions with short address reuse and exception addresses to allow unlimited network size.
• For simplicity purpose, security is a matter of application payload content.
• The stack is so small that the RAM and ROM are left for the application logic, not requiring a network co-processor.

Mesh Broadcast

• A simple flood mechanism is implemented where every router repeats the signal heard decrementing the time to live to avoid infinite propagation.
• Future extensions can extend the routing by gathering statistics and deciding of the optimal path in a decentralized fashion. Note that small installations in a home do not bring any significant advantage, thus the interest for a simple protocol for such use case.

Directed messages with ack

• This type of communication uses a source and destination addresses
• Only the node recognizing itself as destination will send a packet as acknowledge
• The acknowledge packet is propagated the same way, until it reaches the source, which make it an end to end acknowledge
• If the source did not got an acknowledge back while it was requested, it can retry the transmission again.

Packet Format

×

×

• control: bit 7 defines whether a packet is to be broadcasted or has a target destination. Bits 6 and 5 allow safe communication with acknowledge, and a request response type. That allows the sw stack to handle the acknowledge and re-transmission. bit 3 allows streaming of messages without acknowledge.
• pid: is defining the application function which maps to a particular payload serialization
• Source and dest: are the Node Id, and are unique within every mesh. Although 8 bits, exceptions allow further reserved sizes.
• Time to live : used by the routers to know when to drop the packet.

Alive trace routing

×

• All Nodes including the low power, send a periodic “alive” packet
• The initiator includes a counter that informs about the live cycle count
• Every retransmission appends information about
  • Received RSSI (Radio Signal Strength Indicator)
  • The Node Id of the Router performing the re transmission
  • Transmission power with which the packet has been re transmitted

×

• The “alive” packet that reaches the server’s dongle has the full route information
• Multiple paths can reach the server for the same original broadcast
• A single “alive” packet can provide link status of the complete mesh netwrok
• The signal route information is packed in a json structure
• json structures are broadcasted on the jNodes topics path

Mesh Stack

Tools

./nRF5_SDK_15.0.0_prf/

    git submodule update --init

./tools/

• switch power on and off using a Segger jlink
• read and write parameters matching the device's unique identifier read from the HW registers

installation

• For the Raspberry pi tools and scripts see full installation steps in the Installation website page
• For the nRF52 firmare :
  • GNU Tools ARM Embedded version 6 2017-q2-update, referenced from the SDK Makefile.windows
  • Python jlink wrapper. Used in Makefile and tools of this repo, more on pylink.readthedocs. Note that it has to be used with a 32 bit python version referenced in the tools scripts as C:\Python27\python.exe. wrapper scripts already availabe in the tools directory

Details about the nRF52 Frimware environment

×

• nodes.json is provided locally in this repo and the docker command nodes-server.sh can also serve it at http://hostname:8080/nodes.json

×

Configuration

sdk config tool

×

Automated mesh devices configuration

simple board switch

USED_BOARD := BOARD_NRF52_SENSOR_TAG

PPI automation

Raspi Host Controller Interface

HCI MQTT Test vector

Commands

mosquitto_pub -t 'cmd/request/get_node_id' -m ''

cmd/response/get_node_id {"cmd": "get_node_id", "node_id": "73"}

mosquitto_pub -t 'cmd/request/get_channel' -m ''

cmd/response/get_channel {"cmd": "get_channel", "channel": "2"}

Remote Commands

mosquitto_pub -t 'remote_cmd/request/set_channel' -m '{"channel":2,"remote":74}'

remote_cmd/response/set_channel {"pid": "236", "ctrl": "0x02", "src": "74", "dest": "73", "cmd": "set_channel", "set": "2", "get": "2"}

Actions

mosquitto_pub -t 'Nodes/79/ping' -m '{"remote":"74"}'

Nodes/79/ack 1

Other nRF52 Applications

cd ./applications/

02 acell tag

application/02_accell_tag> make flash

×

• Status : experimental, low battery life
• nRF52832 module
• MPU-6050 module
• interrupt pio from MPU-6050

03 buttons

application/03_buttons> make flash

×

• Status : experiemntal, low battery life
• nRF52832 module
• x6 buttons

05 rotary decoder

application/05_rotary_decoder> make flash

×

• buy : "600 pulses Optical Rotary encoder"
• custom wiring +5V, encoder pullups to +3.3 V
• rf timestamp synchronisation
• HW capture of timestamp
• RF Mesh log of modulo 600 position with timestamp
• 4 ms status on change, otherwise 4 s reminder

06 bldc 52832

application/06_bldc_52832> make flash

×

• Status : RF magnetic angle control OK, rest is in development
• nRF52832 sensor tag board used
• buy : "L6234d breakout"
• custom wiring power supply 9.6 V / nRF powered with 3.3 V separately
• RF bldc control : magnetic angle, voltage ratio, speed, absolute angle

07 bldc 52840

application/07_usb_dongle> make flash

×

• Status : preparation
• previous application "03 bldc 52832" ported to the nRF52840-dongle

FAQ - Discussion