Clarification on tRXCHAIN and EVENTS_ADDRESS Timing in BLE 1M

[Xin He]

Hello,

I am trying to understand how the documented tRXCHAIN value relates to the timing of EVENTS_ADDRESS in BLE 1M mode.

In this DevZone ticket:

https://devzone.nordicsemi.com/f/nordic-q-a/83778/undocumented-tx---rx-radio-delay/570863

the measured receiver delay from TASKS_START to EVENTS_ADDRESS is 49.568–49.844 µs. The reply states that EVENTS_ADDRESS is generated approximately 8–9 µs after the last access-address bit has been received. The nRF52840 Product Specification also lists tRXCHAIN as 9.4 µs.

I am confused because, if tRXCHAIN and the stated 8–9 µs address-decoding delay are two separate serial delays, the expected timing would be approximately:

0.6 µs TX chain delay + 40 µs preamble and access address + 9.4 µs tRXCHAIN + 8–9 µs decoding delay = 58–59 µs.

This does not match the measured 49.5–49.8 µs.

Could you please clarify whether the 8–9 µs delay from the final access-address bit to EVENTS_ADDRESS is the documented tRXCHAIN, or whether these delays overlap? Alternatively, does tRXCHAIN only apply to chained consecutive packets and not to this single-packet measurement?

I need to understand the timing of EVENTS_ADDRESS for radio synchronization.

Thanks in advance.

Best regards,
Xin He

[Amanda Hsieh]

Hi, 

Could you please clarify whether the 8–9 µs delay from the final access-address bit to EVENTS_ADDRESS is the documented tRXCHAIN

Yes, they describe the same physical delay, not two separate stages. 

whether these delays overlap?

Yes. You should not add them.

does tRXCHAIN only apply to chained consecutive packets and not to this single-packet measurement?

For your single-packet synchronized measurement, tRXCHAIN is embedded in the post-access-address delay, not an additional term.

Regards,
Amanda H.