NUS Event Handling and Latency Measurements, (Single Packet Per Connection Interval)

[donbosley]

SDK 14.2 / SD132 5.0 / NRF52832 --> NRF52832

There is a thread here which discusses "when NUS is ready" : https://devzone.nordicsemi.com/f/nordic-q-a/28208/when-is-nus-ready


While BLE_NUS_EVT_RX_DATA is reliable in indicating the system is ready to send another payload etc..., if you look at the actual timing it's dictated by the connection interval. I have a set of test cases built off of the NUS and NUS central example where an external device trips gpiote to start a series of transmissions. A gpio on Peripheral / Server tells the external device, "I've started."

In theory when the transmission is over, I should be able to use the Central/Client to trip another GPIO on the external device and have it measure the latency - at least in a way rough enough to characterize it.
Right now this works, but regardless of what flags/events I use to trigger the external time stamps, they're directly related to connection interval.
I have also tried other events on the Peripheral side and get similar or 2x connection interval length results.

While the concept

works reliably and I can measure the latency of a large number of packets and log them through terminal with very little impact on the NRF52's, the latency is not really the packet latency, it's the time between the start of transmission and end of the connection interval. If I have the external device force a time delay between sending data from server to client, for instance put a delay of 4mS between "send" trips, the measured time shrinks, but the running time between events remains coupled to the connection interval. 

The major issue : I'm only getting one packet per connection interval and throughput is terribly low (2M phy is set, att_mtu is set to max, and data length is verified) - capping around 240 kBit/second.

Is there a way within NUS to reliably signal that an individual transmission has completed, and start an additional send within a connection interval? Or does a call to SD_BLE_GATTS_HVX by its nature require a new connection interval? I have notifications enabled also, and have verified they are enabled by printing the status code to terminal.

*I may try to incorporate code more similar to ATT_MTU throughput where starting a transmission event goes into a while loop of sending until !NRF_SUCCESS, and then waits for the EVT HVC to retry, but it would be nice to just have it work with the projects I have working by adding handling for an event that exists, but that I'm somehow missing.

[Vidar Berg]

Hi, 

Notification packets passed to SD_BLE_GATTS_HVX are queued internally in the softdevice scheduler, which handles the packet transmission and ensure that max. number of packets are sent per connection interval. In other words, you should get max. throughput as long as the application keeps the output buffer full. 

Transmission complete is signaled to the application through the BLE_GATTS_EVT_HVN_TX_COMPLETE event. This event can be combined with a ring buffer, etc if you want to avoid the while loop.

Also, the number of packets per connection interval depends on the time set aside for each connection, see sdk_config.h::NRF_SDH_BLE_GAP_EVENT_LENGTH. It's set to 320*1.25 ms in the throughput example.