Notification handling in pc-ble-driver vs on-chip handling

RE: Notification handling in pc-ble-driver vs on-chip handling

brianreinhold — Thu, 04 Feb 2021 09:23:25 GMT

Not that critical - its good for design development and testing new protocols for health devices (which I am doing). But pay dirt is on a real chip. There the notifications are significantly faster.

RE: Notification handling in pc-ble-driver vs on-chip handling

run_ar — Thu, 04 Feb 2021 08:40:13 GMT

[quote user="brianreinhold"] I suppose the slowness is due to the overhead of going through the serial port meaning I never run out of buffers (never get the out of resources error); by the time I send the next buffer (even in a tight loop) the previous one has gone out the door[/quote]

Exactly. Not sure what throughput you are getting. But the serial interface will be the limiting factor eventually. I guess you could check your connection interval and how many packets you are able to send in each connection event using a sniffer if you want to try to maximize throughput as much as possible.

RE: Notification handling in pc-ble-driver vs on-chip handling

brianreinhold — Tue, 02 Feb 2021 12:43:22 GMT

On chip I simply notify in a loop as long as I get success. I only wait on the event if I get the error message that I am out of TX buffers. This greatly speeds up transfers compared to indications where I need to wait for the peer confirmation event before sending the next one. Since the peer does not confirm notifications, the speedup is no surprise.

I tried the same thing using the pc-ble-driver. Of course there are some differences. For one thing I use semaphores since there is no sd_app_evt_wait() support. Then with indications I simply do indications in a loop and repeat if I get an NRF_ERROR_BUSY.

For notifications, I also repeat the loop and wait for a semaphore event only when I get the out of resources error. However, I did NOT get the big improvement over using indications instead as I did on chip. I noticed that the BLE_GATTS_EVT_HVN_TX_COMPLETE event was almost in step with the notification. I suppose the slowness is due to the overhead of going through the serial port meaning I never run out of buffers (never get the out of resources error); by the time I send the next buffer (even in a tight loop) the previous one has gone out the door.

RE: Notification handling in pc-ble-driver vs on-chip handling

run_ar — Tue, 02 Feb 2021 12:15:55 GMT

Hi,

If you want to transfer data using notification you should place new data in the tx buffer as soon as you receive the TX_complete event for as long as you have data to transfer. This should be done regardless of whether this is on chip or using the pc_ble driver. If you wait for the last buffer to be freed you will slow down transfer quite significantly as BLE uses lacy acknowledgement. This means the last packet sent by the peripheral in a connection event will not be acked in the same connection event. Instead it will only be acked (and the buffer freed) when the peripheral receives the first packet from the central in the sub subsequent connection event.