nRF5 Custom Mesh Network

A simpler, more efficient alternative to Z-x, BL-x, Thread, standard RF protocols

Public Chat
Similar projects worth following
We all love standards because they make our devices compatible with each other. What if an open source custom mesh could offer a much simpler alternative ?
Every standard has a must to support all possible features which grows its complexity.
This custom mesh network implementation fills the gap of the entry level complexity which amazingly results in way higher performance.
Open source SW is provided for off the shelf nRF SoC tags and dongles. An example of DIY sensor tag SW/HW is also provided.
So what's the catch ? An automated database per id flash time configuration spares all the association burden to the user.
At MQTT level, a similar interface is provided which is similar to others such as zigbee2mqtt.

nRF5 projects have now their own section on a dedicated Home Automation website :

If you would like to get support, give feedback or discuss new ideas related to this project ?

It's possible to directly discuss on the forum

  • 2 Mbps (e.g. Zgibee is at 250 Kbps to have a higher range), 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 with a high bitrate.
  • stress tests including up to 300 packets / second were successfull.
  • This 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.

Just plug a dongle and watch the serial port

cu -l /dev/ttyACM0 -s 460800 

Then start a python service to turn serial to mqtt

Link to the python script

python3 py/nrf_mesh/
mosquitto_sub -t 'nrf/#' -v | ts

more details about the protocol on the Home Smart Mesh Website Protocol page

Home Smart Mesh with comprehensible structure, menu for different boards, mesh concept,...

Repeater and Command Line Interface : nRF52840 usb dongle

  • Nordic has release a cheap usb dongle. This board does not have a serial to usb converter, rather the physical usb of the nRF52840 chip. A firmware is provided to offer a high performance interface. I must admit that it was not easy due to all required ring buffers and interrupt management.
  • This dongle is multi purpose and is also used in other projects with "OpenThread" as a protocolas example #Self standing balancing robot. But the custom protocol is simpler and has a millisecond scale efficiency.

DIY nRF52 Sensor Tag

Why am I doing a custom HW ? When I started this there were no Aqara sensors on the market. The aqara weather do not measure ambient light, the motion sensor does but with unpractical sampling rate and resolution. The nRF51802 is an 8€ tag that can sense temperature and ambient light, and the aqara the humidity and pressure which for my use case do not require a high sampling rate. So this nRF52 is more as a platform to plug in any new sensor but is an optional chain in the...

Read more »

  • nrf mesh to mqtt with tracing main steps

    Wassim10/04/2019 at 20:04 0 comments

    Serial output from the usb dongle

    Dongle Firmware

    cu can be used to check the output. Hint, stop serial with "~." 

    cu -l /dev/ttyACM0 -s 460800 

    Then start a python service to translate the serial to mqtt

    Python script
    python3 py/nrf_mesh/
    mosquitto_sub -t 'nrf/#' -v | ts

    The "| ts"  is a pipe that adds timestamp

    subscribing to the mqtt topic would then show an output format inspired from zigbee2mqtt that allows to mix the custom nrf devices into the rest of the automation chain

    used sensors

    nRF52 DIY Sensor Tag
    nRF51 sesnor tag

    more details about the RF and serial protocol in

  • Aqara and Eurotronics hand in hand to save energy

    Wassim09/14/2019 at 10:44 0 comments

    and make life more convenient for users. In this home automation section, aqara window contact sensors are used to send a window open alert to the Eurotronic thermostat, once the alert is disabled, the thermostat resumes the previously set temperature.

    The Spriit (google "eurotronic thermostat zigbee" ) has the spirit of devices compatibility introducing a zigbee product, which support is added by the zigbee2mqtt community.

    In this code section below, multiple windows contacts ("apertures") are aggregated and a notification is sent when the state changes, the full code is available here.

    Down below, the "friendly names" used to filter the mqtt traffic coming from "zig/friendly name". Note that the code does mention sensor names and not ids, thus a better readability.

    As conclusion, it is very challenging to program such an aggregation function using graphical tools such as nodered or any other high level automation language. Python is at the same time simple and powerful to allow such configurations.

  • nRF dongle brought to life with a pogo-pin adapter

    Wassim05/15/2018 at 21:23 0 comments

    The pogo-pin adapter is successful

    The used pogo-pins, not ideal, very thin, but all I got at the moment, can't wait.

    during the testing all possible mistakes were obviously performed :

    • SWDIO and SWDCLK have been inverted, the nrfjprog got thus an error, had to swap them to make it work
    • Tx and Rx pin were confused between sender and receiver, so first attempt was silent
    • At least the RF worked since the first attempt

    Photos of the scene

    Lack of helping hands and preliminary design not possible to put a holder on top or clip it to the DUT, anyway, at least the pogo-pins are matching.

    It was very hard to get tiny holes on the 3d print, I had to set them much bigger around 1.3 mm diameter to get something where the 065 mm could pass, but not adjusted so had to set some glue.

    Two first attempt failed because of holes diameter, then I abandoned the idea of having a ceiling holding the pins, after all some glue did the trick.

    This nRF52 board will become the official dongle for the nRF52 Mesh project, given its cost and compacity, it makes it an ideal candidate.

    I also figured out before flashing my own application that it had a bootloader, so I should probably start testing and using the serial bootloader to avoid mounting and dismounting every time. As this is already a serial USB adapter this concept fits perfectly.

View all 3 project logs

Enjoy this project?



hugo.burm wrote 09/14/2019 at 12:38 point

There is some overlap in the things you are doing and the experiments I did. See write-up below. I had to spent some time in getting the MQTT-SN protocol working with a MQTT broker (registering topics etc.) using the Nordic examples. Let me know if you encounter the same kind of problems.

I have OpenThread running on a few nRF52840 nodes (Nordic DK, Nordic Dongle, MakerDiary dongle).
I have a Raspberry PI with the OpenThread Border Router runing the Paho MQTT-SN -> MQTT gateway.  
This gateway is talking to another RaspBerry PI running Home-Assitant and a MQTT (Mosquitto) broker.
On the nRF52840 DK, I implemented part of the MySensors protocol. It is using the MQTT-SN protocol for communication. I am using it with a BME280 sensor. I used the Segger IDE for this (free license for nRF52840 hardware). The Nordic nRF52840 DK in combination with Segger IDE is very much needed if you want to debug your code (or repair your bricked dongle :-)).
On the Home Assistant, I installed the MySensors MQTT gateway. Actually, the whole thing is working (Temperature/Pressure/Humidity available in Home Assistant). But it is just a POC with not even alpha quality code (My C knowledge about malloc/free is a bit rusty after 15 years of Java/C#).

  Are you sure? yes | no

Wassim wrote 10/04/2019 at 19:53 point

Absolutely, you apparently managed to do all what I planned to do in direction openThread and nRF52840.

To be honest I left that on the side and focused on taking advantage of the network in applicative level. Zigbee2mqtt has had a major impact on my projects, I just adopted it. I tend to favor ready HW over my custom one as long as the cost is reasonable.

I'll keep working on the OpenThread anyway from time to time, so if you have any openSource or github project examples, that'd be awesome, otherwise already some advises and recommendations are welcome.

I also focused on performance and ported my custom mesh dongle to the nRF52840 usb and used the usb CDC device, it was not that easy to get things running by solving race conditions and adding ring buffers where necessary.

I also feel it's fun challenge to compare a custom protocol to Thread, which is an unfair comparision, but the custom has an amazing simplicity (no joining process) on the cost of custom flashing every short id in every device.

Now I have both networks deployed in parallel see my last entry on

  Are you sure? yes | no

Tim Kerby wrote 08/07/2018 at 23:24 point

Did you get a boot loader compiled for this dongle? I’ve been trying to get the Nordic secure boot loader up and running without much success in buttonless mode

  Are you sure? yes | no

Wassim wrote 01/05/2019 at 10:11 point

Hi @Tim Kerby , sorry for late reply, the notification was not clear.

Same as you, I spent some efforts on the the example of the bootloader:


I followed all steps but did not succeed. It is a pain to open the small usb dongle every time, so I kept it for deployed projects only and develop using another pcb that is open.

Things evolved since, and now the official nRF52840 is available with functional bootloader, so I would recommend it for new projects. I will be porting my custom RF on it. It would be great if I manage to build a bootloader with a custom transmort using my custom RF for it, but given the alternative of using pogo pin adapters, the investment of custom BL is a bit scary.

I'm currently very active on different nRF applications

so let me know if you'd like to collaborate on any particular one.

  Are you sure? yes | no

electrobob wrote 06/24/2018 at 12:22 point

That chipset looks pretty cool, a nice way to integrate sensors into small products.

In which conditions do you reach the 25 µA power consumption?

  Are you sure? yes | no

Wassim wrote 06/24/2018 at 15:22 point

Thanks @electrobob , well 25 uA is an honest measure of the currently deployed firmware sleeping to be awaken with RTC, with the nRF52 module, BME280 and MAX44009 modules unmodified. Also not sure if the BME code can be optimised, and there is potential to do a lot better for the nRF52, as the datasheet mentions 1.9 uA with RTC and RAM retention is less than that. The tx time is neglected as hundreds of microseconds every 20 sec. But I still have to work on the full power profile, also going up to +4 dB. I'll do that with a scope and serial reistor. But let's say that power optimisation is not the priority because I'm logging continuously the battery voltage and it looks good so far, around 0.1 V drop in about a month, you can view here a snapshot I exported from my grafana :

  Are you sure? yes | no

electrobob wrote 06/24/2018 at 15:46 point

Indeed, both sensors should be well below 1µA each, but better check the extra components added and what is happening in the SoC. I think you should be able to keep sleep below 5µA and another 5µA for the data transmission, going for 2-3 years from a CR2032. 

  Are you sure? yes | no

Wassim wrote 06/24/2018 at 18:28 point

Yeah 2-3 years that's a nice target usually reached with the nRF52, the CR2477 would be for a timely waking up listener or more extensive communication.

For my router nodes, there's no chance running them on batteries, as I allow the low power devices to sleep as long as they want, so the routers have to be listening full time ~ 10 mA. Low power and real time mesh is a real challenge, so now I stick with Home application where every corner is allowed a USB power supply for the surrounding low power nodes.

  Are you sure? yes | no

electrobob wrote 06/26/2018 at 11:55 point

Since you are talking about router nodes, what is the maximum range you have?

  Are you sure? yes | no

Wassim wrote 06/26/2018 at 16:44 point

I have two types of routers that can operate on the same mesh, one for long distances from my previous project #Home Smart Mesh  based on an STM32 and an nRF24 + PA + LNA, The metal shielded ones seen on the picture promise 2KM, I only tested them indoors and they could still send (1 msg out of 100) through x4 floors, I have no good unit for measure but e.g. 80% of messages through 2 ~ 3 walls.

The second type I stick with in this project is a much less powerful repeater (+4dB default nRF52 usb dongle), in favor of a much better design integration, inside a wall usb socket you would barely notice them. Another advantage is the RSSI only available since the nRF51 / nRF52 series, and I'd like to base the concept of this mesh on top of that, where every ~ 60 sec, every low power node sends one alive message, which acts like a trace-route, with every router appending the RSSI and tx power to the packet, the server thus can fully diagnose the mesh permanently from all redundantly received routes, also working on a webgl 3d viewer (preliminary version already shared on github) we'll see how that'll end up.

I have found some nRF51 + PA + LNA modules, I'm tempted to use them as another variation, but at the beginning I try to minimize the variations and get them better working first.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates