nRF52840 DK - real TIFS inaccurate with Long Range

[JGounon]

Hi,

I am using the TIFS register of the NRF RADIO to define the interframe spacing timing.
(Done with the following line)

NRF_RADIO->SHORTS |= RADIO_SHORTS_DISABLED_TXEN_Msk; // or NRF_RADIO->SHORTS |= RADIO_SHORTS_DISABLED_RXEN_Msk;
NRF_RADIO->TIFS     = 150;

During a 1Mbit or 2Mbit connection, the real TIFS observed on the sniffer is quite accurate (~150.25us observed).
However, in LE Coded PHY with different Coded PHY, the real TIFS is inaccurate (TX: S=2, RX: S=8): TIFS observed 161.375us  and (TX: S=8, RX: S=2): TIFS observed 146.5us 

I am using a nRF52840 DK (PCA10056 v1.0.0).
Do you have any idea of what may impact this timing and how could I avoid this behavior ? 

Thank you.

[Sigurd]

Hi,

Can you check that the HFCLK with crystal oscillator(HFXO) is running ?

[JGounon]

Thank you for your answer ! 

I used the following lines to start the HFXO.  

    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_HFCLKSTART = 1;
    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

Then when the connection is established with LE Coded PHY, I checked the NRF_CLOCK->HFCLKRUN (=0x00000001) and NRF_CLOCK->HFCLKSTAT (=0x00010001)  registers and they indicates that the HFCLK is running with the HFXO 64 MHz crystal oscillator.

Is there something more that I should check ? 

Thank you.

[JGounon]

Good point, I didn't write this part in the code snippet but the shortcuts configuration is done before the TIFS configuration :

    NRF_RADIO->SHORTS           = RADIO_SHORTS_READY_START_Msk |
                                  RADIO_SHORTS_END_DISABLE_Msk;
    ... 
    
    NRF_RADIO->SHORTS |= RADIO_SHORTS_DISABLED_TXEN_Msk; 
    //or NRF_RADIO->SHORTS |= RADIO_SHORTS_DISABLED_RXEN_Msk; depending on the next operation chosen
    NRF_RADIO->TIFS     = 150;

Without those shortcuts the TIFS doesn't work with the 1Mbps or 2Mbps neither. 
In my case, the timing are always good, except with different LE Coded Coding Sheme. 

[Sigurd]

JGounon said:

In my case, the timing are always good, except with different LE Coded Coding Sheme.

 Ok. I have asked the team internally if they have seen this issue before. I will get back to you with a reply when I know more. 

[Sigurd]

We have seen similar behavior for asymmetric links previously. It’s still under investigation. For the asymmetric use-case, I suggest trying to update/modify the TIFS register with a different value, so that you observe 150 us.

[JGounon]

Thanks a lot for the update.
Indeed that's the work-around we are using for now, but it doesn't work when we don't know the remote device coding sheme (RX with S=2 or S=8 impacts the TIFS value). 
Please let me know, once you have more information about it, thank you.

[Sigurd]

You should be able to tell what TX mode the peer is using by monitoring the PDUSTAT CISTAT field for incoming packets. (Note: peer is allowed to dynamically switch between S8/S2 without notification, so T_IFS calculation would have to be checked upon every received packet. You set the TIFS register to a specific value when preparing the Tx packet.)

Another option is to enable an interrupt on EVENTS_RATEBOOST. Write a TIFS value for S=2 to the TIFS register when starting the radio for BLE LR. If EVENTS_RATEBOOST (this happens during the reception of a frame in S=8!) is generated the software should update the TIFS register to the value for S=8.

Update of the TIFS register takes immediate effect. It is recommended to update as early as possible.