evenly space multiple notifications inside very same connection interval

[astella]

To the kind attention of Nordic support team,

I'd like to know what would be the best theoretically way, if possible, to control "when" multiple notifications are sent during the very same connection interval. Let's say I have to send multiple notification packets (that is about 200us each, using 1M PHY): #10 notifications. And available connection interval (also considering NRF_SDH_BLE_GAP_EVENT_LENGTH) is 100ms. Is it possible some sort of sync mechanism that allows to evenly space the 10 notifications 10ms apart so to have a steady stream of notification packets, arriving host side with some sort of fixed frequency (given all limitations related to the wireless channel)? The 10 notifications should be buffered before the connection interval beginning, so to be possible for the device to enable the "more data" flag and inform the master to not close the connection interval? In this case the notifications would be sent very quickly at the beginning of the connection interval, and not evenly spread in it. Is it possible to set a 100ms connection, sync very first sd_ble_gatts_hvx using radio notifications and then call sd_ble_gatts_hvx every 10ms without having buffered nothing? The master is going to close the connection interval?  

Best regards

[astella]

Hi Afroza, thank you. I'm experimenting using ble_app_att_mtu_throughput now. It appears to me, if I'm not wrong, that it is not possible to exactly place a packet in the connection interval. Like sending #10 packets spaced 10ms during the very same 100ms connection interval (just an example, for sake of clarity). At least, I'm never seeing such a thing when using the sniffer: whatever the timing I'm trying to force, softdevice is then carrying on its tasks async. I'm quite often seeing a bunch of packets that are accumulated at the beginning of the connection interval and spaced about 150us from each other. The best (in case a "constant" stream is desired) is when packets are sent until the end of the connection interval. Or, at least, that a constant number of packets is "always" sent per connection interval. Is there any theoretical guideline to get this?Anyway, ble_app_att_mtu_throughput and Nordic sniffer are a very good way to explore how packets are using connection intervals and what the best throughput to expect. 

Best regards  

[Emil Lenngren]

You should read the link layer chapter in the Bluetooth Core specification.

In a connection event, central and peripheral exchange packets. They alternate sending one packet, spaced 150 us apart (with a +-2 us tolerance), as long as at least one device sets the "more data" in the header. You cannot increase this spacing since that is not how the standard works.

If you need to send something every 10 ms, then just set the connection interval to 10 ms. If you don't always have something to send but want the central to always be ready, use the peripheral latency feature.