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 

I reproduced your findings in 2M mode, and will check with the hardware team if they can shed some light on this delay. 

As soon as I hear back from them I will let you know. 

Best regards
Torbjørn

[ovrebekk]

Hi again

Apparently your findings are normal, but since we don't characterize or document this delay it is limited how much information there is to share. 

Most of the data processing on the receive side is clocked at the same speed as the RF bitrate, and as such the processing delay will to a large extent scale with the bitrate as you have discovered. There is also some constant delay that doesn't vary with the bitrate, but the magnitude of this delay is significantly smaller. 

Best regards
Torbjørn

[Fmag]

Hi,

thanks for your answer. Based on my findings I had the impression that the delay is distributed between transmitter and receiver paths but based on what you write it sounds more like the delay is completely on the receiver side. Do I understand this correctly? Can you quantify the constant delay, even if it is much smaller?

Cheers

[ovrebekk]

Hi 

The difference you measure in timing between the events on the TX and RX side should be the RX delay only, that is correct. 

Fmag said:

Can you quantify the constant delay, even if it is much smaller?

Somewhere around 500-1000ns I believe. 

Best regards
Torbjørn

[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