Queued message count at start of Connection Interval

[avaldes]

If we want to make certain that a particular message goes first on a connection interval. Is there a way to check that there is none already internally queued?

Is this possible? Pseudo code below

app_ble_radio_notification_handler (active)

    if active

         if 0 == queued_tx_messages()

             queue_message(handle)

The reason I'm asking is because we can control the messages that we synchronously send to Central but messages that are generated by Central, example read request of a particular characteristic, will generate an internal response that will be transparent to peripheral.

[Vidar Berg]

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.

[avaldes]

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.

[Vidar Berg]

Hi,

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

avaldes said:

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)

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 ?

[avaldes]

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.

[Vidar Berg]

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. 

[avaldes]

Hi

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

[Vidar Berg]

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.