Edit: We have decided to open source this project, and we hope that it may be useful to some of you. In particular, for those of you using custom protocols or that require low latency.
We're working on our own wireless mesh network implementation for research purposes, and we're seeing significantly lower latency and higher reliability than Bluetooth Mesh. We're using the BLE 2M PHY on the nrf5340.
We're considering making the project open source, and we want to gauge interest in the community.
This plot shows the CCDF of the latency associated with sending a 1-byte packet between two nodes, i.e., the value on the y-axis is the probability of the latency exceeding the corresponding value on the x-axis. We measure latency over a wired coaxial connection. For Bluetooth Mesh, we see a ~3% probability of packet loss on the first transmission, which causes the jump in latency to over 20ms (the default packet retransmission timeout). For our mesh node, we did not see any packet loss during a test with 10 000 packets sent.
What's the tradeoff against the standard BLE Mesh? and other comparable meshes (eg, Thread, Zigbee)?
In particular, power consumption?
I would expect the scanner to be near always ON similar to the Bluetooth mesh looking at the numbers shared. However it could be interesting to add this "new mesh" as a different PHY so the upper application layers of the mesh can be leveraged with the newer PHY.
Would this work on the nRF52 as well ?
Bluetooth Mesh utilizes the advertising packets of the existing Bluetooth stack, which has been designed without necessarily having mesh applications in mind. This is especially apparent when looking at latency, as there is a minimum 20ms interval between re-transmissions should a packet be lost. The delay between each transmitted packet is also a severe limitation, especially when considering the small packet size (8-10 bytes). Of course the big advantage of using the Bluetooth stack is how ubiquitous it is.
I expect power consumption to be similar, but we don't have data on that yet.
We wanted to create a mesh network without any static routing and without coordinating nodes, which is why Thread and Zigbee are not very comparable technologies. In very dynamic environments (e.g. vechicle-to-vechicle), Thread and Zigbee's routing does not work. We have made some latency measurements of Thread, and while the tail latency is much better than Bluetooth mesh, the average is quite similar. The PHY used by Thread and Zigbee might be more power efficient than 2M BLE, but our stack is easily adaptable to another PHY.
Yes, so far we are in receive mode as long as we're not transmitting. I don't think PHY is the right term here. We use existing PHYs to transmit over the radio. Not exactly sure what you mean, but I don't think using an existing mesh stack with this as a lower layer would provide much advantage, the idea is to let the application use this mesh network directly.
We have designed it for the nRF53 with the mesh network stack on the network core and application specific code on the application core. However the mesh stack should be quite straight forward to port to nRF52, the only difference is you would have to run your application code on the same core.
We have decided to open source this project, and we hope that it may be useful to some of you. In particular, for those of you using custom protocols or that require low latency.