This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

[NRF52840] Early BLE radio events

Hello,

We're using a BLE connection configured with a 15ms connection interval, and a radio event notification configured to fire 800us prior to a radio event. I'd like to synchronize a function with this event, so am testing the timing accuracy of this interrupt with poor signal strength.

To test, I am logging the difference in RTC ticks (with 16.4khz frequency; ie 15ms = 246 ticks) between the last two BLE radio events. Ideally, the logs should show a constant difference of 246 ticks. The following are some examples of deviations from that case:

[246, 249, 190, 305, 241, 250]

[245, 250, 190, 304, 241, 245]

Here, a tick arrives early and the following ticks return to the previous phase with 15ms period. Another deviation I've seen is:

[246, 246, 251, 158, 246, 246]

Here, a tick arrives early but the following ticks now reset phase to the early tick and maintain the 15ms period.

I'm not sure what could be causing an early radio event from the Softdevice. Any tips on how to interpret these events would be helpful. My current plan is to use a median filter to remove these outlier events.

Thank you!

Parents
  • Hello,

    The reason you are seeing these changes are because this is a wireless protocol, and in wireless transfers it is quite common with packet loss.

    When you see the 190 ticks, it means that the packet before that was lost, and it is a retransmission. Then you can see that this is sent successfully, and the next radio event is after a bit over 300 ticks.

    (190+305)/2 ≈ (246+246)/2

    Just to be clear, it means that the second packet is lost, the one saying 250, because this is shedulet at the normal time. The packet at 190 is the retransmission, and the 305 is another normal. But all in all, this is not really something you need to worry about. The softdevice handles it.

    Best regards,

    Edvin

  • Thanks for the explanation! Is this retransmission protocol documented anywhere? I wasn't able to find anything on it.

    Also for this case:

    [246, 246, 251, 158, 246, 246]

    Is this also an instance of retransmission? Here there is a reset in phase of the radio events which I don't understand.

  • aram said:
    Is this retransmission protocol documented anywhere? I wasn't able to find anything on it.

     It probably says somewhere in the specification, but I am not sure where.

    Perhaps you can tell me why you are looking at these numbers? Are you experiencing any issues?

     

    aram said:

    Also for this case:

    [246, 246, 251, 158, 246, 246]

    Is this also an instance of retransmission? Here there is a reset in phase of the radio events which I don't understand.

     If you are curious on what is happening on the air, I suggest you look into capturing a sniffer trace instead of just the timestamp of each packet. You can use the nRF Sniffer for BLE.

    The timestamps only doesn't really say much. 

Reply
  • aram said:
    Is this retransmission protocol documented anywhere? I wasn't able to find anything on it.

     It probably says somewhere in the specification, but I am not sure where.

    Perhaps you can tell me why you are looking at these numbers? Are you experiencing any issues?

     

    aram said:

    Also for this case:

    [246, 246, 251, 158, 246, 246]

    Is this also an instance of retransmission? Here there is a reset in phase of the radio events which I don't understand.

     If you are curious on what is happening on the air, I suggest you look into capturing a sniffer trace instead of just the timestamp of each packet. You can use the nRF Sniffer for BLE.

    The timestamps only doesn't really say much. 

Children
No Data
Related