nRF5 action!

d00616

@NeverDie said in nRF5 Bluetooth action!:

What's the best way to awaken the radio after sleeping it though? I've tried:

This depends on the implementation. Sorry, at the moment I have not time to look into the RadioHead code in that detail. You can try to initialize the library again.

d00616

@NeverDie Here is a snippet to dump all registers, hope it's help to analyze whats going wrong with RadioHead:

Serial.print("NRF_RADIO->EVENTS_READY  ");
Serial.println(NRF_RADIO->EVENTS_READY, HEX);
Serial.print("NRF_RADIO->EVENTS_ADDRESS  ");
Serial.println(NRF_RADIO->EVENTS_ADDRESS, HEX);
Serial.print("NRF_RADIO->EVENTS_PAYLOAD  ");
Serial.println(NRF_RADIO->EVENTS_PAYLOAD, HEX);
Serial.print("NRF_RADIO->EVENTS_END  ");
Serial.println(NRF_RADIO->EVENTS_END, HEX);
Serial.print("NRF_RADIO->EVENTS_DISABLED  ");
Serial.println(NRF_RADIO->EVENTS_DISABLED, HEX);
Serial.print("NRF_RADIO->EVENTS_DEVMATCH  ");
Serial.println(NRF_RADIO->EVENTS_DEVMATCH, HEX);
Serial.print("NRF_RADIO->EVENTS_DEVMISS  ");
Serial.println(NRF_RADIO->EVENTS_DEVMISS, HEX);
Serial.print("NRF_RADIO->EVENTS_RSSIEND  ");
Serial.println(NRF_RADIO->EVENTS_RSSIEND, HEX);
Serial.print("NRF_RADIO->EVENTS_BCMATCH  ");
Serial.println(NRF_RADIO->EVENTS_BCMATCH, HEX);
Serial.print("NRF_RADIO->CRCSTATUS  ");
Serial.println(NRF_RADIO->CRCSTATUS, HEX);
Serial.print("NRF_RADIO->RXMATCH  ");
Serial.println(NRF_RADIO->RXMATCH, HEX);
Serial.print("NRF_RADIO->RXCRC  ");
Serial.println(NRF_RADIO->RXCRC, HEX);
Serial.print("NRF_RADIO->DAI  ");
Serial.println(NRF_RADIO->DAI, HEX);
Serial.print("NRF_RADIO->PACKETPTR  ");
Serial.println(NRF_RADIO->PACKETPTR, HEX);
Serial.print("NRF_RADIO->FREQUENCY  ");
Serial.println(NRF_RADIO->FREQUENCY, HEX);
Serial.print("NRF_RADIO->TXPOWER  ");
Serial.println(NRF_RADIO->TXPOWER, HEX);
Serial.print("NRF_RADIO->MODE  ");
Serial.println(NRF_RADIO->MODE, HEX);
Serial.print("NRF_RADIO->PCNF0  ");
Serial.println(NRF_RADIO->PCNF0, HEX);
Serial.print("NRF_RADIO->PCNF1  ");
Serial.println(NRF_RADIO->PCNF1, HEX);
Serial.print("NRF_RADIO->BASE0  ");
Serial.println(NRF_RADIO->BASE0, HEX);
Serial.print("NRF_RADIO->BASE1  ");
Serial.println(NRF_RADIO->BASE1, HEX);
Serial.print("NRF_RADIO->PREFIX0  ");
Serial.println(NRF_RADIO->PREFIX0, HEX);
Serial.print("NRF_RADIO->PREFIX1  ");
Serial.println(NRF_RADIO->PREFIX1, HEX);
Serial.print("NRF_RADIO->TXADDRESS  ");
Serial.println(NRF_RADIO->TXADDRESS, HEX);
Serial.print("NRF_RADIO->RXADDRESSES  ");
Serial.println(NRF_RADIO->RXADDRESSES, HEX);
Serial.print("NRF_RADIO->CRCCNF  ");
Serial.println(NRF_RADIO->CRCCNF, HEX);
Serial.print("NRF_RADIO->SHORTS  ");
Serial.println(NRF_RADIO->SHORTS, HEX);

NeverDie

@d00616
I did a bit more poking around, and I've confirmed that there's no need to re-enable the radio before transmitting. Apparently doing the transmission and returning to disabled mode happens automatically. In fact, I think this is the expected behavior, as indicated by Figure 35 of the datasheet.

NeverDie

So, under this theory, the only time when the radio is not disabled is when it is actively transmitting or receiving. There's no need to manually disable it, because that appears to happen automatically anyway.

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.

nRF5 action!

19

11.7k

11.2k

113.0k