This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

I need to understand how a multi-link configuration can achieve real-time transmission - its all about latency. 

The Application

In my nRF52840 application I have several body-worn Inertial Measurement Units (IMU's)  - the Peripherals, each taking turn in a "Round Robin" manner to send a data sample in real-time to a PC Dongle - the Central.  For this app the sample rate is 180sps so the sample period is therefore 5.56ms and all IMU's ideally transmit one 26 byte sample to the Dongle within this period - so Data Length Extension has been enabled to ensure that all 26 bytes fit into the ATT Payload of one frame.  To ensure this 180sps sample rate and allow the full capacity of up to 20 IMU's (peripherals) I am using the 2Mbps PHY.

Because the minimum Connection Interval is 7.5ms the 5.56ms sample rate cannot consistently be met in real-time, however, the application can tolerate a few sample periods of latency - say 27.5ms (22 units of 1.25ms) and so I am setting the Connection Interval to 27.5ms and packing five 26 byte samples into each transmission - this results in an average sample period of 5.5ms but introduces latency - the most recently collected sample is sent by the IMU "on time", the one collected before this has a 5.5ms delay, ... and the 5th sample in the frame arrives at the Central 27.5ms "late" but that is ok for this app, but no more latency than that please!.  Of course my MTU is set to allow one frame to accommodate all 5 samples in one single transmission.

The multi-link Application Question

If I have say 20 IMU's (Peripherals) transmitting one-by-one (#1 sends its frame, then #2, then #3..., then #20, repeat - #1, then #2, then #3, .... and so on) to the Dongle (Central), 

  1. does each Peripheral have to use a separate sequential 27.5ms Connection Interval? - so it cannot transmit it's next frame for 20 x 27.5ms (550ms!!!) when its turn comes back around and thus is not real-time anymore because of the 550ms gaps being forced between its successive sample groups?,
  2. OR, can each of the 20 Peripherals transmit in turn WITHIN A SINGLE CONNECTION INTERVAL and thus all 20 have transmitted their frame within the same 27.5ms time period before the next Connection Interval begins on a new hop channel - thus preserving the maximum 27.5ms sample latency.  I checked the transmit time and with a payload of 5 x 26bytes all 20 frames can fit in this time period even with Inter Frame Space and some retries considered so the interval is theoretically long enough to fit all 20 frames.  

From my understanding, this consideration of how multi-link works with Connection Intervals determines if real-time data transmission is feasible.  If (1) applies then it is not, if (2) applies then it generally is.  Can somebody please shed light on this question.  Does Nordic Semi have any written documentation that can answer the question?  Does the SDK support the use of multiple Peripherals transmitting within each Connection Interval?

Many thanks in advance !!!

Parents Reply Children
  • 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

Related