Computing stuff tied to the physical world

Losing sync is bad

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

Yesterday’s code has a nasty side-effect of getting into a corner out of which it almost can’t recover at times. Here’s a somewhat longer run, edited for brevity (note the indented lines):

Screen Shot 2012 10 30 at 23 52 35

On one occasion, it took 238 retries (12 minutes) to get back into sync!

Note how the code is sailing slightly too close to the edge, by always being at 0 or 1 ms from the expected time, just because this watchdog timer “happens” to run at a particular rate.

One fix is to gradually widen the window again when too many receptions in a row fail:

Screen Shot 2012 10 30 at 23 56 44

The other step is to always leave a bit more time when calculating a new estimate – it’s better to err on the side of receiving too early than to miss the start of the packet:

Screen Shot 2012 10 30 at 23 55 53

Whoops, looks like this doesn’t get it right – but it illustrates the widening:

Screen Shot 2012 10 31 at 00 02 29

This change works a lot better (i.e. plus 2, instead of minus 2):

Screen Shot 2012 10 31 at 00 07 05

Here’s the sample output:

Screen Shot 2012 10 31 at 00 05 35

The syncRecv code on GitHub has been updated with this tweak. More to come!

  1. I had this same problem somewhere along my adventures. I solved it by simply “waiting” a few cycles untill a new packet came in, combined with ack’s. So if my sender gets an Ack, it knows the receiver goes into sleep for the length of the cycle and vice-versa. This limits the time my nodes are out of sync, but you will have to report at least one packet every cycle….

    • The downside of that is that the sender needs to listen for an ACK. Something you may not want to do in a very low power sensor, where you prefer a “fire and forget” approach.

  2. In one of my setups (using MSP430s) I used a system where the transmitter gets synced also. Every Xth transmission the transmitter asks for a sync (= ACK). That sync can be used to get both transmitter and receiver in sync. The receiver told the sender in the sync/ack also how much time was between the last 2 received transmissions and the sender can then react by slowing down/speeding up transmissions. In the MSP430 setup it was clear that temperature played a major role in the way timed sendings would happen (no crystal installed so running on internal timers).

    cheers CorB

Comments are closed.