Sleep/Wake/TXRx Cycle

therik

Hi guys,

I had a chance to connect a sensor node to an oscilloscope over the last couple of days, and also to a couple of meters (Fluke and Keithley). I'd like your opinions as to the sleep/wake/TxRx cycle that is shown in the trace below.

As is evident from the figure, the entire wake/TxRx cycle is around 1.44 s. I assume that the large current (measured voltage with a 10x probe across a ~5 ohm resistor) is the radio TxRx portion. And the initial current is the wake, but why it drops between is a mystery.

Anyway, here are my numbers from the meters using an Arduino pro mini clone 3.3V running the temperature sensor sketch (1.3 library) using 2xAA through a booster ('China no LED') radio run directly from batteries.

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

Wow, this is great, with an improved booster and 2xAA is should have a year easy.

Thoughts?

marceltrapman

Are you talking about a 'booster' and a 'radio' or about a 'boosted radio'?
Same with 'Remove LED'. Do you mean 'Remove booster' or do you mean 'Remove boosted radio'?

Yveaux

@therik I think your wake time is quite long. What does the sensor do when it's awake?

a-lurker

Yes I thought this was a rather long time too. Need to post the code in use.

Just on say a single transmission at 250K bps - then (32*8)/250000 = about one ms. That's assuming a 32 byte payload at 8 bits per byte. It would be longer than this, as it may be sent multiple times, if an ACK was not received. Plus the turn around time and the actual ACKing has to be added in as well.

How many variables are being returned?

Yveaux

@a-lurker the default retry timeout when no ack received is 1500us ( from my head) so you can do a lot of retries in a second. The Nrf will give up anyway after max. 15 failed retries...
So there's something fishy going on.
When I have some time I'll measure one of my test sketches and see how much time it requires.

therik

@marceltrapman Clarification: I'm running the 'China' 3.3 V booster and powering a standard radio both directly from the 2xAA batteries. The 3.3 V booster powers the pro-mini clone and the Dallas temperature sensor.

Yes, I modified the code to run the node 'gateway-less'. That is, I commented out much of the void setup() so that it would enter the void loop() and do it's thing. So, yes it is most definitely maxing out the retries.

I'll post the code...but, can someone let me know how to format the code for the forum...I don't want blast the code in the normal text box!

a-lurker

@therik To show as code - insert a couple of line feeds at the start and then all lines of code thereafter, indent with four spaces.

If you are using ver 1.3 of the Arduino code; then recommend you change to the ver 1.4 of the code. The radio code is far better.

therik

Okay, here is the code...

#include <Sleep_n0m1.h>
#include <SPI.h>
#include <EEPROM.h>  
#include <DallasTemperature.h>
#include <OneWire.h>
#include <RF24.h>
#include <Sensor.h>  

#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected   
#define MAX_ATTACHED_DS18B20 16
unsigned long SLEEP_TIME = 3; // Sleep time between reads (in seconds)

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
Sensor gw;
Sleep sleep;
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors=0;
boolean metric = false; 

void setup()  
{ 
  sensors.begin();
  gw.begin(); 

  // Send the sketch version information to the gateway and Controller
  //gw.sendSketchInfo("Temperature Sensor", "1.0");

  // Fetch the number of attached sensors  
  numSensors = sensors.getDeviceCount();
  // Register all sensors to gw (they will be created as child devices)
  //for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
  //   gw.sendSensorPresentation(i, S_TEMP);
  //}
 // metric = gw.isMetricSystem();
}

 void loop()     
{     
  sensors.requestTemperatures(); // Fetch temperatures from Dallas
  delay(100);
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
    // Fetch and round temperature to one decimal
    float temperature = static_cast<float>(static_cast<int>         ((metric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;
// Only send data if temperature has changed and no error
if (lastTemperature[i] != temperature && temperature != -127.00) {
  gw.powerUp(); // Powerup introduces a small delay (which is missing in radio.write powerup)
  // Send variable (using registered shortcut) to gw
  gw.sendVariable(i, V_TEMP, temperature, 1);
  //lastTemperature[i]=temperature;
  lastTemperature[i]=temperature-100;//Force a reading every time; Added by Erik
  //Serial.println(temperature); //Added by Erik
}
  }
  // Power down the radio.  Note that the radio will get powered back up
  // on the next write() call.
  delay(500);
  gw.powerDown();
  sleep.pwrDownMode(); //set sleep mode
  sleep.sleepDelay(SLEEP_TIME * 1000); //sleep for: sleepTime 
}

therik

@a-lurker yea, I know everyone likes v1.4. I had some trouble initially, probably related to the voltage ripple on the radio, and I haven't migrated over to v1.4 since discovering the solution to the radio power supply problem. I will try v1.4 again soon; I hope.

Yveaux

@therik said:

  gw.powerUp(); // Powerup introduces a small delay (which is missing in radio.write powerup)

By quickly scanning over your code I only see powerUp getting called for every sensor. That shouldn't be required. I would take it out of the loop. In 1.4 you don't need to call powerUp at all; the library will do it for you.

If you only have 1 sensor attached that loop is only executed once, btw.

Zeph

@a-lurker said:

Just on say a single transmission at 250K bps - then (32*8)/250000 = about one ms.

That's good enough for the topic here, but here's how I calculate when I'm planning.

Add 9 bytes to the payload length for overhead (preamble + 5 byte address + control + 2 byte CRC). Control is really 9 bits, but why quibble? So a full packet @250Kbps is about 4/3 ms.

Turnaround is 130uS. With simple successful ACK in ESB mode, a 32 byte payload would take about 41x32us + 130 us + 9x32us, (plus another 130 us before the next transmit can begin). Call it 1 3/4 ms before you get acknowledgement.

(use 8 us and 4 us multipilers for 1 Mbps and 2 Mbps)

Those are best cases in an ideal world of course, things will be slower in reality.

Yveaux

@Zeph said:

Turnaround is 130uS.

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

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):

upload-dacf1add-9eb0-4e0a-9db6-c2561345a1b8

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.

Sleep/Wake/TXRx Cycle

16

11.7k

11.2k

113.1k