Sleep/Wake/TXRx Cycle

[Zeph]

@Yveaux said:

I wondered what turnaround would be. Is it in the datasheet?

Yup

[Yveaux]

@Zeph it's been too long since I had a good look at the data sheet....
What I'm really interested in is the time between packet reception and sending of ack packet, but judging from the figures that also seems to be 130us.

[Yveaux]

@therik Hi there. I took some time to connect my uCurrent & scope and ran a simple sketch which reads temp/hum from an SI7020 and light intensity from an LDR, powered from 2xAA batteries (no step-up ;-) ), regular nRF24 radio (no PA).
These 3 values are sent using MySensors 1.3 @1Mbps. Then the sensor node goes to sleep and the whole thing repeats.
This scope image shows the power consumption (blue) of a single wake-cycle (1mV == 1mA):

In short, the interesting values are:

• The sleeping sensor consumes 154uA sleep current (incl. radio, SI7020, LDR) (Not in this scope image; measured separately)
• The total wake-time is only 92ms, of which approx. 33ms is waking up, reading sensors etc. Rest is radio + going to sleep again.
• When awake it peaks at 28mA.

There must be something very wrong with your setup, taking almost 1.5sec to send 1 message, thats for sure !

[Zeph]

So am I seeing the power signature from sendng three packets for the results?

At 1 Mbps, a maximum packet (32 bytes) should take about 1/3 mSec. With successful auto-ack, there would be two turnarounds at 130 us each and an auto-ack packet at about 72 uS, say 2/3 msec per packet. Three packets should be done in not much over 2 mSec (including powerup time).

Of course, with failed auto-ack it can take much longer, given the timeout waiting for each missing ack and the auto retry. Worst case with 4 ms timeout and 15 retries is about 60 mSec; less than that for most settings.

@Yveaux was this test using failing auto-ack with retries?

And I gree that 1.5 sec doesn't make any sense, even at 250Kbps and maximal retries. Could the OP's time scale be off?

[a-lurker]

Any one presenting measurements should indicate if they are using Ver 1.3 or 1.4 of the code. There are significant differences in how the timing and ACKing is organized between the two. The OP is using 1.3 and I suspect @yVEAUX is using 1.4 - please correct me if I am wrong on that.

There is no point in trying compare results between 1.3 and 1.4 Any one using 1.3V will be far better off with 1.4.

[Yveaux]

@a-lurker said:

Any one presenting measurements should indicate if they are using Ver 1.3 or 1.4 of the code.

And anyone stating rules should first read the posts with some attention; it's clearly in my post :-1:

These 3 values are sent using MySensors 1.3

[Yveaux]

@Zeph @Therik asks about thoughts on his power signature. I did a similar experiment to show him that his initial findings are, for some reason, far off.

I agree on your timing calculations (packet payloads are far shorter than 32 bytes, though), but for some reason my measurements do also not seem to agree with the calculated values.
I used default settings for the MySensors library and used version 1.3. There should be no ack but I've seen (using wireless sniffer) the receiving nRF24 send acks anyway. Still have to investigate why...
There could also be delays in the MySensors or nRF24 driver implementation (how about the crc8 calculation in MySensors 1.3? -- anyone timed it?), but these are unlikely to take several ms.

Lets try to understand and help @therik improve his application! We will all benefit from it!

Update
@hek I had a quick look at the Sensor.cpp code and all sends seem to boil down to Sensor::sendWrite.
And what's in there? "WAIT FOR ACK" which can take 50ms???

  boolean Sensor::sendWrite(uint8_t dest, message_s message, int length) {
  // ... some init code
  RF24::stopListening();
  RF24::openWritingPipe(TO_ADDR(dest));
  RF24::write(&message, min(MAX_MESSAGE_LENGTH, sizeof(message.header) + length), broadcast);
  RF24::closeReadingPipe(WRITE_PIPE); // Stop listening to write-pipe after transmit
  RF24::startListening();

  if (!broadcast) {
    // ---------------- WAIT FOR ACK ------------------
     unsigned long startedWaiting = millis();
     bool timeout = false;
     // Wait for ack message maximum 50 ms
     while ( !RF24::available() && !timeout ) {
      if (millis() - startedWaiting > ACK_MAX_WAIT ) {
        timeout = true;
        debug(PSTR("Ack: receive timeout\n"));
        ok = false;
      }
     }
     // Check payload size and content
     if (!timeout) {
       // Check payload size and content
       if (RF24::getDynamicPayloadSize()==sizeof(uint8_t)) {
       uint8_t idest;
       RF24::read( &idest, sizeof(uint8_t));
       if (dest != idest) {
         debug(PSTR("Ack: received ack from the wrong sensor\n"));
         ok = false;
       } else {
         debug(PSTR("Ack: received OK\n"));
       }
       } else {
         ok = false;
         debug(PSTR("Ack: received none ack msg.\n"));
       }
    }
  }
  return ok;
}

Can you give us a quick explanation?

[Zeph]

Yowsa.

Those three tiny spikes that go up to about 27 may be the actual transmissions, then.

[hek]

@Yveaux said:

@hek I had a quick look at the Sensor.cpp code and all sends seem to boil down to Sensor::sendWrite.
And what's in there? "WAIT FOR ACK" which can take 50ms???

This is the old inter-node ack mechanism used in 1.3 (long story why we had to do it like this). This should not be mixed up with full route ack messages used from source to final destination.

This code has been replaced by the NRF build-in ack/retransmission functionality in 1.4.

[Yveaux]

@hek OK, I'll repeat with 1.4 then!

[therik]

Hi guys,

I checked again, with another scope (1 GHz Tektronix) and I get 1.44s total time. It must be hardware or software related, not measurement related. Any other ideas to fix? I need to run the node without a gateway, because the measurement must be made off-site from vera and the gateway.

[Zeph]

@therik said:

No modification: current from battery: 2.24 mA, current to pro-mini: 1.63 mA
Remove LED: current form battery: 144 µA, current to pro-mini: 104 µA
Remove LED and regulator: current from battery: 48 µA, current to pro-mini: 23 µA

This refers to removing a power-on LED from the APM, right? (The LED from the china booster already being removed).

And you were feeding power to the APM's VCC (ie: output of it's onboard linear regulator) until the third measurement, where you removed the unused regulator as well from the APM?

That's excellent low power for a cheap booster!

Did you remove the LED and reg with a simple soldering iron?

---

Only thing is, that bottom trace looks kinda choppy. No problems with powering the radio directly from the booster?

(All this leaving aside the slow timing. I understand that 1.3's timeouts were 50ms and it probably did a bunch of them because there was nobody to respond, but why would the lower current first part - presumably doing sensor measurements - take so long?).

[Yveaux]

@therik You are running at 8Mhz, right? Maybe do a quick I/o pin toggle test to toggle it a fast as possible and measure pulse on a scope. That test we can easily repeat when in doubt.

[therik]

Okay, did the toggle test using the delayMicroseconds() method. I tested 96 µs, 1000 µs, and 10 ms and all were very close to the set delay, pins 6, 5, and 4 respectively. (@ 8 MHz the delay is a multiple of 8 µs).

It must be the fact that I'm trying the MySensors temperature sketch 'gatewayless'. I wonder if I can modify the sketch to not wait for an ACK. Of course, when I get a scope at home the 'gatewayless' operation will not be needed.

[Yveaux]

@therik What about the first part of the scope chart, starting from 0 sec?
What is the sketch doing there for more than half a second? It was reading temperatures, but for how many sensors?