Undocumented TX - RX radio delay

[Fmag]

Hello,

I am using the nRF52840 DK (same applies also for the dongle). The setup is quite simple. I have two nodes on my desk, one transmitting packets and the other receiving. Via PPI, I connect some of the radio events, such as FRAMESTART, END (in 802.15.4 mode), or ADDRESS, PAYLOAD (in BLE modes), to GPIO pins and observe them with a logic analyzer. I can see a constant delay for the same events between transmitter and receiver. This delay depends on the data rate and is about 10 bit times in each mode. For example, in 802.15.4 mode (250kbps) the delay between the FRAMESTART (or END) events between transmitter and receiver is always around 40 us. I have the impression that the delay is evenly distributed between the receive and transmit paths, without being sure. Can someone explain this delay to me? Are there buffers in the radio which cause this delay or does this somehow relate to the EasyDMA, which the radio uses?

Thanks in advance.

[ovrebekk]

Hi 

Those are interesting findings, thanks for sharing. I have asked the hardware team for some input on this, and will get back to you once I hear back from them. 

Best regards
Torbjørn

[ovrebekk]

Hi

The hardware team did some investigation and found that in transmit EVENTS_ADDRESS is generated when the last address bit starts to leave the RADIO, rather than after it is fully transmitted. 

There is also a very short delay from TASKS_START until the first bit starts transmitting. In other words the 39.25us delay that you measured is correct. 

Best regards
Torbjørn

[car]

Hi Torbjørn,

Thanks a lot for these informations, they are very helpful.

Regarding EVENTS_ADDRESS, is it the same at the receiver, or does the receiver generate the event after the last bit has been received?

Is it possible to quantify the very short delay after TASKS_START?

I know, asking for such details sounds weird, but they are important in the context of high-precision time synchronization.

Best
car

[ovrebekk]

Hi Car

I have forwarded your questions to the designers, and will let you know once I hear back from them. 

Best regards
Torbjørn

[ovrebekk]

Hi again

car said:

Regarding EVENTS_ADDRESS, is it the same at the receiver, or does the receiver generate the event after the last bit has been received?

During reception EVENTS_ADDRESS is generated when the correct address has been decoded. This is some time after the last address bit has been received (approximately 8-9us). In reception there is no fixed relation between this event and the bits on air, since there are various factors that affect the time it takes to decode the address (such as the signal quality). 

car said:

Is it possible to quantify the very short delay after TASKS_START?

This delay is referred to as the TX chain delay, and is approximately 0.6us. 

car said:

I know, asking for such details sounds weird, but they are important in the context of high-precision time synchronization.

I will do what I can to help with your questions, but if you are doing high-precision time sync I would not recommend relying on theoretical numbers alone. Make sure you do the sufficient testing to very that you can get the level of accuracy you require. 

A common way to test time sync algorithms is to toggle a GPIO repeatedly on each of the devices (at a pre-determined point in time), and check with a scope how little jitter and delay there are between the different devices. 

Best regards
Torbjørn