Author Topic: radio.delay oddness  (Read 1188 times)

Neko

  • NewMember
  • *
  • Posts: 37
  • Country: us
radio.delay oddness
« on: April 24, 2017, 10:06:13 PM »
In the low-power application I am working on, my gateway sends a wakeup burst to a node, and I then use radio.delay (from this thread) to wait N ms from the start of the wakeup burst until the node responds with data. The logic is simple:

Code: [Select]
radio.listenModeStart();
LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
burstRemaining = radio.LISTEN_BURST_REMAINING_MS;
radio.listenModeEnd();
radio.delay(burstRemaining + N);  // followed by 3x LowPower.powerDown()
radio.ListenModeEnd();
It doesn't quite work. The actual delay varies in a range of 250 ms from the trial to trial. The variation is in direct relation to (burstRemaining % 250).

But it does work if I replace radio.delay() with plain old delay(). I get very precise timing (+/- 3 ms) with this:

Code: [Select]
radio.listenModeStart();
LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
burstRemaining = radio.LISTEN_BURST_REMAINING_MS;
radio.listenModeEnd();
delay(burstRemaining + N); 
Or if I replace radio.delay(burstRemaining + N) with two separate radio.delays(), one for burstRemaining and one for N:

Code: [Select]
radio.listenModeStart();
LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
burstRemaining = radio.LISTEN_BURST_REMAINING_MS;
radio.listenModeEnd();
radio.delay(burstRemaining);        // followed by 3x LowPower.powerDown()
radio.ListenModeEnd();
radio.delay(burstRemaining + N);  // followed by 3x LowPower.powerDown()
radio.ListenModeEnd();
I'd use this last idea, except that it crashes after several hours of operation. The processor gets stuck somewhere inside the first radio.delay().

So it seems like there is some odd interaction between radio.listenModeStart and radio.delay, but I am not well versed enough in how the RFM69 works to figure out what the issue is. Any help would be welcome.
« Last Edit: April 24, 2017, 10:21:23 PM by Neko »

Neko

  • NewMember
  • *
  • Posts: 37
  • Country: us
Re: radio.delay oddness
« Reply #1 on: May 01, 2017, 03:28:25 PM »
I think I figured out more about this issue.

Here is a graph of the programmed delay against the actual delay using radio.delay(t);

When t < 1050, the relationship between t and actual delay is smooth.

When t > 1050, the relationship is quantized in steps of 256 ms.

Looking at the code for delay(), I guess this makes sense, given the different choices available for RF_LISTEN1_RESOL_IDLE.

« Last Edit: May 01, 2017, 03:42:02 PM by Neko »