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.

[car]

Hi there

I performed some similar experiments, they also show the 10 bit times delay. However, there seem to be more issues. Would be nice if you have a look and shed some light on it.

My setup is as follows:

• two DK boards on my desk (near to each other, so time of flight is negligible), radio mode = BLE 1M
• TASKS_START triggered manually (after radio ramp-up) via PPI (no shortcut used), also route this PPI channel to GPIO (FORK TEP, so no extra delay)
• EVENTS_ADDRESS connected to another GPIO via PPI (i.e., 1 PCLK16M cycle PPI delay from event to pin)
• pins of both boards connected to logic analyzer

My expectation regarding START -> ADDRESS delays:

• transmitter: delay = 40us + 1/16us + small constant (8 bit preamble + 32 bit access address + 1 cycle PPI delay + constant delay inside radio)
• receiver: delay = 40us + 1/16us + small constant + uncertainty < 1/16...0.5us (the latter due to limited radio bandwidth and asynchronous clocks of the two boards)

At the receiver, I measured delays between 49.568us and 49.844us -> about 10 bit times extra delay.

At the transmitter, I measure rather constant 39.25us. What's this? If EVENTS_ADDRESS really signals "Address sent or received" (citing 4413_417 v1.2 6.20.14.15), how can the event appear before 40 bit times have passed? Since the radio cannot predict TASKS_START, the only explanation I see is that the event gets generated right before address has been sent indeed.

Can you please clarify what's going on here? At which point in time / in the radio bitstream does the transmitter really generate EVENTS_ADDRESS? Does the receiver also generate the event time-shifted? By how much? Does the time depend on the bitrate?

Since it is related: What is the delay between TASKS_START and the first preamble bit on air?

Thanks for your support

[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