RF12Mesh library

This is the project page for the RF12 driver library I've been working on for a small research project at Utrecht University. I will add my ideas, problems and experiences with the driver here, and intend to upload the code to the JeeLabs repository, if jcw considers the project to be a worthy addition to the site. When using the driver, have a look at the User Manual first, and keep in mind that this is all very new, unproven and in some areas unfinished stuff... (hence all the TODO's in the code and the ideas below)

Enjoy!

Joost

These are the digitized versions of some of the notes i've written in the past two months, regarding the project. When writing down or drawing ideas, pen&paper is still the way to go in my opinion...

General

So the driver is very autonomous. It is vital that received messages are handled by the sketch, because if the buffer is fill receptions are lost. Routing messages will in this case continue, though.

Thoughts A possibility I had in mind when developing, is that the driver could support two different modes of operation. One Mesh mode where every node is equivalent, and one Sensor Network mode where there is one master and the others only send data to that master.

In the second case, the master is externally powered and could provide the network with a clock signal. The master can signal the sensors to power down for a predefined period of time. The master could also be the only node that calculates routing. It could send data to the other nodes containing the information they need, built by an initial broadcasting sequence (so all the nodes can report the neighboring nodes they detected to the master). That information is essentially the next hop for every respective node. No routing table is needed for every node.

This second mode is a completely different scheme, would take about as much time to create as with the Mesh driver. I've written a simple protocol using this technique, its in my notes. This possibility will not be discussed further in this setion.

Idea: when receiving a message, immediately check the header to see if the message is addressed to us. Otherwise, check the message length and sleep for as long as it takes to send a message of that length. Another idea that would improve the mesh's characteristics, is to check if the sender's routing table entry is consistent (i.e. has 1 hop).

The lhop header isn't really used apart from this just-mentioned possibility of route checking. It could also be removed.

I wonder if the system should include a watchdog timer. if things go wrong and the system locks up, reset the node. the WDT could also be used to provide a deep sleep functionality, but in order to get that to work we would need to get a synchronizing (clock) signal through the network. But, because every node is essentially equivalent, which node should provide that signal and how would we propagate it through the network without every Node clogging up the airspace while they are all waiting for their backoff() function to return (hence not receiving any signal because the transmitter is set to IDLE mode before starting the backoff() -> sending sequence).

I also wonder if the group byte should really be included in the buffers and the CRC routines. JCW told me that this is needed because otherwise, the driver would accept messages from other netgroups if that byte were to be scrambled. But, since the group is essentially the second SYNC byte used by the rf12, those transmissions shouldn't get the rf12 to sync and start receiving, would they? JCW am I wrong?

Setting nhop to 0 might cause all the nodes to keep routing... need to investigate and correct!

This driver uses an approach to Mesh networking that I think is flawed. It processes link loss in stead of node loss. I've only come to this conclusion when nearing completion. But in real-worls scenarios, the network will never experience a link loss because the node will most likely be stationary. A Node loss is far more likely as JeeNodes can run out of battery. The link loss and recovery should be handled completely different:

When initializing, the number of hops in every Routing Table (RT) entry shouldn't be 64 (max nr of hops possible), but 65. This value indicates that the corresponding node ID has not been discovered by the network and therefore is unreachable. rf_send() should immediately return false when sending to such an address. When the node is discovered, it is set to a certain value by setNextHop() automatically.

When a message fails (i.e. has been tried more than LINK_LOSS times), the system can resort to a number of actions. Currently, the corresponding address is reset to 65 and a Control (CTL) message is sent into the network, to hopfully find an alternative route. What should be done is one of 2 options:

1) send the message as broadcast All other nodes should also forward it as a broadcast and update their RT's using the received broadcasts (caused by the failed message, so this option would cause one happy broadcasting party at every routing failure...) Care must be taken so that every node only forwards the message once. This option is a lot less pretty than the other.

2) Change the routing method from the default Passthrough (immediately forward it) to Store & Forward. The nhop node should ACK the message, letting the sender know that he is still on-line (or rather on-air) And send it to its nhop for the destination RT entry. The message should contain a flag bit to let the receiving node know that we're useing SAF now. This way, the message will fail at the lost node, letting the network know which node has failed so the last node on the route can send out CTL messages to try and find an alternative route. Difficulty in this method is: how long should the original sender wait for te ACK? because every node along the route could retry 3 times, adding up to 1.5 second, and a mesh could contain 64 nodes... I still believe this is the best way, though.

Another option is to send CTL messages at regular intervals, to check if all the neighbors are still operational.