nRF5 action!

[rmtucker]

@d00616

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

Should be:-

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

[rmtucker]

@d00616

Just checked and it now returns 10002 for a sleep(10000).
Much better after the above alteration.

[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.