Fixed and repeatable latency in BLE

RE: Fixed and repeatable latency in BLE

Sigurd — Fri, 09 Oct 2020 13:46:34 GMT

[quote userid="90692" url="~/f/nordic-q-a/66680/fixed-and-repeatable-latency-in-ble/273689#273689"]Does BLE_EVT_TX_COMPLETE event mean that the user packet was transmitted successfully and was acknowledged in the link layer?[/quote]

Yes, that is correct.

[quote userid="90692" url="~/f/nordic-q-a/66680/fixed-and-repeatable-latency-in-ble/273689#273689"]

Is there a way to know whether retransmission has accrued per a specific user packet?

[/quote]

No. That information is not forwarded to the application layer.

[quote userid="90692" url="~/f/nordic-q-a/66680/fixed-and-repeatable-latency-in-ble/273689#273689"]Subsequently, can a specific packet be sent without the need for receiving link-layer acknowledge - so auto-retransmissions are avoided? [/quote]

No.

RE: Fixed and repeatable latency in BLE

ThePinkPanther — Thu, 08 Oct 2020 10:48:47 GMT

Does BLE_EVT_TX_COMPLETE event mean that the user packet was transmitted successfully and was acknowledged in the link layer?

Is there a way to know whether retransmission has accrued per a specific user packet?

Subsequently, can a specific packet be sent without the need for receiving link-layer acknowledge - so auto-retransmissions are avoided?

RE: Fixed and repeatable latency in BLE

Sigurd — Wed, 07 Oct 2020 15:51:13 GMT

[quote user="ThePinkPanther"]Does the receive path have a similar latency variance, from the moment the packet is received fully in the radio part, and till the SoC user application layer gets the data?[/quote]

No, it's much faster. The event, a BLE_GATTS_EVT_WRITE in this case, is forwarded to the application layer through a software interrupt. If the CPU is not busy with other interrupts(UART,SPI,etc), then it will be very fast. There are some numbers on how much time the SoftDevice uses to process the package here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fble_processor_avail_interrupt_latency%2Fble_central_connection_performance.html

RE: Fixed and repeatable latency in BLE

ThePinkPanther — Tue, 06 Oct 2020 20:51:20 GMT

This is very helpful - Thanks

Does the receive path have a similar latency variance, from the moment the packet is received fully in the radio part, and till the SoC user application layer gets the data? Or is it a deterministic and fixed latency?

RE: Fixed and repeatable latency in BLE

Sigurd — Tue, 06 Oct 2020 15:45:52 GMT

[quote user="ThePinkPanther"]If I understand correctly, configuring both minimum and maximum connection intervals to 7.5ms, for example, will result in latency between 0 to 7.5ms - right?[/quote]

Correct, assuming that the packet is send in the upcoming connection event(this is not guaranteed).

[quote user="ThePinkPanther"]Is there a way to measure the time a specific packet is queued by the SoftDevice, till it is actually sent?[/quote]

You can measure the time from you call sd_ble_gattc_write(), until you get the event BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE

RE: Fixed and repeatable latency in BLE

ThePinkPanther — Tue, 06 Oct 2020 07:40:46 GMT

Hi,

If I understand correctly, configuring both minimum and maximum connection intervals to 7.5ms, for example, will result in latency between 0 to 7.5ms - right?

Is there a way to measure the time a specific packet is queued by the SoftDevice, till it is actually sent?

RE: Fixed and repeatable latency in BLE

Sigurd — Mon, 05 Oct 2020 15:22:37 GMT

Hi,

When you send data from your application code, it will be queued by the SoftDevice, and then (usually) sent in the next connection event. A new connection event happens every connection interval. This means that the time from when you queue the packet on the central-side, until it will be received by the peer depends on the time the packet was queued in relation to when the next connection event starts.

Note that even if you are only sending a single command with 20 byte payload, it’s not 100% guaranteed to be received by the peer in the next connection event. Due to interference, packets can be lost, and would need to be resent in the next connection event.

Also note that if you are sending a lot of data, and depending on e.g. how the GAP event length is configured, what connection interval is used, etc, you might not be able to send all the data in the next connection event, and you might need several connection events to send all the data.