This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Calling sd_ble_gatts_hvx in radio notification

FormerMember
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. SendingGoodies.jpg (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!

Parents
  • 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. image description

  • FormerMember
    0 FormerMember in reply to Susheel Nuguru

    Your theory seems correct. We also thought so. It is confirmed by the sniffer screenshot I attached in the original question. Aryan seems to have got this working in his setup, even with checking if BLE_EVT_TX_COMPLETE event is called. Any theory on how to get that working? We're working on an application where the most recent sample needs to be sent. The reason why we can't queue up in the TX buffer is that we cannot remove from the buffer once a packet is added. So if I queue up because of the reliable nature of BLE, the buffer can only be updated once all the packets are sent. This can become a problem where there is wireless interference causing old samples being tried to be sent over and over.

Reply
  • FormerMember
    0 FormerMember in reply to Susheel Nuguru

    Your theory seems correct. We also thought so. It is confirmed by the sniffer screenshot I attached in the original question. Aryan seems to have got this working in his setup, even with checking if BLE_EVT_TX_COMPLETE event is called. Any theory on how to get that working? We're working on an application where the most recent sample needs to be sent. The reason why we can't queue up in the TX buffer is that we cannot remove from the buffer once a packet is added. So if I queue up because of the reliable nature of BLE, the buffer can only be updated once all the packets are sent. This can become a problem where there is wireless interference causing old samples being tried to be sent over and over.

Children
No Data
Related