Queued message count at start of Connection Interval

RE: Queued message count at start of Connection Interval

Vidar Berg — Tue, 06 Apr 2021 09:17:49 GMT

Hi,

Yes, the peripheral will have to send a read response, but not neccessarly in the same connection event as the request. Below you can see a picture of a sniffer trace that shows the scenario where a GATT server receives a read request while having a notification packet in the queue.

RE: Queued message count at start of Connection Interval

avaldes — Wed, 31 Mar 2021 15:17:04 GMT

I agree with most of that. What about a read characteristic from Central, would not that generate a transmission in the Peripheral?

Assume that Application has queued a single notification, and Central happens to also want to read a particular READABLE characteristic from the Peripheral. On the next connection interval, wouldn't that generate possibly two transmissions?

#1 for the Notification we have queued

#2 to read the characteristic that Central was interested in reading

RE: Queued message count at start of Connection Interval

Vidar Berg — Wed, 31 Mar 2021 15:02:18 GMT

Hi,

Is the application expected to send multiple notifications from different handles around the same time as this particular packet? As you may know, the tx complete event is only raised after the Softdevice has successfully transmitted notification packet(s) that have been enqueued by the application through the sd_ble_gatts_hvx() call. There isn't anything else that will trigger this event.

RE: Queued message count at start of Connection Interval

avaldes — Wed, 31 Mar 2021 13:46:54 GMT

Hi Vidar

Yes we have looked into BLE_GATTS_EVT_HVN_TX_COMPLETE but it does not provide much of a context as the only context is "Number of notification transmissions completed" which is not much of a context for what we are looking for which was "what was the handle that was sent" if that was something that was available somehow maybe we can use it not for precise timing but to help have a context while we use the RADIO_STATE_STATE_TxDisable == NRF_RADIO->STATE as a timing method.

RE: Queued message count at start of Connection Interval

Vidar Berg — Wed, 31 Mar 2021 11:47:18 GMT

Hi,

It's only the application which fills the notification/write queue.

[quote user="avaldes"]All we do know is that a given messages has made it all the way out to the air, but we not have any context about which one is the one that made it out (which handle) ... so for us TWO possible solutions (perhaps you have more)[/quote]

Have you considered using the BLE_GATTS_EVT_HVN_TX_COMPLETE event to determine when a packet has been successfully sent, or wouldn't that be accurate enough? Also, have you seen this one:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/wireless-timer-synchronization-among-nrf5-devices ?

RE: Queued message count at start of Connection Interval

avaldes — Mon, 29 Mar 2021 18:42:02 GMT

Hi,

There is a message that on a particular connection intervals we need to be able to guarantee that it will go first, ahead of any other message ... is there any way to queue a message to the HEAD of the FIFO or only way to insert is to the TAIL?

We have used PPI to get access to the NRF_RADIO->EVENTS_END and once we get to the RADIO_STATE_STATE_TxDisable == NRF_RADIO->STATE

All we do know is that a given messages has made it all the way out to the air, but we not have any context about which one is the one that made it out (which handle) ... so for us TWO possible solutions (perhaps you have more)

#1 Get context as to what message did go out when we get the RADIO_STATE_STATE_TxDisable == NRF_RADIO->STATE state (timing is very very important)

#2 Be able to guarantee that a particular message gets in front of the transmit queue once the Connectoin interval is about to start.

RE: Queued message count at start of Connection Interval

Vidar Berg — Mon, 29 Mar 2021 18:22:58 GMT

Hello,

I'm afraid this is not something you can control as a Bluetooth connection events are being started by the GAP Central. The internal Softdevice protocol queue isn't exposed to the application either.

I may be able to provide some other suggestions, but I think would need to understand the background for this requirement first.