One of these days I'm going to come visit New Zealand. It looks quite beautiful in pictures to this Yank.
kiwironnie wrote: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.
kiwironnie wrote: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.
kiwironnie wrote: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.
kiwironnie wrote: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.