Android central receive notifications from two nRF52832 peripherals at high frequency

[vvelinov]

Hello,

I have the following scenario: An Android Phone is playing the master role and two nRF52 custom boards are connected to the master as peripherals. Both peripherals are sending IMU data as notifications to the Android Master at 50 Hz. The same software is flashed on both peripheral boards (even the same BT Name). S132 and SDK15 is used. 

Everything works great, exept that the central device receives the notifications with different frequencies. Data from the second sensor is received slower than the first.

On the Android site I have two BluetoothGattCallbacks for each sensor and a separate onCharacteristicChanged method is called when a new notification is received from a sensor. The sensor data frame is written to a separate blocking Queue for each Sensor: Queue0 and Queue1. A separate Thread is reading both Queues sequentially and waits if a queue is empty until at least one sensor frame is written. Thus, we allign the data from both sensors, so that the frame IDs from both sensors match.

However, one of the Queues progressively accumulates more sensor frames, since the thread is blocking on the other queue and waiting for a sensor frame from the other sensor. This means that we receive the notifications with different frequencies. Below is a Plot of the sizes of both Queues over the time.

Is it the non deterministic nature of BLE that makes synchronous reception of notifications not possible ? Do we have to set different connection parameters for each sensor connection, so that no collisions occur ? Currently, we test with PHY 2 (Android 8.1 on Samsung) and Connection Interval from 15 ms. 

Any help is appreciated

Thanks

[Einar Thorsrud]

Hi,

Have you had any progress with this problem?

If not, I wander if it always is the same board that lags behind, or if it seems random? Do you have a sniffer trace showing the communication with the two boards? 

[vvelinov]

Hello, sory for the late reply but I was busy with experimenting. So I have changed a couple of things:

1. My previous results ware based on nrf_delay_ms() function which triggered the sending of notification each 20 ms (I know not the cleverest idea...). I have replaced it with a RTC Timer and put the CPU in sleep mode until the timer expires and the next notification is sent.

2. I used an external board for synchronization which sets a pin on both sensors and starts the timers synchronously.

3. On the Android device I have replaced the blocking queues with two counter variables which are incremented when a notification is received from sensor 1 and sensor 2 respectively. Another low priority Thread is calculating the difference of the two counters each second and writes the result in a file.

The results of the test which lasted for about 50 minutes looks like this:

After 30 minutes one of the sensors have sent  around 12 notifications more than the other. Then the other sensor starts sending faster. But the total difference of 10 - 12 notifications over a long term does not seem so bad. Since Android is not a real-time OS and the BLE is not time-deterministic protocol, I think we cannot achieve much better simultaneous reception of notifications. Any other opinion on the results would be appreciated.

[Einar Thorsrud]

Hi,

Thank you for letting us know about your progress. The difference is too big to be explained by typical 32.768 kHz clock drift. A possible explanation could be that you have more packet loss on line link than the other for some reason, leading to retransmissions. Then if you sample once per connection event, that would potentially cause a lag, at least if only one packet is exchanged per connection event. It should be possible to see this from a sniffer trace if that is the case.

[vvelinov]

Hi,

Thank you for the reply.

I also think that some re-transmittion of packets occurs. Do you have any Idea how I can sniff both sensor connections at the same time ? I have one PCA10040 Board which I use as a sniffer but I dont think Wireshark can sniff two connections at the same time ? I also have one nRF52840 PCA10059 board, but I think it cannot be used as a sniffer.

[Einar Thorsrud]

Hi,

You would need a proper professional sniffer in order to sniff multiple connections simultaneously (such as for instance a Ellisys Bluetooth Explorer). These are not cheep, though.

We cold just assume that this is the case for now and make a test that should mitigate the issue. If you use a connection interval that is larger then the sensor sampling interval, and/or allow multiple packets per connection event, then you should be able to retransmit quickly enough that you can continue transmitting sensor readings at the correct average speed, keeping them in sync, except for the clock drift.

[vvelinov]

thank you for the help and support.