nRF5 action!

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
alt text

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
 }

NeverDie

So, to make the above code work as a PPI, all I would need is some kind of linkage such that whenever the "event" of TXIDLE occurs, then a "task" (in this case it would be TASKS_START) is executed to move the radio back into the TX state.

Hmmm.. Still not obvious though from just the datasheet how to actually setup even that simple linkage.

d00616

@NeverDie said in nRF5 Bluetooth action!:

So, to make the above code work as a PPI, all I would need is some kind of linkage such that whenever the "event" of TXIDLE occurs, then a "task" (in this case it would be TASKS_START) is executed to move the radio back into the TX state.

This is a use case for shortcuts. PPI is not required.

There is no TXIDLE event but looking at the state diagram is TXIDLE a result of ether READY or END event. You can enable following shortcurts:

NRF_RADIO->SHORTS = RADIO_SHORTS_READY_START_Msk | RADIO_SHORTS_END_START_Msk;

In PPI this should be the code (untested):

#define CHANNEL (1)
NRF_PPI->CH[CHANNEL].EEP = (uint32_t)&NRF_RADIO->EVENTS_END;
NRF_PPI->CH[CHANNEL].TEP = (uint32_t)&NRF_RADIO->TASKS_START;
NRF_PPI->CH[CHANNEL+1].EEP = (uint32_t)&NRF_RADIO->EVENTS_READY;
NRF_PPI->CH[CHANNEL]+1.TEP = (uint32_t)&NRF_RADIO->TASKS_START;
NRF_PPI->CHENSET = (1 << CHANNEL) | (1 <<( CHANNEL+1));

NeverDie

Thanks! That helps my understanding quite a bit. I've tested the following shortcut code, and it works:


#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->SHORTS = B100001;  //Implement shortcuts: READY_START and END_START
  NRF_RADIO->TASKS_TXEN=1;  //wake-up the radio transmitter and move it into state TXIDLE.

  //The shortcuts will take-over the moment the state TXIDLE becomes activated.
}


void loop() {

}

NeverDie

Is there any example code which illustrates the use of interrupts on the nRF52832?

NeverDie

Looks as though it should be possible to send tightly packed meaningful packets, not just null packets, using almost the same methodology.

d00616

@NeverDie said in nRF5 Bluetooth action!:

Is there any example code which illustrates the use of interrupts on the nRF52832?

Yes. In a sketch, you have to put the interrupt routine into one line. You can define the interrupt only once. If you want to use the radio ISR, you can't enable the radio in MySensors.

https://github.com/sandeepmistry/arduino-nRF5/issues/52

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

NeverDie

Interestingly enough, it turns out all I need to do is transmit one packet, and afterward just leave the radio in TXIDLE mode. That's because, as indicated in the datasheet, it transmits a carrier wave of one's (or any pattern you program) after the packet, expecting that another packet will be sent soon. This is illustrated in Figure 37 of the DS.

NeverDie

So, I've got the transmit side of this problem figured out. Next up: the receiver side, which already works using the MCU.
The next step will be to see whether I can setup timed events from the RTC which can be used to trigger the PPI to measure the RSSI without waking up the MCU. Also, I'll need some way for the PPI to evaluate the magnitude of the RSSI without involving the MCU. Ideally it would also trigger a Rx sequence if the RSSI is above threshold and wake the MCU if something gets received. Not sure how much of this will be possible, but that's the wish list.

I'd say the energy consumption is already pretty good after switching to the RSSI paradigm, but if this succeeds, then it may cut what remains of the energy consumption roughly in half. At that point, I think we will have wrung just about every possible bit of efficiency out of this radio, with the remaining to-do's as mostly mop-up and maybe some fine tuning (e.g. to better mitigate against false positives on the RSSI threshhold trigger).

nRF5 action!

15

11.7k

11.2k

113.0k