Computing stuff tied to the physical world

Synchronised reception

In AVR, Software on Nov 2, 2012 at 00:01

That homeGraph setup brought out the need to somehow synchronise a receiver to the transmitter, as illustrated in a recent post. See also this forum discussion, which made me dive in a little deeper.

Let’s take a step back and summarise what this is this all about…

The basic idea is that if the transmitter is transmitting in a fixed cycle, then the receiver need not be active more than a small time window before and after the expected transmission. This might make it possible to reduce power consumption by two orders of magnitude, or more.

Here’s the initial syncRecv.ino sketch I came up with, now also added to JeeLib:

Screen Shot 2012 10 30 at 22 55 17

The idea is to turn the radio off for T – W milliseconds after a packet comes in, where T is the current cycle time estimate, and W the current +/- window size, and then wait for a packet to come in, but no later than T + W.

Each time we succeed, we get a better estimate, and can reduce the window size. Down to the minimum 16 ms, which is the granularity of the watchdog timer. For that same reason, time T is truncated to multiples of 16 ms as well. We simply cannot deal with time more accurately if all we have is the watchdog.

Here are some results from three different JeeNodes:

Screen Shot 2012 10 30 at 22 48 04

Screen Shot 2012 10 30 at 22 42 44

Screen Shot 2012 10 30 at 22 39 44

Screen Shot 2012 10 30 at 22 37 04

(whoops – the offset sign is the wrong way around, because I messed up the subtraction)

Note that for timing purposes, this sketch first waits indefinitely for a packet to come in. Since the transmitter doesn’t always send out a sketch, some of these measurement attempts fail – as indicated by multiple R’s.

That last example is a bit surprising: it was modified to run without powering down the radio in between reception attempts. What it seems to indicate is that reception works better when the radio is not put to sleep – not sure why. Or maybe the change in current consumption affects things?

As you can see, those watchdog timers vary quite a lot across different ATmega chips. These tests were done in about 15 minutes, with the sending sketch (and home power consumption levels) about the same during the entire period.

Still, these results look promising. Seems like we could get the estimates down to a few milliseconds and run the watchdog at its full 16 ms resolution. With the radio on less than 10 ms per 3000 ms, we’d get a 300-fold reduction in power consumption. Battery powered reception may be feasible after all!

  1. How about to put the external crystal to mantain the time and you wakeupp every x time like here: JeeNode with a 32 KHz crystal http://jeelabs.org/2011/06/28/jeenode-with-a-32-khz-crystal/ Denis

    • I’d prefer to find a solution without extra circuitry, but yes, that would be another option.

  2. Nice work, implementing this with the coarse watchdog granularity :) I suppose a newer version will not keep the radio on every second packet reception?

    Turning the radio on and off itself doesn’t take that much time in the sketch, does it? Then it shouldn’t influence the timing of the ATmega much. (Or indeed a wobble in Vcc could cause the WDT speed to change—check this with a scope?)

    But, when powering on, is the radio immediately online, ready to pick up packets? Otherwise, you might be late in turning it on—but then the RRRRs would occur mostly at the small window size, i.e. at the last few lines, and they’re spread throughout the log.. Interesting! :)

    • I’ll be posting several refinements to this in the next few days. Perfection is elusive, but I do end up with a fairly usable algorithm.

      I think the RFM12B takes under a millisecond to enter receive mode. Haven’t really measured it.

  3. When the window size reaches 16, it will never increase again. If for some reason (fresh battery?), the sending node gets out of sync, they will probably never sync up again. Perhaps you could consider increasing the window size if you’ve missed a large number of packets?

    • Indeed. This is just part of a more complete solution, to narrow down that first estimate.

  4. The longest internal delay to get from sleep to receiver-ready comes from kickstarting the crystal – listed as Typical 2ms, Max 7ms. Depends mostly on the loading and Q of the crystal itself. There may be a considerable difference between the older can type and the newer SMD type.

    BTW, is it worth considering inverting the sleep initiator? The RFM12B timer is much lower on power consumption and can both wake itself and a sleeping MCU.

    • is it worth considering inverting the sleep initiator?

      Yes, but when I tried a long time ago, I couldn’t figure out all the race conditions. Always ended up with a never-waking unit after a while. I’d like try again at some point, now that I understand these things a bit better.

  5. would it be useful to instruct a sending node with a response/ack that contains the desired length of the radio silence ? when you reply to a sender, these senders only have to enable their receivers fairly shortly and always only directly after transmission. This way you could organize the ‘future’ sent packages, minimizing e.g. collisions. Now you are tweaking the reciever after the sender, but does that work for multiple senders ? you can also ack the last-received package(-number) and facilitate retransmission. this looks very much like what tcp does.

    • It depends – once you do that, you basically set up a dialogue, so this would work for 1-on-1 comms. The homePower/homeGraph scheme is currently still agnostic to how many nodes are sending and how many are listening, i.e. the sender does not change its behavior with more listening nodes.

      In this case it wouldn’t matter, but note that an ACK is again a packet, doubling the packet rate and bandwidth utilisation. And when both sides are battery-powered in such a bi-directional setup, you end up with the same “can’t turn the receiver on for a long time” problem on both sides.

      As for multiple senders: if you need to track multiple independent senders, then the logic will become a lot more complex, because then you need to estimate two cycles independently, but the logic stays the same: predict T1 and T2, and listen from T1-W1 to T1+W1 as well as from T2-W2 to T2+W2, switching to whichever comes first.

      Another idea would be to have a node collect everything, and then to instruct it to periodically send out a tailor-made summary for a certain purpose (sort of a customisable filter+relay), then the receiver could just listen to that single summary transmission to find out everything it needs.

  6. JCW, have you explored RFM12b’s Low Duty-Cycle and Wake-Up Timer? These (in theory) would have significant impact on reducing power consumption

    • Not yet. But now that I understand all this timing stuff better, I probably should. I agree that it could be more efficient – don’t knpw yet how fine-grained those RFM12B settings can be, but perhaps the transmit cycle can be chosen such that an optimal range of adjustments can be used.

      I did try the wake-up timer a long time ago, but never got the RFM12B+ATmega combo working reliably. So yes, that too is worth a second attempt.

      There’s definitely still a lot left to explore…

  7. JCW, this is close to what I proposed with “time slots”. Anyway, I do not quite agree with all nodes being battery powered, so suggested star-alike environment with always-on [and powered from socket] central/base node, which could carry an RTC.

    PS: got my JL delivery, could start actually playing shortly.

Comments are closed.