• State Verified Answer
  • Replies 24 replies
  • Subscribers 68 subscribers
  • Views 731 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 331167
Options

Packet loss during ISO transmission when advertising

thomas_hexploy

Hi,

Bug:

With a connected ISO connection between two devices X and Y:

  • X acts as a peripheral. It's the ISO server and it is transmiting iso data to Y.
  • Y is multirole. It connects to X and establish an ISO connection to receive ISO data.

As long as Y only receives data, the communication is stable (no packet loss). As soon as Y advertises (bt_le_adv_start), Y does not receive all packets.

  • Increasing advertising interval, decrease packet loss.
  • Decreasing advertising interval, increase packet loss.

Environment:

  • OS: Linux
  • Toolchain zephyr-sdk-0.16.8
  • NRF5340DK
  • NCS 2.7 (sdk-nrf v2.7.0 and zephyr v3.6.99-ncs2)

How can solve this issue, which causes too many packet loss ?

Thank you

  • 0 in reply to yuxuan.cai

    Hi,

    You can find enclosed a patch to apply on Zephyr (v3.6.99-ncs2) used by NCS 2.7. It's only a rework of peripheral_iso and central_iso samples (central becomes RX and peripheral becomes TX).

    Once the patch is applied, you just have to build and flash these 2 samples on 2 different targets (Once flashed, the targets must be close to connect to each other since connection is based on RSSI).

    0001-Peripheral-TX-ISO-Central-RX-ISO.patch

    There is multiple defines at the beginning of the different main.c to customize the parameters we talked about.

    Let me know if you have any issue with this.

  • +1 in reply to thomas_hexploy

    Hi,

    Sorry that it took some time.

    I've managed to reproduce the packet loss you mentioned, and after discussions with the team, I believe it has to do with how the data are provided.

    In your application, the SDUs are provided to the controller with sequence numbers. When an SDU is provided too late, the controller will either drop the data or send it in the next event. An SDU can be provided too late due to the asynchronous nature of the HCI interface, or in your case, the interference from an ongoing advertiser.

    To address this, you could use the "Time of Arrival" mode mentioned here by setting the sequence number to 0 when calling bt_iso_chan_send(). With this I observed no missing packets locally.

    If you'd like to learn about the "Timestamp" mode, please check out the iso time sync sample.

    Cheers,

    Yuxuan

  • 0 in reply to yuxuan.cai

    Hi,

    We did some test with

    ret = bt_iso_chan_send(&iso_cis_chan, buf, 0);

    and this is much better. We don't see any packet loss for the moment (we will continue our tests in the following days).

    Could you tell me if the issue you mention with the SDU will be fixed in later version or is it normal ?

    Thank you for your support.

  • 0 in reply to thomas_hexploy

    Hi,

    Glad to know it helps!

    The fact that the controller drops outdated SDU is a design decision and thus it will most likely not be fixed.

    Cheers,

    Yuxuan

Related