Very Low Power Mesh

[kiwironnie]

What I'm looking for here is a library for a very low power mesh network layered over enhanced shockburst.

My personal interest is to support a network of farm monitoring sensors in hilly countryside, where a star net wouldn't work too well.

Ideally it would be a self-healing mesh with all nodes equal, i.e. no need for master nodes, or special router nodes. To keep power low (very small, inexpensive solar power panel plus battery) it would also need to support time synchronisation so that nodes could sleep until its time to exchange data.

There seem to be some expensive products around that do something similar (e.g. dust) but nothing open source or cheap, particularly that can take advantage of the heavy lifting already done by enhanced shockburst! Ideas, suggestions would be appreciated.

[brennen]

It could certainly be done, but it would certainly take quite a bit of effort. At some point, I'll probably venture out and write a mesh library that supports the 24L01, but I haven't had the need to do one just yet. Probably the hardest parts of the project would be getting the protocol together such that you could build a routing table and how to handle dropped packets (especially if they have to pass through one or more central nodes). Enhanced Shockburst will tell you if a packet got from point A to point B, but if you're going from A to B to C to D to ..., it's only of so much use, so you'd have to build more protocol in code to detect at what point the link broke.

Throwing in sleeping makes the protocol even more difficult, since you now need some type of clock or timer that can wake up the microcontroller. You would want to try to find a microcontroller that doesn't have to have the CPU section turned on to run the timers (and be able to set the timers to wake the microcontroller from sleep). For instance, the nRF24LE1 can do this in memory retention mode, timers on, with a current consumption of 1.6 uA.

[kiwironnie]

Thanks Brennen. Clearly quite a project, which I'm also interested in tackling, maybe, as yet another night job! Relatively doable for lower speed, bursts of data. The problem of dropping packets across the mesh might be handled by a combination of shifting responsibility for delivery to the next node (reliability handled by enhanced shockburst) and end-to-end acknowledgment. The synchronisation requirement is a fascinating one. The wake-up without CPU that you describe is of course also handled by many PIC micros that incorporate a CPU independent, low power oscillator designed to wake-up the micro. A colleague of mine used a small battery powered PIC to wake-up a digital camera at regular intervals to do time sequence photography over many months. A worthwhile challenge would be to sync all nodes without a central time controller, i.e. develop a 'time consensus' protocol. To support greater distances 24L01 boards with radio amplification would be useful.
There's certainly lots of opportunities here in NZ for a capability to deploy cheap sensors in the rugged countryside!

Further detailed thought. The 24L01 doesn't seem to have a broadcast address or mode by the look. This will be essential for the discovery phase of a mesh. Broadcast might be emulated by setting pipe 0 to have an address common to all nodes when its not being used for receiving enhanced shockburst acks, with Pipe 1 being used for reliable data. Broadcasts would be sent in shockburst (rather than enhanced shockburst) to this common address.

[brennen]

One of these days I'm going to come visit New Zealand. It looks quite beautiful in pictures to this Yank.

The problem of dropping packets across the mesh might be handled by a combination of shifting responsibility for delivery to the next node (reliability handled by enhanced shockburst) and end-to-end acknowledgment.

I think you are exactly right with this. I would say this part of the protocol would be one of the hardest things to get working because it can change at any time and you have to stay on top of it constantly.

A worthwhile challenge would be to sync all nodes without a central time controller, i.e. develop a 'time consensus' protocol.

That may be a harder thing to do if you're not using a precision time source, such as an RC oscillator. However, given that RC oscillators typically can run independent of the main CPU, whereas main crystals often do not (or at least at a higher power consumption), you should still be able to come out ahead with the power savings while sleeping. The RC oscillator version would likely have to stay awake longer because the higher tolerance of RC oscillators over the net would make the nodes have a higher distribution of actual time in standby.

To support greater distances 24L01 boards with radio amplification would be useful. There's certainly lots of opportunities here in NZ for a capability to deploy cheap sensors in the rugged countryside!

This may or may not be necessary. You could likely use directional Yagi antennae with higher gain and possibly not even need an amplifier. RF amplifiers are also typically very inefficient, usually less than 50%. This will be a major current draw and will likely drain the battery much faster. However, if you can use solar panels in conjunction with batteries, then you could likely sustain this much easier. Plus you wouldn't have to go all over the countryside to change batteries all the time.

Further detailed thought. The 24L01 doesn't seem to have a broadcast address or mode by the look. This will be essential for the discovery phase of a mesh. Broadcast might be emulated by setting pipe 0 to have an address common to all nodes when its not being used for receiving enhanced shockburst acks, with Pipe 1 being used for reliable data. Broadcasts would be sent in shockburst (rather than enhanced shockburst) to this common address.

You are correct that there is no functionality in the 24L01 that inherently gives you a broadcast address. This would be easy enough to set up in your protocol though, as you would assign an address that is a broadcast, and likely set a certain pipe to use that address. Broadcasts would indeed not be useful to send in Enhanced Shockburst, for obvious reasons. That is simple enough, as you can turn of Enhanced Shockburst on a pipe-by-pipe basis.

[kiwironnie]

As you say Brennen, New Zealand is a beautiful and exciting place to visit if you like outdoor pursuits of any kind, and yanks are always very much welcome.

The clocks could re-sync on each wake-up cycle, to avoid them having to be particularly precise. A second or two wouldn't matter if the wake-up time slot assumed that degree of inaccuracy.

Yagis excellent for range of course and for avoiding interference, and would work well for isolated nodes on the edge of a mesh. The rest are going to need omnis or possibly sector antenna, with reliable transceiver comms over several hundred metres to be of use on a farm without a costly number of nodes. No problem to provide a small solar panel to keep the battery charged. These are very cheap from China, although quality variable.

Will keep you posted with any progress on this 'project' but unlikely to be for a while. Cheers.

[brennen]

So it's been quite a while, but I've actually gotten a fairly simple embedded mesh network up and working with the nRF24LE1. The one requirement of yours is that it's currently not set up to sleep, so power consumption would probably be pretty ugly. That's something I'll probably start looking into at some point.

The theory behind it is that a network can have up to 255 nodes (one address is reserved as a broadcast). All nodes are set up with the same hardware address, which allows them to receive packets addressed to them or anybody else. Each node keeps a routing table with two dimensions: one keeps the next hop address for a particular recipient address, as well as the number of hops to that particular recipient. Any time a node receives a packet, it tries to update the routing table if the calculated route would be shorter or as short as the current route.

To set up the network, the device powers up with an "attach" message to allow other nodes to know it exists. Any node that hears this message also responds with an attach message, and so forth. Each message has a maximum relay count field in the packet header, similar to TCP/IP, such that it gets decremented each time it is received, which helps from flooding the network with packet relays. A node can also send a "get hop count" message to the network to get routing information to a particular node, and nodes that receive this message respond with a "cur hop count" message with their current routing information to the requested node. These messages are all handled behind-the-scenes and are transparent to the user.

There is currently the provision for a "data" message that is accessible to the user. Up to 24 bytes of user data can be sent per-packet (8 bytes are overhead). Also, a function callback can be provided to the mesh code that allows the mesh to alert the user when it has received a data message, so that the user can process the received data.

If you'd have any interest in peeking at the code, let me know.

[kiwironnie]

Wow, I just tuned in again after all this time and saw your message (didn't get an automatic e-mail, never mind). Looks like a brilliant piece of work. I've been off mucking around with ARM technology and 6LoWPAN but was considering getting back to working on an ANT based mesh to avoid the unnecessary (for my applications) bloat! If you still have it available Brennen, yes please I would be very interested in your code. Its been so long though that I'll have to kick start the old brain into remembering how the addressing etc works! Cheers Ron

[brennen]

I've uploaded two different versions: one with no packet acknowledgement (http://www.diyembedded.com/files/nrf24le1_mesh_working_no_ack.zip) and with packet acknowledgement (http://www.diyembedded.com/files/nrf24le1_mesh_working_with_ack_and_retries.zip). The one without packet ack is considerably simpler, but it isn't as robust in getting packets through. I will admit that it doesn't always work 100% for getting packets through, but it's at least a start. There's also no support for sleep mode yet, so battery drain is going to be fairly quick without it.

[kiwironnie]

Thanks for getting back so quickly with your mesh source Brennen, which I've now downloaded. Will take a look as soon as there's time enough to do it justice. I really like the stepwise development approach that you always seem to take of starting simple and building up complexity.

I'm looking at resurrecting an ANT based mesh project which had to be put on the back burner. This could undoubtedly build on some of the mesh work that you've already done. A major advantage of the ANT chips for mesh is of course that they support neighbourhood discovery via broadcast. Another key advantage is that they have a measure of security for more serious applications. Some hardware development will be needed to produce a module that includes a radio power amplifier to get more range at the expense of power consumption, obviously a departure from ANT's short range marketing strategy. I have the Nordic reference design for the nRF24L01 which has exactly the same output stage as the nRF24AP2 series and which I've been assured by Nordic will work with the ANT chip. The emergence of the new ARM based nRF51 should make such work even more worthwhile. Best wishes, Ron.

[kiwironnie]

A quick look through your code, as usual looks straightforward and logical.
After just doing some further research into ANT it appears that I may have previously led myself into a misconception that the media access layer hardware design has a specific broadcast mode. As you've remarked yourself the Nordic documentation isn't always the clearest or most comprehensive. Still really no excuse! The main evidence is that the AT3 ANT module from Dynastream Innovations, is based on a Texas MSP430 microcontroller containing the ANT stack with an nRF24L01+ for the radio!! Consequently the 8 channels, broadcast capability and other ANT features, described in Nordic's 'ANT Message Protocol and Usage' document must be built into the higher levels of the comms stack. Though I'm unclear how security is achieved, which usually requires a hardware based crypto co-processor. So it appears that broadcast must be based on something similar to your approach, and there may be no hardware advantage at all in using the ANT chips in a mesh network, over the nRF24L01+! In which case your mesh software development is entirely relevant from my perspective and worth progressing further. So I shall think about how best to implement sleep functionality.