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]

I think the issue was with how you call sd_ble_gatts_hvx. BLE_EVT_TX_COMPLETE is triggered at the end of an event if in that event, the TX packet (notification/write command) sents in the last event was acked.

This means if you queue only one packet when BLE_EVT_TX_COMPLETE happens, you will have one connection event with one notification next connection event will be no notification (it's the conn event when you have the BLE_EVT_TX_COMPLETE event) and next with connection event with one notification (BLE_EVT_TX_COMPLETE will not come for this event, because there was no notification sent last event, BLE_EVT_TX_COMPLETE will come at the next event).

I would suggest you to try testing by queue as much as possible data when you receive BLE_EVT_TX_COMPLETE, until the buffer is full. This way, you will make sure at any connection event, there will be something sent.

A sniffer trace will really clarify what happens in the air (connection interval, notification latency) and explains everything.