Calling sd_ble_gatts_hvx in radio notification

RE: Calling sd_ble_gatts_hvx in radio notification

Hung Bui — Thu, 27 Aug 2015 09:16:47 GMT

Thanks for the figure, you are correct, if you switch the role, and use the master to send data the TX_COMPLETE will tell the number of packets actually acked on that same event.

I wasn't expect that you have control over both side. Your approach is correct.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Wed, 26 Aug 2015 09:11:42 GMT

Write command and notification are similar in the sense that they are unacknowledged at the GATT layer. What is being used depends on which device (link layer master or slave) is GATT client and GATT server. For this discussion lets consider both as goodies.

Now there are two cases of goodies being sent, whether its LL master sending them or the slave. In case the master is sending goodies to slave TX_COMPLETE is sent immediately after the event. In case the slave is sending goodies to master, the slave has to wait till after the next conn event to get the TX_COMPLETE.

In BLE it is always the master sending the first packet and slave responding in a connection event. With this we can see that for a slave to get a LL ack from the master with the Sequence Number, it has to wait one conn event. In case of master the slave has to respond back immediately, thus getting an ack and then giving TX_COMPLETE event to the application. I've made a small diagram to explain this and is added as an attachment to the question.

RE: Calling sd_ble_gatts_hvx in radio notification

Hung Bui — Wed, 26 Aug 2015 07:35:35 GMT

Your understanding of " The softdevice can only give the TX_COMPLETE event after the next conn event after sending the notification packet. This is because only after receiving the next packet from the master the slave can get an ACK through the sequence number." is correct.

What do you mean by "So, I'll test in a configuration where the master sends the data packets to the slave. In this case the ACK is immediate, thus being able to queue up only one packet. Edit Works with a master with GATT client sending write commands to a master with GATT server." ? Write command and notification are similar in the sense that it will be queued and the TX_COMPLETE only comes after 1 connection event.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Tue, 25 Aug 2015 08:44:14 GMT

I should have realized this way back. The softdevice can only give the TX_COMPLETE event after the next conn event after sending the notification packet. This is because only after receiving the next packet from the master the slave can get an ACK through the sequence number.

So, I'll test in a configuration where the master sends the data packets to the slave. In this case the ACK is immediate, thus being able to queue up only one packet. Edit Works with a master with GATT client sending write commands to a master with GATT server.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Mon, 24 Aug 2015 14:59:52 GMT

I've got it working to send at every conn event of 7.5 ms by queuing up to 2 packets. For now we'll settle for this. Thanks for all the help.

RE: Calling sd_ble_gatts_hvx in radio notification

Hung Bui — Mon, 24 Aug 2015 10:41:51 GMT

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.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Fri, 21 Aug 2015 13:56:33 GMT

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.

RE: Calling sd_ble_gatts_hvx in radio notification

Hung Bui — Fri, 21 Aug 2015 13:19:42 GMT

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.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Fri, 21 Aug 2015 10:58:42 GMT

Hi Hung,

There are few setups that I've tested:

S110 slave and S120 master on PCA10028 both with hardcoded max and min conn interval of 7.5 ms
S110 with 7.5 ms max and min conn interval and S120 with 7.5 ms min conn interval and 30 ms max conn interval. In this I call sd_ble_gap_conn_param_update(m_conn_handle,0); right after connection establishment. I wait for BLE_GAP_EVT_CONN_PARAM_UPDATE before sending notification packets as shown in the second comment to the original question.
Same as above with an Android phone as master instead of S120.

In all the cases the notification packets are received at an interval of 15 ms. Please note that I check that I wait for BLE_EVT_TX_COMPLETE event before calling sd_ble_gatts_hvx in the active signal radio notification handler.

This application cannot work if the notification are only sent at 15 ms interval. Could you please look into this.

RE: Calling sd_ble_gatts_hvx in radio notification

Hung Bui — Thu, 20 Aug 2015 09:35:15 GMT

@Narendra: The First connection parameter update happens after two seconds as defined by FIRST_CONN_PARAMS_UPDATE_DELAY here in the peripheral main.c:

#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(2000, APP_TIMER_PRESCALER)

I suspect that in your case the connection parameter didn't get updated correctly. You can check this out by capturing a sniffer trace. And see what happens over the air.

RE: Calling sd_ble_gatts_hvx in radio notification

Susheel Nuguru — Wed, 19 Aug 2015 16:56:13 GMT

I do not remember exactly when the notification frequency changed, I think it is after connection param update, which was after 2 secs. It seems to match the logic analyzer output. hope some one else could help you as i am on vacation for this week.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Wed, 19 Aug 2015 09:01:54 GMT

Bumping this up. Aryan, a bit of your time please.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Wed, 12 Aug 2015 14:46:51 GMT

Sorry to be bothering you again. I am still getting the notifications packets at the client at 15 ms. I'm using the examples that you've given.

Could you give this info: In the graph that you posted, when did the doubling of the freq of the HVX happen and become equal to that of irq handler?

Thanks!

RE: Calling sd_ble_gatts_hvx in radio notification

Susheel Nuguru — Wed, 12 Aug 2015 09:50:50 GMT

S110_LBS_client_server_central_peripheral-master.zip

S120_LBS_client_server_central_peripheral-master.zip

These are based on SDK8.1 from Github example. you will need to include this fix to compile them. copy them to SDK\examples\ble_peripheral folder. Good luck

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Wed, 12 Aug 2015 09:13:35 GMT

Thanks Aryan! Could you share (if fine with you) the main file for the central device and makefiles for the two devices. Today I'll dig in and see why its not working as it should for me.

RE: Calling sd_ble_gatts_hvx in radio notification

Susheel Nuguru — Wed, 12 Aug 2015 08:46:25 GMT

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.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Tue, 11 Aug 2015 23:03:15 GMT

I can't seem to recreate what was asked in the original question. I'll give it a try again in any case. Please let me know how often is the GATT notification packet received at the GATT client in your setup with the example that I posted?

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Tue, 11 Aug 2015 14:41:10 GMT

The radio active event is called every 7.5 ms. How often is the GATT notification packet received at the GATT client in your setup?

RE: Calling sd_ble_gatts_hvx in radio notification

Susheel Nuguru — Tue, 11 Aug 2015 13:49:11 GMT

Prithvi, I see a 7.5077ms interval with and without hvx. So it is as expected and nothing is wrong. Probably something else in your project effects this. Now I have tested with same setup like yours S120 Central and S110 peripheral, GCC but on windows. I do not think GCC will differ that much on linux.

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Tue, 11 Aug 2015 11:39:02 GMT

I've added a minimal example in the original question that does what I mentioned in my previous comment. It is based on nrf-ble-app-lbs SD 8.0 example. The pin toggling in the radio event happens every 7.5 ms, but the notification received in the master is at every 15 ms. Please see if you can figure out what is happening. Thanks!

RE: Calling sd_ble_gatts_hvx in radio notification

Susheel Nuguru — Tue, 11 Aug 2015 07:53:54 GMT

I cannot reproduce this PhrithviRaj, I tested this with latest SDK9.0 and the softdevice that comes with it on PCA100028. Now i wait for your example project.

RE: Calling sd_ble_gatts_hvx in radio notification

Susheel Nuguru — Tue, 11 Aug 2015 07:30:58 GMT

Hi PrithviRaj, If you can post a minimal example like you mentioned where I can reproduce this problem, it would save me a lot of time to set up the environment. Also I need to ask something you probably have checked before. You are checking the radio notification callback frequency and not the frequency with which HVX is done right?

RE: Calling sd_ble_gatts_hvx in radio notification

FormerMember — Mon, 10 Aug 2015 22:59:48 GMT

Thanks Aryan for verifying this. Updates from my side - When I changed from sending notification of payload of 1 octet to 16 octet, the radio notification handler gets called every 7.5 ms as it should. Strange. This was based on the ble-lbs example - github.com/.../SDKv8.0 I'll try to see if I can get a minimal example where I can recreate this behaviour and post it here for your reference.

I would appreciate your help with my current problem which is similar to what I posted but not exactly the same. I'm working on an application where the most recent sample needs to be sent as soon as possible. Here the reliability of BLE's link layer is a bane rather than a boon. This is why I cannot queue up packets in the application buffer, as this will affect the latency. So what I'm doing is:

bool tx_pending =  false;
void RADIO_NOTIFICATION_IRQHandler(void){
      if(false == tx_pending){
            //Send a packet as notification
      }
}

void on_ble_evt(void){
      switch(evt_id){
            case BLE_EVT_TX_COMPLETE:
                  tx_pending = true;
                  break;
      }
}

Even with different connection intervals and different radio notification distances the notifications are always received at an interval double of the connection interval. Could you please see why this is. As far as I read, queueing up in the radio notification event is early enough to be sent in that connection event. Thanks a lot!

RE: Calling sd_ble_gatts_hvx in radio notification

Susheel Nuguru — Mon, 10 Aug 2015 13:39:23 GMT

I did test it quickly with the setup I had S130 , Keil , Windows, but it was working normal. I will try your setup tomorrow with S120, Ubuntu, gcc and check the results.