Hello all, my question is related to notifications and to maximize data bandwidth using them; First af all i have already read this: devzone.nordicsemi.com/.../ but it is not enough for my situation;
In my scenario, i have a nRF51822 device which needs to update some characteristics at high frequencies (up to 100Hz) by using notifications; each characteristic is optimized to be 20 bytes long in order to take advantage of all the data payload available for each notification;
In one of my use-case i need to update togheter 4 characteristics at 100Hz frequency, so on the nRF51822 side the firmware updates at the same time (with 4 consecutive calls to sd_ble_gatts_hvx specifically timed at 100Hz) the 4 characteristics to be notified with a connection interval previously set to 10ms; My problem is that it seems (by executing some debug and checking the TX_COMPLETE event, reading the number of packets transmitted each time) that on each connection event the number of packets transmitted is not always 4 as i was expecting (1 packet for each notification requested), and i see a similar problem also when transmitting 3 characteristics instead of 4; So, considering the fact that the nRF51822 can send up to 6 packets per connection event, this behaviour seems strange to me; this can be a normal behaviour of the S110 stack or there can be a problem? Is there a way (standard coding or some sort of "hack") to force the nRF51822 to send a X number of notifications (so packets) on each connection event?
The peer device used for these tests is an android smartphone at a very short distance to avoid re-transmission problems (one time a Motorola MotoG 2gen 4.4.4 and another time a Nexus5 5.0 with similar results - the Nexus5 seems to allow a slightly greater number of packets transmitted than the MotoG)
Thanks to all in advance
UPDATE 1: I have executed other tests with a slightly different configuration in order to know more of this problem: connection interval: 7.5ms; slave interval: 500ms; With a timer each 400ms are updated 5 different characteristics togheter (with 5 consecutive calls to sd_ble_gatts_hvx);
Then, by checking the TX_COMPLETE event continuously (reading the number of packets transmitted and timings between them) i can see these results:
- with MotoG 4.4.4, most of the time are needed 3 consecutive connection events to transmit the 5 notification packets with the scheme 2-2-1 (packets each connection event), while sometimes are enough 2 connection events with the scheme 3-2 (packets each connection event);
- with Nexus5 5.0, most of the time are needed 3 consecutive connection events to transmit the 5 notification packets with the scheme 3-1-1 and sometimes 2 connection events; sporadically i have seen also 4 packets in one single connection event;
Do you think is a Central problem that can't accept more packets in each connection event? Or could be the S110 stack which doesn't try to send all the queued notifications (up to 6 for 6 packets) togheter within the first available connection event?
