Radio registers and radio performance

[Rob Garner]

Hi there.

First of all, Happy New Year!

I am currently creating a product using the nRF52811 chip, together with a proprietary radio protocol (in other words, I am not using a SoftDevice) using the 1Mbit BLE PHY. In general, the communication is working well. However, I am getting a lot of corrupted packets due to interference issues. The interference is of course to be expected, as the radio is operating in the 2.4GHz ISM band, and I do also have wi-fi routers at my location, and possibly in nearby locations. I am currently debugging the corrupted packet issue, and there are several items I need to examine more closely (such as turning off the wi-fi, etc). One of these items is the way I am setting up the radio registers themselves. 

In order to get an idea of the best way to set them up I loaded the "gzll_ack_payload_device_pca10040" project onto a PCA10040 Eval board. It compiled without issues. I programmed the board, and then let the program run for a few seconds in the debugger. I then paused program execution, and I looked at the radio registers in a Memory window (I realize that the chip on the Eval board is an nRF52832, but the register structure seems to be very similar to the nRF52811). I then noticed that quite a few undocumented registers, especially in the address space starting at 0x40001700, are being written with certain values (see screenshot below):

So my questions are as follows:

- What are these registers?

- Do they impact the functionality of the radio in terms of optimal performance?

- If so, is there additional information available?

Thanks for the help

Rob 

[Daniel Veilleux]

Howdy! That looks like a fun approach but I'd recommend coming at it from the opposite direction; Take a look at the radio initialization code in the SDK's nrf_esb module ("{SDK_ROOT}/components/proprietary_rf/esb/nrf_esb.c") -- everything you need to use the radio is out in the open, gazell just adds timing and higher-level protocol interactions.

[Rob Garner]

Hi Daniel

Thanks for the reply. I did look at the code, as you suggested. I'm doing pretty much everything in that code (and some additional things as well). Looking forward to what Tech Support will say regarding my question.

Cheers

Rob

[ovrebekk]

Hi Rob

There are various undocumented registers in the part, yes. 

When the hardware peripherals are designed the designers will typically put in more control and status registers than strictly required. Any register that is not required for normal operation of the peripheral will not be documented, but having these registers available can be very useful in case of unexpected hardware issues. Some of the hardware issues listed in the part erratas can be fixed by writing to undocumented registers, such as this one. 

- What are these registers?

Being undocumented I can't really go into details on specific registers ;)

- Do they impact the functionality of the radio in terms of optimal performance?

As long as you leave them alone they will not. If you write something to them it might affect performance, yes. 

I agree with Daniel that the ESB library might be a better place to start in terms of evaluating a proprietary RF implementation. If nothing else you can use it as a comparison to your own implementation, and see if you see the same amount of packet loss. 
Typically you would use different mechanisms, such as ACK packets, retransmissions, and frequency jumping, to get around issues with interference. 

Best regards
Torbjørn

[Rob Garner]

Hi Ovrebekk

Thank you for the quick response. So, according to your statement, I will assume that there are no radio calibration registers that need to be written before the radio is used (this may perhaps be taken care of by software automatically if I were to use the stacks provided by Nordic?). I do indeed use ACK packets, retransmissions and frequency hopping, as well as CRC, etc. What I am seeing in general is that usually only a few bits fall over, so I am "close". 

It may be perhaps related to the radio timing I have implemented. Let me explain in a little more detail how I have implemented the radio timing:

The receiving device (Slave) will trigger the TASKS_RXEN task 150us before the transmitting device (Master) begins transmission, in order to provide a 140us ramp up time, Then, 10us before the Master starts the transmission the Slave will trigger the TASKS_START in order to start the receiver. I do this in order to minimize the reception of an unwanted preamble. When the Slave then transmits data to the Master the same timing also applies. 

However, the 10us timing may be too short, and the receiver may not actually be fully ready within 10us after the TASKS_START, thereby impacting reliability of the data transmission. I do not see any timing specs in the data sheet for this phase of the radio timing. Do you see any issues with the way I have implemented the timing?

Thanks

Rob

[ovrebekk]

Hi Rob

Rob Garner said:

So, according to your statement, I will assume that there are no radio calibration registers that need to be written before the radio is used

That is correct. 

The ESB library is provided with full source, if you take a look at it you will see that only the standard registers are accessed (to configure packet format, address, channel etc). 

Rob Garner said:

What I am seeing in general is that usually only a few bits fall over, so I am "close". 

This makes sense. If the interference was more severe you would most likely get bit errors in the address as well, and at that point the packet wouldn't be received at all (you need a valid address match for the packet reception to start). 

Rob Garner said:

Do you see any issues with the way I have implemented the timing?

It should take significantly less than 10us for reception to start once the READY event has occurred, so I doubt this is the issue. 

One question is how certain you are that the two devices are properly synchronized? 

Clock drift will cause the timestamp on each side to drift over time, and it is necessary to reset the timing at regular intervals to keep the two devices in sync. 

A common way of debugging these kinds of protocols is to use the PPI and GPIOTE peripherals to connect radio events to GPIO pins. Then you can track the events on a scope and get accurate information about the timing of the events on the TX and RX side. 

Best regards
Torbjørn