Multi-link for real-time apps - can it be done?

RE: Multi-link for real-time apps - can it be done?

neonotion — Fri, 29 Jun 2018 23:09:25 GMT

Yes that is right, already using it as the range was still pretty good for this app :-)

RE: Multi-link for real-time apps - can it be done?

FormerMember — Fri, 29 Jun 2018 13:33:21 GMT

I see that you already use 2 Mbps mode.

RE: Multi-link for real-time apps - can it be done?

FormerMember — Fri, 29 Jun 2018 13:30:07 GMT

If the peripherals support BLE 2Mbps mode, you can set up your device to run in that mode instead. That should double the throughput, I assume. To test it, you can use the throughput example in the SDK.

RE: Multi-link for real-time apps - can it be done?

neonotion — Thu, 28 Jun 2018 23:18:52 GMT

Thanks Kristin,

Yes indeed multiple Centrals would help, unfortunately the idea is that the Central is a USB dongle with a single nRF52840 module :-)

Cheers

Jeff

RE: Multi-link for real-time apps - can it be done?

neonotion — Thu, 28 Jun 2018 23:12:42 GMT

Hi kont40, yes buffering is already used. Because the transmitted samples get fused with real-time video frames at the receiver side the buffer cannot be too long (the frames can't wait too long for samples and must be fused ASAP), its the real time aspect of this project that means sample latency can only be tolerated up to a small number of sample intervals - 4 sample intervals as a guideline, so that is the maximum allowed buffer size. This is the reason for the dependency - its not the sample rate, its the latency issue.

cheers

Jeff

RE: Multi-link for real-time apps - can it be done?

kont40 — Thu, 28 Jun 2018 13:45:49 GMT

Hi @neonotion , Do you consider using buffering for the sensor data? This will simplify the data transmission a lot and decrease the requirements towards real-time transmission. Finally, the sensor sampling rate and the communication protocol timing should not directly depend on each other. The only question in this case is whether the final consumer of the data can tolerate some ms delay in receiving the data - but for a wireless application this is often the case. As I am solving a similar matter as yours, although with only two peripheral devices, you may want to check the topic on my current problem here https://devzone.nordicsemi.com/f/nordic-q-a/35689/multilink-central---data-always-received-from-the-last-device

Kind regards

RE: Multi-link for real-time apps - can it be done?

FormerMember — Thu, 28 Jun 2018 13:20:12 GMT

Hi Jeff,

Yes, your understanding is correct: to allow more devices connect to your central, you will either need to increase the latency or decrease the amount of data.

An option could be to use multiple centrals,multiple chips. Those centrals could then communicate with eachother using a serial interface.

-Kristin

RE: Multi-link for real-time apps - can it be done?

neonotion — Wed, 27 Jun 2018 13:00:57 GMT

Thanks Kristin,

I read that section and it clarifies a lot, yes the event length is the key concept. But I still think that based upon what I read that the maximum number of connected Peripherals is very small.

To take a simple example. Imagine that my streaming sample interval was 5ms and my maximum sample latency tolerance was 4 intervals (20ms), then considering the minimum event length of 2.5ms I can only fit 8 peripheral devices into my multilink scenario. #1 transmits a 4 sample packet at time 0, then #2 does at 2.5ms, then #3 at 5.0ms, then...#8 at 17.5ms, then at 20ms #1 send its next 4-sample packet - the average sample rate is still one per 5ms and the maximum sample latency is 20ms (4 sample intervals). So if I cannot tolerate more latency then I can't fit more than 8 devices into the system - certainly nowhere near the 20 devices limit of the SoftDevice S140. Have I missed something???

Cheers

Jeff.

RE: Multi-link for real-time apps - can it be done?

FormerMember — Fri, 15 Jun 2018 13:32:23 GMT

From my understanding, there are two consepts that needs to be distinguised: connection interval and "connection event length"

Connection interval: how often one device can transmit data

"Connection event length": the time it takes for each device to transmit data (I'm not sure if "connection event length" is the correct name)

Depending on the connection interval used, there can be multiple "connection events" (for different device) within on connection interval.

To get a better understanding, I would recommend you to read the Scheduling chapter in the softdevice specification.