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,

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