nRF5 action!

NeverDie

Epilog: I made the changes so that just prior to taking a measurement the sense pin is hwPinMode'd to an input pin, and then immediately after the measurement I disconnect it. Seems to be working, and without the usurious power drain I was experiencing previously. :)

rmtucker

@NeverDie said in nRF5 Bluetooth action!:

Epilog: I made the changes so that just prior to taking a measurement the sense pin is hwPinMode'd to an input pin, and then immediately after the measurement I disconnect it. Seems to be working, and without the usurious power drain I was experiencing previously. :)

Good news
So what is the current usage now when sleeping?

NeverDie

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

Epilog: I made the changes so that just prior to taking a measurement the sense pin is hwPinMode'd to an input pin, and then immediately after the measurement I disconnect it. Seems to be working, and without the usurious power drain I was experiencing previously. :)

Good news
So what is the current usage now when sleeping?

About 6ua on this particular Ebyte nRF52832. I'm pretty sure it would be higher on my other Ebyte nRF52832, though I haven't measured it again. Haven't tested any additional ones as of yet.

mfalkvidd

@rmtucker very nice work, thanks for locating the problem.

It occurs because 12/125 will be evaluated before the bit shift. http://en.cppreference.com/w/c/language/operator_precedence for details.

d00616

@rmtucker said in nRF5 Bluetooth action!:

MY_HW_RTC->CC[0] = max((ms<<12 / 125), 2);
Should be:-
MY_HW_RTC->CC[0] = max(((ms << 12) / 125), 2));

Thank you. This was the result of merging some commits. I haven't seen I reversed that change. I had tested the code before merging some commits into one.

Actually I check the result of sleep(511999) and sleep(512001). When it's finished I fix that in MySensors.

d00616

@scalz said in nRF5 Bluetooth action!:

@d00616 said in nRF5 Bluetooth action!:

Should I add a DISCONNECTED mode to hwPinMode()?

make sense to have it for input too.. i agree

What's the best name for this mode? DISCONNECTED or INPUT_DISCONNECTED. I prefer the first variant.

I have to play a little bit with the port modes. Maybe it saves some current when the serial port pins are put into the disconnected mode while sleeping.

d00616

@d00616 said in nRF5 Bluetooth action!:

Actually I check the result of sleep(511999) and sleep(512001). When it's finished I fix that in MySensors.

Is fixed in development branch.
https://github.com/mysensors/MySensors/pull/917

scalz

@d00616 said in nRF5 Bluetooth action!:

@scalz said in nRF5 Bluetooth action!:

@d00616 said in nRF5 Bluetooth action!:

Should I add a DISCONNECTED mode to hwPinMode()?

make sense to have it for input too.. i agree

What's the best name for this mode? DISCONNECTED or INPUT_DISCONNECTED. I prefer the first variant.

I have to play a little bit with the port modes. Maybe it saves some current when the serial port pins are put into the disconnected mode while sleeping.

agree too for the first one should be enough :simple_smile:
yes, for lower power consumption, better disconnect pins which are not needed.
it's the same for a simple 328p though (setting the right pin states).

NeverDie

As a follow-up to rmtucker's line of inquiry, what is currently the shortest deep sleep that's supported? Is it one millisecond, or something else?

rmtucker

@NeverDie
Theoretically it is 2 clock ticks at 32768khz so 0.000061035secs i think.
But how long it takes to go into sleep mode and come out of sleep mode i am not sure.
But of course the sleep function only allows millis.

d00616

@NeverDie said in nRF5 Bluetooth action!:

As a follow-up to rmtucker's line of inquiry, what is currently the shortest deep sleep that's supported? Is it one millisecond, or something else?

Why do you need this type of short sleeps?

Sleep is for battery powered devices. A device that wakes up more than 1000 times in the second might be hard to drive with a battery.

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie
Theoretically it is 2 clock ticks at 32768khz so 0.000061035secs i think.

This is correct.

But how long it takes to go into sleep mode and come out of sleep mode i am not sure.

It's simple to evaluate with micros() before and after a sleep().

NeverDie

I haven't yet upgraded to the current version, so maybe this is moot (?), but the following code in a loop:

  digitalWrite(TEST_PIN,HIGH);
  sleep(100); // Sleeps for 100ms
  digitalWrite(TEST_PIN,LOW);
  sleep(100); // Sleeps for 100ms

holds the TEST_PIN first HIGH for 250ms and then LOW for 250ms. That means 150ms of sleep overhead, which seems like a lot.

I measured the length of time the TEST_PIN is HIGH or LOW using an oscilloscope. Ran it on an Ebyte nRF52832.

NeverDie

Nevermind. I just now upgraded to the current versions, and it seems to be fixed.

NeverDie

So, with the current libraries and an Ebyte nRF52832 that's using its external crystal oscillator, I'm now measuring the sleep overhead as being 260us. I expect that may be even less if using the internal 32768Hz resonator.

NeverDie

I tried measuring the sleep overhead with the Ebyte nRF52832 running on its internal resonator, and surprisingly it wasn't that much faster: it appears to be about 220us.

Here's the test script:

#include <MySensors.h>

#define TEST_PIN 19  // (P0.19) 

void setup() 
{
  hwPinMode(TEST_PIN, OUTPUT_H0H1);  
  digitalWrite(TEST_PIN, LOW);  
}

void loop() {
  digitalWrite(TEST_PIN,HIGH);
  sleep(1); // Sleeps for 1ms
  digitalWrite(TEST_PIN,LOW);
  sleep(1); // Sleeps for 1ms  
}

Here's the scope capture:

Of course, this assumes (?) that the mcu sleeps for exactly 1ms, and during the extra 220us it is either ramping down or ramping up.

BTW, I don't anticipate sleeping for a mere 1ms at a time. However, to get a good measurement of the overhead using the oscilliscope I had to set the sleep period that low.

I can, however, well imagine having a use for sleep periods lasting 100ms.

NeverDie

Anyhow, it's not academic, as the plan is to approximate the "listen-mode" of an RFM69, but using the nRF52832. For that to be power efficient, I need the mcu to wake-up and fall-asleep very, very fast. For comparison, an atmega328p can wake-up in 3.8usec.

On page of the nRF52832 datasheet, it advertises:

Fast wake-up using 64 MHz internal oscillator

However, I'm not sure how to set that up. There's no menu check-box for that on the Arduino IDE tools menu like there is for the 32768Hz internal resonator. On the other hand, I'm not sure that it matters, because apparently the 64Mhz external crystal, which is what's slowing down the wake-up, is required to operate the radio.

NeverDie

Here's the current drain through a 1-ohm resistor:

i.e. 1mv=1ma.

As you can see, there's a rather long tail before it finally falls asleep.

Here is the same, but superimposed onto the TEST_PIN capture:

NeverDie

Good news. It appears that DCDC is already implemented on the Ebyte nRF52832 and working automatically!

Just for grins, I decided to measure the Tx time and current draw from sending a 13 byte payload in a packet, and I was happily surprised to see how low the current draw was:

The yellow trace marks the start and stop of the packet transmission process from a software point of view, but the blue trace measures the current (as before 1mv=1ma). As you can see, the transmission current never seems to rise above 2.5ma. The only (?) explanation I can think of is that DCDC must be working. Right? Tx power is set to be 4dbm.

It would be great if someone else would confirm/refute the measurement.

Nca78

@NeverDie said in nRF5 Bluetooth action!:

It would be great if someone else would confirm/refute the measurement.

I don't think it's possible, from the datasheet peak current is 7.7mA at +4dB with DCDC enabled with 3V power supply.
Current gain from 3V=>1.7V DCDC conversion is already included in this measurement so you should not be able to go lower.

How did you make your measurement across the resistor ?

NeverDie

@Nca78
You're right. It didn't ring true, so I setup some different capture hardware, and this time the image is a lot crisper:

This time I powered it from a 3.3v supercap and with the 1 ohm resistor soldered securely onto a PCB, with the o-scope leads on either side of it.

So, sadly, it doesn't look DCDC after all, because on this capture the peak is exceeding 20ma. :(

It's interesting how lengthy (and energy intensive) the phase is that's just prior to the transmission itself. I presume that's mainly just the PLL coming up to speed? It looks as though the actual current expended in the prelude exceeds that of the actual Tx proper!

I'm guessing that in the earlier scope capture, the probe must have slipped into 10x mode, because the shape is similar, just proportionately reduced by roughly that factor.

nRF5 action!

11

11.7k

11.2k

113.0k