Calling sd_ble_gatts_hvx in radio notification

[FormerMember]

Hey everyone, I'm trying to send a value as a notification packet from GATT Server (slave) to GATT client (master) at 7.5 ms connection interval. I have set up the radio notification IRQ (SW IRQ) to fire before the radio becomes active at low IRQ priority. In this routine I call the sd_ble_gatts_hvx() routine. Without the sd_ble_gatts_hvx call, I get 7.5 ms interval. But with the call I get 15 ms routine.

void RADIO_NOTIFICATION_IRQHandler(void){
      //sd_ble_gatts_hvx call to send a notification
}

Is there a way send a GATT notification packet from the RADIO_NOTIFICATION_IRQHandler while still having 7.5 ms connection interval with S110 SD?

Edit: Adding that I have checked with different 'radio notification distances', from 800 us to 3260 us.

Edit 2: This behaviour is consistent even with 10 ms, 15 ms or 250 ms connection interval. I.e. the interval at which the radio notification event happens doubles when sd_ble_gatts_hvx is called in the radio notification IRQ handler.

Edit 3: Added a minimal example that has the problem mentioned in the comments.main_notify_radio_evt.c

Edit 4: Added a sniffer trace of how the notifications are sent.Sniffer_Trace.png

Edit 5: Added a small flow diagram to explain a comment. (It'll be nice to add pics to comments) Setup: nrf51 DK with S110 v8.0.0 in connection with nrf51 DK S120 v2.1.0. Compiled with GCC in Linux. Thanks!

[Susheel Nuguru]

Hi Prithvi, I have just used your radio init and radio irq handler (exactly as it is) I confirm that after connection param update is done, the connection interval is 7.5ms and after the connection param update, I have checked that notification is sent at the same interval and received on peer at the same interval

I believe that the image you see is self explanatory.

[Hung Bui]

As you already mentioned, the nature of BLE doesn't support realtime requirement. All packet will be transmitted I assume that you want to only update the latest sample on each connection interval, my suggestion for you is to try to keep track of the number of packet in the buffer by using the number of packet you queue, minus the number of packet sent reported in BLE_EVT_TX_COMPLETE. If in one BLE_EVT_TX_COMPLETE you have the number of packet in the buffer is full, you would need to queue at least 7 packets (if the max number of packet per connection interval is 6). This is to make sure you will have at least 1 packet to be sent in the connection after the next one. So that we will not get into the situation with one connection event with packet sent and one without.

But anyway, it will have a 7.5ms latency because you can't have a packet sent immediately but will have to wait for the next connection interval.