This forum has moved to forum.jeelabs.net - this read-only archive is for reference only!
I'm going to add some code to the RF12 driver which will make it much easier to write sketches which send their readings on a periodic basis. See this page for details: http://wiki.jeelabs.net/p/33 - the basic idea is to take advantage of the fact that [i]in this particular context[/i] an occasional loss of information is usually acceptable.
Or to put it in network terms: think UDP i.s.o. TCP.
It's all wide open still, suggestions welcome.
I am (or maybe was, after learning about jeenode, I may abandon my radio project) implementing the following logic:
for sensors that tolerate occasional loss of data:
Every N seconds, send data only if there is new data (the most recent sensor reading is not equal to the last transmission), or if the previous reading wasn't acknowledged. No automatic retransmission is used when ack isn't received, that is covered at the next transmission in N seconds. The goal is to transmit as little as possible in order to minimize radio bandwidth and maximize sensor battery life.
for sensors that don't tolerate data loss or delay:
Transmit as soon as the data changes. Use ACK and retransmission to make sure the data gets through.
Note that you should use some sort of pseudo-random, exponentially increasing, backoff delay between re-transmissions so you don't have two nodes banging away at each other in sync. But, unlike TCP, return to the minimum backoff delay for each new transmission. I haven't gone through your code yet, maybe you have that already. It is basic CSMA/CA.
My thought is that on retransmission, I would always send the latest data reading. Once the backoff delay becomes the maximum N seconds, it works like the algorithm that tolerates data loss. Thus, the two transmit routines are the same. Just set the minimum retransmit time to 1 or equal to the maximum retransmit time during setup.
Thanks. This is close to what I've been working on. Some differences, but nothing is set in stone at this early stage: not yet using randomized back-off (this is indeed better), and not exponentially slowing down but simply "giving up" after a few retries. The case I need to deal with is when the central node is off, in which case all the other nodes would flood the airwaves with each new sensor reading. What I'm going to try is: if there has been an ack, then on next reading start resending as usual, but if the last reading never got an ack then don't even bother resending on subsequent transmissions. The other tweak is that I'll probably force a transmission every 15 minutes or so, even if nothing changed - to confirm that the node is still alive. These transmissions might contain some extra info, such as battery status.
The other thing I need to look into is listen-before-send. The ISM specs, at least for the 868 MHz band, seems to indicate that with LBS more than 1% of the time may be used for transmissions. Right now, band utilization is no big deal - even a few dozen nodes sending a few bytes every 10 seconds should get very few collisions, since a packet takes just a few msec.
First implementation now checked in - there is a weblog post about this "easy transmission" interface coming up.