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

BLE Multi-link high throughput / lowest latency

Hi,

We are looking at the nRF52840 and would like to have 5 such devices in their own piconet, 1 Central device and 4 Peripherals, with a 2 Mbit PHY,

and want to achieve relatively high data throughput (roughly 1.2 Mbits / second total payload Peripherals->Central across the 4 connections) and lowest latency.

Is it possible to:

- have all the connections contain a connection interval = 7.5 msec, and a connection event length = 1.25 msec

- so that within a single 7.5 msec connection interval, the Central device has up to 6 discrete events possible  (or is the time not divvied up quite so neatly?)

- and within a single 7.5 msec connection interval, the Central device could (sequentially) request data from 1 Peripheral, then receive it, then request data from a different Peripheral,

then receive it, etc, in some kind of round-robin fashion, up to 6 events total, and even coming back around and requesting from 1 or more Peripherals a 2nd time

(still within the same connection interval)

Does this seem feasible?  Or is there a better scheme to absolutely minimize latency whilst maintaining a high throughput amongst multiple Peripherals.

As a side note, in this scenario, would the 4 connections all be time-sync'ed, ie, the 4 connections' 7.5 msec connection intervals all start and stop at the same moment in time,

and all 4 connections on the same channel within a connection interval?

Or not necessarily?

Thank You

Thomas

  • Hi

    It should be possible to have up to 6 connections running at a 7.5ms connection interval if you set the event length to 1.25ms, that is correct. 

    I am not sure if we have tested this, but I will check this with the developers and get back to you. 

    The way BLE works the central device will poll each peripheral on every connection event, and with a connection interval of 7.5ms the connection events will be spaced 7.5ms apart. 

    When the event length is set to 1.25ms the central device will schedule the different connections 1.25ms apart, so that it services one after the other. In other words the 4 connections won't start at the same time, they will all start 1.25ms 'out of phase'. 

    After a connection event ends it can't be started again until the next period starts, but it can be extended. This means that the last of the four connections could potentially send data for more than 1.25ms, since the central device should have some time left over when only running 4 links. 

    The four connections will change channels independently of each other, there is no link between them in this regard. 

    Best regards
    Torbjørn

  • Thanks a lot Torbjørn, for your reply.  If I read your answer correctly, then within a single 7.5 msec block of time, it is possible for up to 6 connections (with the parameters described above) to each get serviced for a portion of that 7.5 msec .

    I have a couple more questions please, if I may, related more to maximizing throughput:

    - At the beginning of a given connection event: if the peripheral is set up for notifications or write without response, is the central still required to 1st poll the peripheral, or can the peripheral just start sending data to the central?

    - And if the peripheral has more than 1 data packet to send within a connection event, does the central have to 1st poll the peripheral before every data packet that the peripheral wants to send?

    - In your Online Power Profiler, there is time allotted at the beginning of a connection interval for “Pre-Processing”, “Crystal Ramp-up”, and “Standby”, in some cases up to 1.5 msec combined total.  

    Do those kinds of factors delay data transmission at the start of a connection interval and thereby limit total throughput?  I understand the Inter-Frame Space between packet transmission but are there any additional built-in delays incurred at the start (or end) of a connection interval?

    Thanks

    Tommy

  • Hi

    Some bad news from the developers unfortunately: The minimum event time for one connection is 2.5ms, not 1.25ms. This means that with a connection interval of 7.5ms you only have room for 3 connections. 

    If you need 4 connections you need to increase the connection interval to 10ms. 

    Regarding sending without waiting for the poll, keep in mind that these radios are half duplex systems. They can't send and receive at the same time, so when the central is set up to poll the peripheral it can't receive anything from the peripheral. A BLE link follows a very strict scheme of the central polling the peripheral at exact intervals to ensure that the average current consumption is as small as possible. 

    TLDR: The peripheral will always have to wait for the poll from the central, and send any queued notifications or writes on the response to the poll. 

    In the case where the peripheral has more data to send the central will have to send a new packet for every packet from the peripheral. Neither the central nor the peripheral can send multiple packets in a row, they will always send one packet after the other. 

    Any delays caused by starting crystals and similar are planned ahead of time to make sure the radio is ready when the connection event occurs.The spec allows for a small amount of leeway in timing, to counter the fact that the clocks in the peripheral and central running the timing will never be 100% accurate, but the allowed leeway is in the microsecond range, not milliseconds. 

    Best regards
    Torbjørn

Related