nRF5 action!

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

After Sleep transportReInitialise() is called. Then you have to initialize RadioHead again.

So, even with RAM retention active while sleeping, each time the radio is awoken, it needs to be re-initialized?

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

So, even with RAM retention active while sleeping, each time the radio is awoken, it needs to be re-initialized?

The Radio has to be initialized after power down. This doesn't depend on RAM retention.

[NeverDie]

According to Table 39 of the mRF52832 datasheet, there is only one radio state resembling sleep, and that is the DISABLED radio state where "No operations are going on inside the radio and the power consumption is at a minimum."

Apparently the radio is disabled through register TASKS_DISABLE, offset 0x010, Disable RADIO, as indicated by Table 41 register overview.

[NeverDie]

But how exactly does one read or write to these registers? It looks like a quite different arrangement than writing to registers for an nRF24 or an RFM69 or a LoRa chip.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

But how exactly does one read or write to these registers? It looks like a quite different arrangement than writing to registers for an nRF24 or an RFM69 or a LoRa chip.

You have to include nrf.h. To disable the radio, you can do this:

https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/Radio_ESB.cpp#L264

If your transmitting power is 0dbm, then "TX only run current PRF = 0dBm" with 11.6 mA is near the calculated current, when the radio stays in TX mode after sending the data.

[NeverDie]

@d00616
Will this block of code guarantee that the radio is disabled?

  Serial.println("Testing whether radio is disabled...");
  Serial.print("NRF_RADIO->EVENTS_DISABLED=");
  Serial.println(NRF_RADIO->EVENTS_DISABLED);
  while (!(NRF_RADIO->EVENTS_DISABLED)) {
    Serial.print("NRF_RADIO->EVENTS_DISABLED=");
    Serial.println(NRF_RADIO->EVENTS_DISABLED);
    NRF_RADIO->TASKS_DISABLE = 1;  //sleep the radio
  }
  Serial.println("Radio disabled.");

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Will this block of code guarantee that the radio is disabled?

This one is better:

if (NRF_RADIO->STATE != RADIO_STATE_STATE_Disabled) {
	NRF_RADIO->TASKS_DISABLE = 1;
}

[d00616]

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

[NeverDie]

@d00616
That works. Thanks!

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

    NRF_RADIO->TASKS_START  = 1;  //awaken the radio

and

    NRF_RADIO->TASKS_TXEN  = 1;  //awaken the radio

and neither seems to have an effect. The radio stays disabled.

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