CIG creation parameters

[GuyYaniv]

I'm trying to test minimum timing and performance using peripheral and central ISO under Zephyr.

I'm trying to play with the interval and latency values under the central sample app.

If I use anything under 5 msec (5U * USEC_PER_MSEC) for interval_us under central_iso I'm getting the following messages (I changed debug to warning messages so I can see the error):

[00:00:00.004,760] <wrn> bt_iso: id 0, latency C to P 5, latency P to C 5, interval C to P 255, interval P to C 255, sca 0, packing 0, framing 0, num_cis 1
[00:00:00.004,760] <wrn> bt_iso: [0]: id 0, c_phy 2, c_sdu 251, c_rtn 1, p_phy 2, p_sdu 0, p_rtn 0
[00:00:00.004,791] <wrn> bt_hci_core: buf 0x20009654 opcode 0x2062 len 27
[00:00:00.005,004] <wrn> bt_hci_core: opcode 0x2062 status 0x11
[00:00:00.005,035] <wrn> bt_iso: Unexpected response to hci_le_set_cig_params
Failed to create CIG (-5)

When I look at bt_iso_cig_create I see that it calls valid_cig_param which in turn checks minimum interval for 255 usec

HCI status 0x11 means Unsupported Feature or Parameter Value.

What are the correct boundaries and what reason is there for valid_cig_param to check values the controller doesn't accept?

Thanks,

Guy.

[Karl Ylvisaker]

Hello Guy,

Thank you for your patience with this.

If I use anything under 5 msec (5U * USEC_PER_MSEC) for interval_us

The lowest possible ISO interval is 5 ms, you can read more about this here.

Is your intention with this to use the ISO channels for data transport, or will the end product use LE Audio?

Best regards,
Karl

[GuyYaniv]

Eventually my goal would be to send low latency data from multiple streams (peripherals) which is not audio related.

At the moment I'm running experiments to understand whether the ISO solution would be adequate for our data rate requirements. 

Thanks,

Guy

[Karl Ylvisaker]

Hello Guy,

Thank you for the clarification - what requirements do you have to the latency of these data streams?
Will you be developing the devices on both sides of the link, or will you require interoperability (like with Bluetooth) with unknown devices made by other manufacturers? If not, there are some other options for the protocols you can choose from, if the 5 ms (iso) or 7.5 ms (regular BLE) minimum intervals are too long for your application.

Please do not hesitate to ask if you should have any questions while familiarizing with the possibilities and running the experiments, we're happy to help! :) 

Best regards,
Karl

[GuyYaniv]

I'm going to be using 2 nrf52833 for the purpose of close loop feedback for tracking a moving object.

I have a stationary central and potentially multiple moving peripherals.

The peripherals measure sensor data and should transmit it to the central.

In the past we've used LE ESB to communicate between 2 devices and it was sending about 8 bytes every 1 ms.

We understand that this is not achievable with BLE but ESB is not scalable or has the security characteristics BLE provides.

The solution we're trying to come up with is isochronous link between central and peripheral using BLE ISO and "package" multiple 8 byte chunks of data with timestamping so the central can extrapolate motion trajectory.

What I'm trying to do is use Zephyr's sample iso_connected_benchmark to experiment what kind of data rate and more importantly latency I can get with this setup.

The app provides 2 main adjustable timing pairs for each direction: interval and latency.

I've been scanning the SIG spec and also plugged in numbers to the sample app and I still don't understand what these represent and how do they impact performance.

I'm guessing the interval parameter corresponds to what the SIG spec calls ISO_Interval but how does it play with the other parameter?

Thanks,

Guy.

[Karl Ylvisaker]

Hello Guy,

Thank you for your extreme patience with this - I have been out of office for some days, but now I am back.

Thank you for elaborating on your use-case and providing the additional details, this is very helpful for me to know.

GuyYaniv said:

What I'm trying to do is use Zephyr's sample iso_connected_benchmark to experiment what kind of data rate and more importantly latency I can get with this setup.

The app provides 2 main adjustable timing pairs for each direction: interval and latency.

I've been scanning the SIG spec and also plugged in numbers to the sample app and I still don't understand what these represent and how do they impact performance.

I'm guessing the interval parameter corresponds to what the SIG spec calls ISO_Interval but how does it play with the other parameter?

Zephyr ISO benchmark example is a good way to go about testing this, since you only need the ISO channels and not the LE Audio interoperability in this case anyways.

Interval indeed refers to the ISO interval, but latency could here refer to multiple things.
In the LE Audio case the latency often refers to 'end to end' latency, but since we're not working with LE Audio in this case this is likely something else.
Could you clarify specifically what parameter and where in the BLE spec you are reading about the latency in question here?

Best regards,
Karl

[GuyYaniv]

I think I'm going to abandon the ISO method. 

My system has a central device that affects the peripheral. The peripheral's job is to send a sensor reading to the central so it can adjust parameter in a closed loop feedback fashion.

May main concern is to make sure that the central and peripheral time is synced so the central knows which sensor sample belongs to which parameters.

I've been reading about the 5.4 standard's periodic advertising with response and seems to be a good way to synchronize the 2 clocks and have correlation between the data.

Thanks,

Guy.

[Karl Ylvisaker]

Hello Guy,

Could you elaborate on why you no longer think the ISO channels are the right fit for your application?

Could you also clarify what kind of accuracy do you need for the synchronization here?
Since the ISO channels are made for stereo audio the synchronization between them is an inherent feature (using the reference / anchor point of each SDU), and so you could get this synchronization 'for free' by using the ISOs.
Using periodic advertising with response will give you a higher latency, so for this reason I would perhaps still recommend using ISO channels for this.

Best regards,
Karl

[GuyYaniv]

Hi Karl,

The loop we're talking about should have a few milliseconds of latency. We're still in development of the system so I don't have real numbers, but for real time tracking it's in the single digit range.

We're trying to come up with different algorithms that won't require the real time since it's not feasible with BLE and more than 1 connection. In past POCs we used ESB to get low latency but that is not scalable.

My goal is to reach some synchronization between the 2 boards: one will send the RTC and the other will update his RTC accordingly with as little drift as possible. Once the clocks are synchronized, I can time stamp the sensor samples so the master board knows which settings the sensor samples correspond to. Hope that makes sense.

Thanks,

Guy.

[Karl Ylvisaker]

Hello again, Guy

Thank you for your extreme patience with this.

GuyYaniv said:

The loop we're talking about should have a few milliseconds of latency. We're still in development of the system so I don't have real numbers, but for real time tracking it's in the single digit range.

We're trying to come up with different algorithms that won't require the real time since it's not feasible with BLE and more than 1 connection. In past POCs we used ESB to get low latency but that is not scalable.

Yes, if your latency requirement for the loop is lower than 5 ms I think you likely can not go with BLE.
However, in this case, will you control both ends of the link, or do you also require interoperability with devices from other vendors?
What particularly is the failing aspect of ESB that makes it infeasible for your product?

GuyYaniv said:

My goal is to reach some synchronization between the 2 boards: one will send the RTC and the other will update his RTC accordingly with as little drift as possible. Once the clocks are synchronized, I can time stamp the sensor samples so the master board knows which settings the sensor samples correspond to. Hope that makes sense.

I understand, thank you for elaborating.
The easiest way to achieve this with BLE would indeed be to borrow the synchronization mechanism from LE Audio, but if the end-to-end latency here makes BLE infeasible for you I think you must look to implementing this synchronization functionality yourself with whichever protocol you end up going with.

Best regards,
Karl

[GuyYaniv]

Hi Karl,

The parts of ESB that makes it not infeasible are its radio saturation for real time data sampling that won't leave   much space for advertisement/connection of other devices, There's no connection establishment protocol so it's most suitable for fixed connections (I still need to have ability to connect/disconnect as devices go in and out of range), and also the fixed channel property which would make it a problem for interoperability with environmental 2.4GHz noise.

And for our product we control both ends of a link. There's no 3rd party involved.

Thanks,

Guy.

[Karl Ylvisaker]

Hello again, Guy

Thank you for elaborating.
It seems to me that BLE would be out of the question in this case, but there are many good features from it that would fit your application (such as the spectrum hopping) that are available in Gazell.
Have you already considered using Gazell for this application?
The linked documentation here is for the nRF5 SDK, but the API and protocol is the same within the NCS context.

Best regards,
Karl