Problem receiving many data from two different characteristics

[jpo38]

We have a home made BLE device based on nrfR1822. This one has two embedded sensors sampling data at a frequency of 25Hz.

In regular mode, the device sends every second or so some markers extracted from 25Hz raw data (local embedded data processing) through 2 characteristic notifications.

In debug mode, the device sends the whole signals (at 25Hz, so one frame per 40ms) through 2 different characteristic notifications.

When I connect the device from and Android phone, I can receive the 25Hz signals in parallel (and even more).

When I connect the device from PC using a s130 dongle, only one characteristic data can be received:

• If I toggle CCCD On for characteristic #1, I receive data for #1 at a 25Hz frequency
• If I toggle CCCD On for characteristic #2, I don't receive any data for #2 (still receiving data for #1)
• If I toggle CCCD Off for characteristic #1, I then receive data at a 25Hz frequency for #2
• If I toggle CCCD On for characteristic #1, I don't receive any data for #1 (still receiving data for #2)

Looks like s130 dongle is unable to receive a huge amount from two different characteristics.

Note that, in the mean time, CCCD is On for battery level characteristic and I receive this one correctly in any configuration (a battery level is sent every few seconds, so frequency is very low).

Is this a bug? A known issue? A bad configuration I'm using (as it works on Android, I know the problem does not come from my BLE device)...

[Petter Myhre]

The S130 as a central can only receive one notification in each connection interval, while Android phones usually can receive more. How are you calling sd_ble_gatts_hvx()? Are you handling the returned error codes?

[jpo38]

I'll have to ask the team who designed the firmware to be able to answer your question. Anyway, even if we handle error codes here, it won't fix the s130 limitation.... By the way, my connection interval is 6ms and I'm receiving values from each caharacteristic at 250Hz (so every 40ms). So it should work better (having 6 connection interval between two samples), shouldn't it? But the two values are notified synchonously (sent at the same time every 40ms, this may be the problem). Is there any chance to have s130 be able to work as Android phone works in the near future?

[Petter Myhre]

The minimum connection interval is 7.5 ms, so 6 ms is not possible. 250 Hz gives a period of 1/250 = 0.004 s = 4 ms.

[jpo38]

You are right, my connection interval is 6 unit, meaning 7.5ms (a unit being 1.25ms). But I was wrong I'm at 25Hz (one data every 40ms). So two characteristics should work well, shouldn't it? Two values are sent every 40ms, should we offset one to have have them not be notified at the exact same time? Is there any chance to have s130 be able to work as Android phone works in the near future?

[Petter Myhre]

I'm guessing that one of your sd_ble_gatts_hvx() calls returns BLE_ERROR_NO_TX_PACKETS. To solve this you can either call sd_ble_gatts_hvx() in a loop until you get NRF_SUCCESS, or the better way, you can wait for the BLE_EVT_TX_COMPLETE event and then call sd_ble_gatts_hvx().

Not calling sd_ble_gatts_hvx() for both characteristics in the same connection interval should also work, but I would still recommend handling returned errors.

The latest release of the S130 SoftDevice, 2.0.0-7.alpha can receive 3 packets per connection interval as a central. It will be 6 packets in the S130 v2 production release. SoftDevice S130 2.0.0-7.alpha is supported in SDK 11.0.0-2.alpha.