nRF5 action!

[NeverDie]

So, to move forward with this, I took a super-stripped down nRF52832, and loaded it with a super stripped down sketch that never initializes the radio and pretty much just jumps directly into a long RTC 12 hour slumber using the MySensors sleep routine. Measuring the current drawn while in that slumber using a uCurrent Gold, I'm reading about 9.3ua. So, to confirm that, I'm running the same stripped down setup from a 10F supercap, and I'll see at what rate the supercap voltage drops with time, and whether that appears to agree or not with these initial measurements.

Hopefully the current draw will remain low, and there will be no surprises. In that case, I'll add stuff back in until I find the culprit that was previously causing the higher current draw.

[rmtucker]

@NeverDie
I can not understand why you are drawing 9.4uA in the first place?.
My nrf51822 seems to consistently only draw 4-5uA with no strip down of software when in mysensors sleep mode.
Fair enough i have not got your measurement equipment but i don,t see it being that far away.
The data sheets seem to point to under 5uA.

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

I can not understand why you are drawing 9.4uA in the first place?.

Yes, it is puzzling. I don't have a good answer as to why it measures so high. Maybe the crystal oscillator? What else is there that might be causing it?

[NeverDie]

After this initial run completes, I'll try reprogramming it to use the internal resonnator instead and see if that makes any difference.

[NeverDie]

Indeed, reprogramming the Ebyte nRF52832 to use the internal oscillator dropped the sleep current consumption down to 5.4ua.

I wonder whether physically removing the crystal oscillator would result in additional savings, or if that's as low as it goes?

I also wonder whether the datasheet cheats a bit by not counting the current consumed by the external crystal oscillator when that's being used? Otherwise, I don't see how Nordic can claim a <2ua sleep current for the nRF52832.

[rmtucker]

@NeverDie

Stranger still my 4-5uA is using the external crystal??.

[NeverDie]

I have to amend what I just said, because I took a measurement short-cut that in retrospect I shouldn't have: namely, I did the measurements on two different modules.

I went back and changed the 5.4ua module using the RC internal oscillator to use the external crystal oscillator, and it measures about the same.

So... The difference I was reading was a difference in the way the two modules measure. I'm not sure why one reads higher than the other, except perhaps that I didn't clean the solder flux off the higher reading module, and I did clean off the solder flux on the lower reading module.

I'll try cleaning the solder flux off the higher reading module and see if that drops the current consumed.

[NeverDie]

I cleaned off the solder flux and... no real difference. Go figure. Maybe it's just random variation among the Ebyte Modules? I guess I'll have to wire up more of them and see how they all compare.

[Nca78]

@NeverDie did you select the option with internal crystal ? 1s accuracy after 12h like you said before sounds more like a precise external crystal than an internal one.

[NeverDie]

@Nca78 said in nRF5 Bluetooth action!:

@NeverDie did you select the option with internal crystal ? 1s accuracy after 12h like you said before sounds more like a precise external crystal than an internal one.

Up until today I was using just the external crystal on the Ebyte nRF52832's. It was only for comparison purposes of current consumption that today I switched to the internal resonator. It's about the same current consumption. Maybe if I now remove the external crystal, it will save some current? I just don't know.

[d00616]

@rmtucker said in nRF5 Bluetooth action!:

I can not understand why you are drawing 9.4uA in the first place?.
My nrf51822 seems to consistently only draw 4-5uA with no strip down of software when in mysensors sleep mode.

While developing the nRF5 port, I had no chance to measure the current of the nRF52 accurate. With my original nRF51 dev kit I I have a sleeping current matching the data sheet.

Now I can measure currents in the µA range. With all nRF52 I have, I measured sleeping currents around 10µA. This is to much. We have to see 2-3µA. I have no original nRF52832 dev kit to compare. The reason of this sleeping current can be either an error in the layout or there is a component which is not required in active state while sleeping.

At the moment I have no time to analyse this. There is a bug in the radio code, which I have to fix. When transport debug is disabled no packages are received. In my opinion this has more priority.

[Koresh]

@NeverDie Just my two cents. Leakage current through non ideal capacitors can be 1-10uA.

[NeverDie]

@NeverDie said in nRF5 Bluetooth action!:

So, to move forward with this, I took a super-stripped down nRF52832, and loaded it with a super stripped down sketch that never initializes the radio and pretty much just jumps directly into a long RTC 12 hour slumber using the MySensors sleep routine. Measuring the current drawn while in that slumber using a uCurrent Gold, I'm reading about 9.3ua. So, to confirm that, I'm running the same stripped down setup from a 10F supercap, and I'll see at what rate the supercap voltage drops with time, and whether that appears to agree or not with these initial measurements.

Hopefully the current draw will remain low, and there will be no surprises. In that case, I'll add stuff back in until I find the culprit that was previously causing the higher current draw.

It turns out that the culprit was the mere act of using pinmode to designate a pin as an input pin, even if it's not connected to anything. Then, during sleep, the current consumption is an order of magnitude higher. This is quite different behavior than on, say, an Arduino pro mini, where the input pins are high impedance and there's neglible current draw.

Not sure what to do about it though. Any ideas?

[NeverDie]

The same sort of thing happens if pinmode is used to designate a pin as an output pin--again, even if nothing is connected to it.

This is a potential show stopper. This module is useless to me if I can't connect it to anything.

As a workaround, is there some way to designate a pin as undefined again after having used pinmode to define it as either an input pin or an output pin?

[NeverDie]

Well, setting the pinmode to OUTPUT and then digitalwriting it to LOW seems to help considerably--at least when it's not connected to anything.

[Edit: Setting it to HIGH also helps similarly.]

[NeverDie]

Anyhow, I'm relieved that the radio isn't the source of these power drain problems. This pinmode stuff is a bummer, but it looks like I can at least partially work around it.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Well, setting the pinmode to OUTPUT and then digitalwriting it to LOW seems to help considerably--at least when it's not connected to anything.
[Edit: Setting it to HIGH also helps similarly.]

Thank's. I check this after I fixed the Radio.

Actually, I have this board running. I measure a voltage of 0.13mV=6,6µA at the shunt with a simple sleep sketch. When I switch two pins into INPUT_PULLUP, then I measure 0.15mV==7,5µA.

When I switch on the LED then I measure 12.75mV == 0,6375mA, One pin in OUTPUT_H1H0 mode. With LED off I measure 0.15mV==7,5µA.

My MCU is nRF52832 QFAAB0 1615AX

P.S.: I have no documentation about the board. When I measure the boards current, then I have an shunt factor of 22,5. I think calculating with 20 is ok.

[NeverDie]

@d00616
Thanks! I just now ordered one of your boards so that in the future we can share a common platform for comparing numbers.
https://www.aliexpress.com/item/NRF52832-Mini-Development-Board-Gold-Core-board-Wireless-Bluetooth-Transceiver-Module/32798618219.html?spm=2114.search0204.3.1.GUmybP&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10130_5490020_10068_5430020_5410020_10307_10137_10060_10155_10154_10333_10334_10056_5370011_10335_10055_10336_10054_10059_10332_100031_10099_5400020_10103_10102_10052_10053_10107_10050_10142_10051_10324_10325_5380020_10326_5390020_10084_10083_10080_10082_10081_10178_10110_10111_10112_10113_10114_10312_10313_10314_10316_10078_10079_10073_5420011-10332_10333,searchweb201603_5,ppcSwitch_4_ppcChannel&btsid=78a27a2f-4aa5-49a0-a538-502a2c86d8f2&algo_expid=598ae4bb-6401-4529-89ad-6e8d8a90af12-0&algo_pvid=598ae4bb-6401-4529-89ad-6e8d8a90af12&transAbTest=ae803_3

[By the way, I did my measurements on an Ebyte nRF52832 module]

[scalz]

in that case, you need to set it as a floating input i think, like it's generally at reset.
In datasheet, section 20 (p111), is explained how works the GPIO. You have a Bit for disconnecting it. See the PIN_CNF[n] registers. For instance, p.140, you can see how it looks for the P0.10, and the Bit 1.
This should do the job..

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Thanks! I just now ordered one of your boards so that in the future we can share a common platform for comparing numbers.

Ok. I have measured my Ebyte with the same sketch and in the µA range of my VC165 multimeter. Sleep current is 9.9µA with two ports in INPUT_PULLUP and one Port in OUTPUT_H0H1 mode. (b.t.w. this module costs actually 3,82€)

@scalz said in nRF5 Bluetooth action!:

in that case, you need to set it as a floating input i think, like it's generally at reset.
In datasheet, section 20 (p111), is explained how works the GPIO. You have a Bit for disconnecting it. See the PIN_CNF[n] registers. For instance, p.140, you can see how it looks for the P0.10, and the Bit 1.
This should do the job..

Should I add a DISCONNECTED mode to hwPinMode()?

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

Sleep current is 9.9µA with two ports in INPUT_PULLUP and one Port in OUTPUT_H0H1 mode....

Ah, maybe that's part of the difference. I was doing just:

pinMode(ALPHA_PIN, INPUT)
pinMode(BETA_PIN, OUTPUT)

because that's how I would have done it on an Arduino. Should we instead always use INPUT_PULLUP and OUTPUT_H0H1 instead?

[rmtucker]

@NeverDie
Should be

hwPinMode(DIGITAL_INPUT_SENSOR, INPUT_PULLUP);

According to NRF5 platform

[NeverDie]

Thanks! Somehow didn't remember that.

So, as suggested by @scalz what is some example code that can be used to "disconnect" the pin later?

[rmtucker]

@NeverDie
He has not added that facility yet,i think he asked you if you wanted it adding to the code?

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

if you wanted it adding to the code?

Definitely!

[scalz]

for unused pins, it should be floating, not pullup. set the pin register you need to 0x02.
Something like that
NRF_GPIO->PIN_CNF[ulPin] = 0x02;
that will put pin in same state like it's on reset. Everything disabled/default, floating, with disconnect bit set.
(see datasheet gpio).

@d00616 said in nRF5 Bluetooth action!:

Should I add a DISCONNECTED mode to hwPinMode()?

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

[NeverDie]

Maybe add:
OUTPUT_D0D1 -> Disconnected 0, Disconnected 1
or similar to your list as another easy way to effectuate the disconnect?

[NeverDie]

It finally makes sense now as to why there were all those "disconnected" choices among the various OUTPUT options. In my case, for controlling whether the solar panel is connected or disconnected, choosing OUTPUT_S0D1 works perfectly.

So, I suppose another way to disconnect an input pin would be to redefine it as an OUTPUT pin with a disconnect state, and then immediately put it into the disconnected state.

[rmtucker]

@d00616 said in nRF5 Bluetooth action!:

@rmtucker said in nRF5 Bluetooth action!:

Yes being able to change the prescaler dynamically would help a great deal as 125ms / 582.542 hours is not really useful for most applications with a 250ms overrun.

The sleep() function is now more precise for sleeping <512s:

https://github.com/mysensors/MySensors/pull/909

The PR is waiting for merge.

Hmm just tried the latest commit and it is giving me 306ms for sleep(10000).
Something not quite right.

[NeverDie]

@rmtucker
How are you measuring how long it's sleeping?

[rmtucker]

@NeverDie said in nRF5 Bluetooth action!:

@rmtucker
How are you measuring how long it's sleeping?

Just using hwMillis() before and after sleep and subtracting one from the other.
It was just reading + 250ms until @d00616 commited some changes a few hours ago.

[rmtucker]

something wrong in here:-

// Calculate sleep time and prescaler
		if (ms<512000) {
			// prescaler 0, 30.517 μs resolution -> max 512 s sleep
			MY_HW_RTC->PRESCALER =  0;
			// Set compare register to 1/30.517 µs to garantee event triggering
			// A minimum of 2 ticks must be guaranteed
			// (1000/32768)<<12 == 125
			MY_HW_RTC->CC[0] = max((ms<<12 / 125), 2);
		} else {
			// 8 Hz -> max 582.542 hours sleep.
			MY_HW_RTC->PRESCALER = 4095;
			// Set compare register to 1/125ms
			// A minimum of 2 ticks must be guaranteed
			MY_HW_RTC->CC[0] = max((ms / 125), 2);
		}

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

@rmtucker
How are you measuring how long it's sleeping?

Just using hwMillis() before and after sleep and subtracting one from the other.
It was just reading + 250ms until @d00616 commited some changes a few hours ago.

I thought so. The point being: doesn't millis stop when you're deep sleeping? Well, at least on an Arduino it does. Not sure what it does on the nRF5.

[rmtucker]

@NeverDie
No the nrf5 has a rtc.(Real time Counter)
It can even keep time while sleeping.(just found this out myself!).
That is a great leap forward on the arduino.

[rmtucker]

Try it just print the time out then put it to sleep for a minute then print the time out again.

[rmtucker]

The problem must be this line but i don't speak nrf5.

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

[rmtucker]

The only other thing it could be is the deletion of this line in the commit.

nrf5_rtc_event_triggered = false 

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

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

[NeverDie]

BTW, I assembled my third board now, and it sleeps at about 9.9ua. The first one sleeps at about 6ua, and the second at about 9ua. It would be interesting to know why the first board is so much less, but it seems that about 9-10ua is the more typical number. That also seems to agree with @d00616 's measurements.

[NeverDie]

Interestingly enough, you can put the radio into receive mode and then sleep the mcu with the radio still in receive mode. Here's a screenshot of current consumption while receiving, where I alternate between leaving the mcu active or sleeping it (each for duration of 500ms). In-between, I sleep everything (both radio and mcu) for 1 second:

[NeverDie]

Here's the mode that I'm most interested in: Putting the radio into Rx for about 1ms per 100ms interval to listen for remote commands. The rest of the time everthing (both radio and mcu) are in deep sleep waiting for the RTC to wake them up.

Here's a close-up of the current drawn during that roughly 1ms interval:

I ran this just now, and my solar setup can easily handle this load during the daytime, even from deep indoors far from the windows. This was the scenario that really stressed the RFM69+atmega328p combo when I tried doing it using the RFM69's listen mode. I'll see tonight how the 10F supercap handles the load without any solar assist.

Because of the nRF52839's 2Mbps datarate, I can probably cut the listen window down substantially from 1ms to much less (much less than would be possible with an RFM69, due to its maximum of 300kbps datarate), but for ease of programming I'm starting with this.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Here's the mode that I'm most interested in: Putting the radio into Rx for about 1ms per 100ms interval to listen for remote commands. The rest of the time everthing (both radio and mcu) are in deep sleep waiting for the RTC to wake them up.

When you take a look into the PPI section, you are able to let the CPU sleep until a radio packet is received. With PPI, the listen mode can be activated and deactivated without CPU interaction.

The nRF5 MCUs are able to to a lot of things without waking up the CPU. That's a really cool feature.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

Here's the mode that I'm most interested in: Putting the radio into Rx for about 1ms per 100ms interval to listen for remote commands. The rest of the time everthing (both radio and mcu) are in deep sleep waiting for the RTC to wake them up.

When you take a look into the PPI section, you are able to let the CPU sleep until a radio packet is received. With PPI, the listen mode can be activated and deactivated without CPU interaction.

The nRF5 MCUs are able to to a lot of things without waking up the CPU. That's a really cool feature.

Sounds like it has potential. Any demo code for this? The datasheet seems a bit sketchy.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

@d00616 said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

Here's the mode that I'm most interested in: Putting the radio into Rx for about 1ms per 100ms interval to listen for remote commands. The rest of the time everthing (both radio and mcu) are in deep sleep waiting for the RTC to wake them up.

When you take a look into the PPI section, you are able to let the CPU sleep until a radio packet is received. With PPI, the listen mode can be activated and deactivated without CPU interaction.
The nRF5 MCUs are able to to a lot of things without waking up the CPU. That's a really cool feature.

Sounds like it has potential. Any demo code for this? The datasheet seems a bit sketchy.

These are some snippets of the radio code. There are fully useable PPI and some predefined. For fully useable PPI into the EEP register, you put the address of an EVENT register and in the TEP register, you put the pointer to an TASK register.

   /** Configure PPI (Programmable peripheral interconnect) */
    // Start timer on END event
    NRF_PPI->CH[NRF5_ESB_PPI_TIMER_START].EEP = (uint32_t)&NRF_RADIO->EVENTS_END;
    NRF_PPI->CH[NRF5_ESB_PPI_TIMER_START].TEP = (uint32_t)&NRF5_RADIO_TIMER->TASKS_START;
    // Disable Radio after CC[0]
    NRF_PPI->CH[NRF5_ESB_PPI_TIMER_RADIO_DISABLE].EEP = (uint32_t)&NRF5_RADIO_TIMER->EVENTS_COMPARE[0];
    NRF_PPI->CH[NRF5_ESB_PPI_TIMER_RADIO_DISABLE].TEP = (uint32_t)&NRF_RADIO->TASKS_DISABLE;
    ...
    // Set PPI
     NRF_PPI->CHENSET = NRF5_ESB_PPI_BITS;
    ...
  // Clear PPI
    NRF_PPI->CHENCLR = NRF5_ESB_PPI_BITS;

Then you have to enable or disable the register. It could be necessary to reset the events. You can use the NRF_RESET_EVENT macro to do this job.

 NRF_RESET_EVENT(NRF5_RADIO_TIMER->EVENTS_COMPARE[0]);

[NeverDie]

I have a brute force version of "listen mode" working using just the libraries, but I have to re-initialize the radio after each cycle because it appears to lose its settings every time I sleep it.

Anyway, finding a way to add DCDC mode to these modules will probably have the biggest near-term impact on current consumption. That said, I'm sure plenty of energy savings can also be found by honing the code.

[NeverDie]

Actually, even just sleeping the MCU with a simple command like:

sleep(100);

is apparently enough to require a re-init of the radio afterward. Not sure why that would be.

[NeverDie]

Comparing Figures 169 and 170 in the nRF52832 datasheet, it looks as though simply adding two inductors in series between DCC and DEC4 should be all that's needed to provide the needed hardware support for DC/DC. Looks as though the 10uH inductor also needs to be able to support a minimum of 50ma, according to the BOM (Table 145).

So, is it as simple as that together with enabling register DCDCEN? Or, is there anything more to it?

[scalz]

Yes. This is like that. I use 2 inductors (better) in serie. Why more complicated

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Actually, even just sleeping the MCU with a simple command like:
sleep(100);

is apparently enough to require a re-init of the radio afterward. Not sure why that would be.

sleep() deinitializes the transport with transportDisable(). This results in power down the radio.

At the moment I review the ESB code. I think the nRF5 is 12-13µs after an nRF24 in RX mode and 432µs before an nRF24 in TX. This can result in unstable connections when debug messages are disabled.

[NeverDie]

Sort-of working. Here's a screen shot with the DC/DC modification. Compare to the earlier one above:

Probably non-optimal placement of the inductors: between the DCC and DEC4 pins on my breakout board for the nRF52832.

This is reason enough to do an new version of the breakout for the Ebyte module to improve the inductor positioning.

Here's the enable code:

  NRF_POWER->DCDCEN=1;  //enable the DCDC voltage regulator as the default.

If it's this easy, I'm just surprised that the module makers haven't included it. The difference in build cost is de minimus, but the difference in delivered value is huge.

Also, it sounds like I'll have to write a variant of sleep that sleeps just the MPU while leaving the radio in receive mode. That's an easy win to improve the current consumption.

[NeverDie]

Good news! I went back and re-rechecked using an un-modified Ebyte module, and, indeed, this time I'm sure that the DCDC inductors are already on it! What follows is the proof. Here is the current drawn when the above DCDCEN is enabled on an unmodified Ebyte module:

Now, here is the current drawn with the exact same script on the exact same unmodified Ebyte module, but with the DCDCEN line of code commented out:

QED.

As you can see, the savings in current consumption are considerable with the DCDC enabled!

[Edit: although looking at it again, the timescale seems way off. Argh. Something still isn't right.]

[NeverDie]

Scratch the preceeding post. I redid it more carefully this time, and I believe it confirms that the Ebyte module does not have the two inductors required for DC/DC mode.

Here is the current drawn by an unmodified Ebyte nRF52832 module which is programmed to be receiving for about 1.5ms every 100ms:

[NeverDie]

Here is what happens with exactly the same hardware (no inductors yet added), but with DCDCEN enabled:

It basically seems caught in a boot loop.

[NeverDie]

Now, adding the two inductors between DCC and DEC4, and re-measuring, we get:

No less importantly, it does receive and decode packets!

Conclusion: Ebyte nRF52832 modules don't come with the DC/DC inductors already installed. However, they can be added, resulting in some current reduction.

[NeverDie]

I've baked these findings into a new breakout board for the Ebyte nRF52832:
https://www.openhardware.io/view/471
The new breakout board will enable the module to work in DC/DC mode.

[NeverDie]

I may have found a clue as to why the reset pin (pin0.21) on the nRF52832 isn't working.

On the nRF52832 DK, I read the following register values:
PSELRESET[0]=21
PSELRESET[1]=21

which is as expected. However, on the Ebyte nRF52832 module, I read those register values as:
PSELRESET[0]=4294967295
PSELRESET[1]=4294967295

which makes no sense. The values match, but they don't correspond to a pin number that can represent RESET.

These two registers are described in the nRF52832 datasheet.

[mfalkvidd]

@NeverDie not sure if you've already noticed, but 4294967295 is the maximum value for an unsigned 32-bit integer. So the value is 0xFFFFFFFF. That often means uninitialized. I don't know why it would be uninitialized though.

[NeverDie]

@mfalkvidd

Maybe because they just never were?
Those particular registers are "The user information configuration registers (UICRs) are non-volatile memory (NVM) registers for configuring user specific settings." So, it would seem that initializing them just once would be enough, since they're non-volatile.

In any case, good catch! It explains both why they are that value and also why they match.

[NeverDie]

@NeverDie said in nRF5 Bluetooth action!:

4294967295

Also, since 4294967295 equals 0xFFFFFFFF, then bit 31 is a '1', which, according to the datasheet, means the pin is disconnected (see section 14.1.60 PSELRESET[0] of the datasheet for the detail].

[NeverDie]

@mfalkvidd said in nRF5 Bluetooth action!:

So the value is 0xFFFFFFFF. That often means uninitialized. I don't know why it would be uninitialized though.

There's a chance we may have unwittingly done it ourselves! Remember back to when we were doing an explicit "Erase All"? From the datasheet:

11.5 Erase all
When erase is enabled, the whole Flash and UICR can be erased in one operation by using the ERASEALL
register.

Furthermore, from page 29 of the datasheet:

After erasing UICR all bits in UICR are set to '1'.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

@mfalkvidd said in nRF5 Bluetooth action!:

So the value is 0xFFFFFFFF. That often means uninitialized. I don't know why it would be uninitialized though.

There's a chance we may have unwittingly done it ourselves! Remember back to when we were doing an explicit "Erase All"? From the datasheet:

This is part of the arduino-nrf5 code -> https://github.com/sandeepmistry/arduino-nRF5/blob/dc53980c8bac27898fca90d8ecb268e11111edc1/cores/nRF5/SDK/components/toolchain/system_nrf52.c#L156

I don't have any idea why this is not included in the binary. When the reset menu is selected then "-DCONFIG_GPIO_AS_PINRESET" is given to gcc.

When system_nrf52.c is completely ignored, then the erratas are not handled.

[NeverDie]

Here is some verbose code which properly sets the registers to use pin P0.21 as the RESET pin:

Serial.println("Testing...");
delay(10000);  //give preparation time to open serial tty
Serial.print(counter);
Serial.print(", PSELRESET[0]=");
Serial.println(NRF_UICR-> PSELRESET[0]);
Serial.print(counter++);
Serial.print(", PSELRESET[1]=");
Serial.println(NRF_UICR-> PSELRESET[1]);

Serial.println();
Serial.println("Write-enabling CONFIG.");
NRF_NVMC->CONFIG=1;  // Write enable the UICR

Serial.println();
Serial.println("Now designating pin pO.21 as the RESET pin.");
NRF_UICR-> PSELRESET[0]=21;  //designate pin pO.21 as the RESET pin
NRF_UICR-> PSELRESET[1]=21;  //designate pin pO.21 as the RESET pin

Serial.println();
Serial.println("Confirming that RESET pin assigment took hold:");
Serial.print(counter);
Serial.print(", PSELRESET[0]=");
Serial.println(NRF_UICR-> PSELRESET[0]);
Serial.print(counter++);
Serial.print(", PSELRESET[1]=");
Serial.println(NRF_UICR-> PSELRESET[1]);

Serial.println();
Serial.println("Return CONFIG to read-only mode.");
NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.

Running it once seems to be good enough, unless there were to occur another "Erase All" or "Burn bootloader" event.

Here is the output from running the code which shows that it succeeded:

Testing...
0, PSELRESET[0]=4294967295
0, PSELRESET[1]=4294967295

Write-enabling CONFIG.

Now designating pin pO.21 as the RESET pin.

Confirming that RESET pin assigment took hold:
1, PSELRESET[0]=21
1, PSELRESET[1]=21

Return CONFIG to read-only mode.

[NeverDie]

Until a more elegant solution can be found, I'm using this in the setup() routine as the workaround:

  if (((NRF_UICR-> PSELRESET[0])==0xFFFFFFFF) && ((NRF_UICR-> PSELRESET[1])==0xFFFFFFFF)) { //if the two RESET registers are erased
    NRF_NVMC->CONFIG=1;  // Write enable the UICR
    NRF_UICR-> PSELRESET[0]=21;  //designate pin P0.21 as the RESET pin
    NRF_UICR-> PSELRESET[1]=21;  //designate pin P0.21 as the RESET pin
    NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.
  }

The code has the positive virtue of not writing to the RESET rregisters unless both registers are erased. That helps ensure that the non-volatile memory does not get worn out prematurely.

[NeverDie]

@NeverDie said in nRF5 Bluetooth action!:

Until a more elegant solution can be found, I'm using this in the setup() routine as the workaround:

  if (((NRF_UICR-> PSELRESET[0])==0xFFFFFFFF) && ((NRF_UICR-> PSELRESET[1])==0xFFFFFFFF)) { //if the two RESET registers are erased
    NRF_NVMC->CONFIG=1;  // Write enable the UICR
    NRF_UICR-> PSELRESET[0]=21;  //designate pin P0.21 as the RESET pin
    NRF_UICR-> PSELRESET[1]=21;  //designate pin P0.21 as the RESET pin
    NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.
  }

The code has the positive virtue of not writing to the RESET rregisters unless both registers are erased. That helps ensure that the non-volatile memory does not get worn out prematurely.

Good news! I've confirmed that doing this does indeed solve the problem I previously had with the EByte nRF52832 module not reacting to a reset on pin P0.21. After inserting the above code block into the nRF52832's setup() routine, I can now, using ESP-LINK, remotely reset an nRF52832 module:
https://www.openhardware.io/view/443/nRF52832-ESP-LINK-Shield-for-ESP8266-Wemos-D1-Mini

[NeverDie]

With that issue now settled, I'm moving on to a different topic: what happens if you put the radio into Tx mode, but with an empty buffer (i.e. nothing to send)? In this scenario an RFM69 transmits a continuous pre-amble, and I'm wondering whether the nRF52832 does the same?
With an empty buffer, does it transmit anything at all? Anyone happen to know?

The reason I ask is that I want to program the radio to send a continuous signal so as to quickly wake-up a receiver. With packets, there's the lag time of receiving and decoding the packet, rather than just reacting to a high RSSI. In this way, I can use much narrower listen windows and thereby save a lot of current consumption.

[NeverDie]

According to the datasheet, the typical RSSI sample period is just 0.25us. However, what spoils that a bit is that the radio has to come up to speed beforehand.

Anyhow, on the receive side, I now have at least that much working.

[NeverDie]

It looks as though the start-up time for the radio is about 390us. So, it does save a lot of current to first check the RSSI level rather than to always listen for a packet.

[NeverDie]

When I measure RSSI on the nRF52832, I get what seems like a rather odd range of values: between about 94 and 127. If I have no other nodes transmitting, then the RSSI is generally around 100. If I set up another node which deliberately transmits on the same channel, then the RSSI is pegged at 127.

Is that what others here are also seeing? Here's the test code:

uint8_t theRSSI;
void loop() {
  
NRF_RADIO->TASKS_RXEN=1;  //start revving up the receiver
while (!(NRF_RADIO->EVENTS_READY)) {} //busy-wait until radio ready to receive
NRF_RADIO->TASKS_RSSISTART=1;  //Take exactly one RSSI sample
while (!(NRF_RADIO->EVENTS_RSSIEND)) {}  //Busy-wait until RSSI sample is completed.
theRSSI = NRF_RADIO->RSSISAMPLE;

Serial.println(theRSSI);
Serial.flush();
sleep(1000);
}

[NeverDie]

Unfortunately, when I use the above code block and test the current using an oscilliscope, it becomes clear that the radio never actually goes to sleep:

So, to do that, I add the line:

NRF_RADIO->TASKS_DISABLE=1;  //turn-off the radio

just prior to sleep(100). Doing that largely eliminates the current drain while sleeping:

However, if I do that, then the RSSI that gets reported is always 127. Why? Do I need some other way to check the radio states? Maybe STATE from section 23.14.25 STATE of the datasheet would work better?

[NeverDie]

Found a breakout board for the nRF51822-04: https://oshpark.com/shared_projects/zqDQaykJ

[NeverDie]

The datasheet is possibly a bit misleading when it says:

For the RSSI sample to be valid the radio has to be enabled in receive mode (RXEN task) and the reception
has to be started (READY event followed by START task).

I'm finding that the radio needs to be in either RXIDLE state or RX state to get a plausible RSSI measurement. I can't get a reasonable RSSI measurement while within the RXRU state.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

The datasheet is possibly a bit misleading when it says:

For the RSSI sample to be valid the radio has to be enabled in receive mode (RXEN task) and the reception
has to be started (READY event followed by START task).

I'm finding that the radio needs to be in either RXIDLE state or RX state to get a plausible RSSI measurement. I can't get a reasonable RSSI measurement while within the RXEN state.

In the ESB code, I use the bitcounter event to start the rssi sample task via PPI. The results are looking plausible.

[NeverDie]

I've found that I get a slightly stronger RSSI signal by about 3dB if I measure it while in the RX state rather than the RXIDLE state.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

In the ESB code, I use the bitcounter event to start the rssi sample task via PPI. The results are looking plausible.

Do you know of any good PPI tutorials? The datasheet seems awfully skimpy on its explanation of exactly how to use it.

Right now I have RSSI triggers working on the receiver (presently using the MCU, not PPI), but it takes 1400 samples to guarantee not missing any transmissions. That's because of the gap between single shot packets when they get sent. If I can reduce that to one sample, by finding a way to make a transmitter transmit continuously, then that will save a lot of energy on the receiver.

There is a way to do more rapid fire transmission of packets, so that would be the fall-back plan if I can't find a way to, for example, send a continuous preamble.

[NeverDie]

Answering my own question: it turns out that if you enter into TX mode without any payload, it just sends a null packet and returns to TXIDLE. So, it is not like the RFM69, which would simply send an indefinitely long preamble until there's a payload to send.

The goal is to close the gap between packets as much as possible. So, I'm getting some improvement by just immediately switching back into TX mode (to send another null packet) the moment I've confirmed that TXIDLE state has re-occured.

[NeverDie]

As it turns out, using the above method packs the null packets so tightly that I can rely on a single RSSI measurement (instead of 1400 of them) to guarantee that a transmission won't be missed. So, the goal is achieved.

It sounds as though combining PPI with this would drive the energy consumption even lower!

[d00616]

@NeverDie Thank you sharing your experience here. It helps me of better understanding some nRF5 internals. It would be awesome if you share your code.

@NeverDie said in nRF5 Bluetooth action!:

Do you know of any good PPI tutorials? The datasheet seems awfully skimpy on its explanation of exactly how to use it.

To understand PPI you have to be in mind that nearly everything is driven by tasks and events. If you want to do something, you have to start a task like 'NRF_RADIO->TASKS_TXEN=1'. If a task ends it generates an event like 'NRF_RADIO->EVENTS_READY'. You can replace NRF_RADIO with another periphery the registers have an equal naming scheme.

For an event an Interrupt can be enabled with the NRF_RADIO->INTENSET register. Each event correspondents with a bit in that register. In an interrupt, you have to reset the NRF_RADIO->EVENTS_READY register to 0 to allow triggering a new interrupt. For compatibility, you can use the NRF_RESET_EVENT macro in interrupts. This reads back the register on nRF52 to avoid caching effects. Interrupts doesn't matter for PPI

The next fine thing are Shortcuts. Shortcuts are limited to the same peripheral unit. Bits in the NRF_RADIO->SHORTS register are corresponding to a connection between an event and a test. If the event is triggered the task is started. This allows to trigger things like send an packet after the radio is ready. To use this, you have to enable the shortcut in the NRF_RADIO->SHORTS register.

To break the limits of shortcuts, there is the PPI unit with 32 channels. Some of the channels are predefined but interesting to see how things are implemented with BLE. The other PPI channels are flexible. To use one of these channels, you have to write a pointer of your event register, like '(uint32_t)&NRF_RADIO->EVENTS_END' to the NRF_PPI->CH[YOUR_CHANNEL].EEP register and a pointer to your task you want to start in the NRF_PPI->CH[YOUR_CHANNEL].TEP register like '(uint32_t)&NRF_TIMER0->TASKS_START'. Then you have to enable the PPI channel by setting the corresponding bit like 'NRF_PPI->CHENSET |= (1 << COUR_CHANNEL)' that's all.

The nRF52, but not the nRF52 comes with NRF_PPI->FORK[YOUR_CHANNEL].TEP registers. in my reading you can start a second task with this register like writing to NRF_PPI->CH[YOUR_CHANNEL].TEP.

I have no idea about using the PPI Groups.

Arudino provides a PPI library for the primo: http://cdn.devarduino.org/learning/reference/ppi I think we have to use this library to be compatible in the future. I hope there is a chance to port things to arduino-nrf5 back.

Edit: The arduino PPI library is not flexible enough to support radio events.

[NeverDie]

Thanks! At least notionally, the PPI sounds excellent. Presently, if I want to move the radio into a particular state which takes a few state changes to get there, using the MCU with a conservative coding style, I have to initiate the first state change, then busy-wait until the new state is confirmed, then make the next state-change, etc. It sounds as though the PPI is a good fit for this, because it would eliminate the busy-waits. It would automatically transition from one state to the next using just the interrupt scheme you outlined until the target state is reached. Well, at least in theory. Meanwhile the CPU could be doing other things or sleeping. This does sound like a definite improvement, especially for more efficient control over the radio.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@NeverDie Thank you sharing your experience here. It helps me of better understanding some nRF5 internals. It would be awesome if you share your code.

Here it is:

#include <MySensors.h>
#include <nrf.h>

void setup() 
{
  NRF_POWER->DCDCEN=1;  //enable the DCDC voltage regulator as the default.

  //guarantee RESET pin is working
  if (((NRF_UICR-> PSELRESET[0])==0xFFFFFFFF) && ((NRF_UICR-> PSELRESET[1])==0xFFFFFFFF)) { //if the two RESET registers are erased
    NRF_NVMC->CONFIG=1;  // Write enable the UICR
    NRF_UICR-> PSELRESET[0]=21;  //designate pin P0.21 as the RESET pin
    NRF_UICR-> PSELRESET[1]=21;  //designate pin P0.21 as the RESET pin
    NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.
  }

  NRF_RADIO->FREQUENCY=123;
  NRF_RADIO->MODE=2;  //set 250kbps datarate.  May as well stretch out the NULL packet as much as possible.
  
  NRF_RADIO->TASKS_DISABLE=1;  //turn-off the radio to establish known state.
  while (NRF_RADIO->STATE!=0) {}  //busy-wait until radio is disabled
  NRF_RADIO->TASKS_TXEN=1;  //wake-up the radio
  while ((NRF_RADIO->STATE)!=10) {}  //busy-wait until radio has started TXIDLE
  
  //Assertion: radio is now in TXIDLE state.
}


void loop() {

    //assume radio is in TXIDLE state.
    NRF_RADIO->TASKS_START=1;  //Move from TXIDLE state to TX state.  This sends a NULL packet.
    while ((NRF_RADIO->STATE)!=11) {}  //busy-wait until radio is in TX state
    while ((NRF_RADIO->STATE)==11) {}  //busy-wait until radio is back to TXIDLE state
    //Assertion: radio is now back to TXIDLE state
 }