Closed whati001 closed 1 year ago
cvinayak
commented
1 year ago Please check if the sample is able to transmit ISO data on making the below if clause false: https://github.com/zephyrproject-rtos/zephyr/blob/d9637673694419abcbbb04d8a012da9a8380866d/subsys/bluetooth/controller/ll_sw/isoal.c#L1584-L1586
i.e. have it as:
/* Adjust payload number */
if (session->sn && 0) {
/* Not the first SDU in this session, so reference
whati001
commented
1 year ago After adjusting the if clause and reflashing both boards (receive + broadcast), we sometimes receive the counter data. But it is really only sometimes, not always and reliably. Here are the logs from the iso_receive sample:
Incoming data channel 0x20000134 flags 0x9 seq_num 648 ts 8214653 len 4: 42040000 (counter value 1090)
--- 1 messages dropped ---
Incoming data channel 0x20000134 flags 0x9 seq_num 650 ts 8234654 len 4: 44040000 (counter value 1092)
--- 4 messages dropped ---
Incoming data channel 0x20000148 flags 0xa seq_num 651 ts 8244654 len 0: (counter value 0)
--- 1 messages dropped ---
Incoming data channel 0x20000148 flags 0xa seq_num 652 ts 8254653 len 0: (counter value 0)
--- 1 messages dropped ---
Incoming data channel 0x20000148 flags 0xa seq_num 653 ts 8264653 len 0: (counter value 0)
--- 1 messages dropped ---
Incoming data channel 0x20000148 flags 0xa seq_num 655 ts 8284653 len 0: (counter value 0)
--- 3 messages dropped ---
Incoming data channel 0x20000148 flags 0xa seq_num 656 ts 8294651 len 0: (counter value 0)
Incoming data channel 0x20000134 flags 0x9 seq_num 657 ts 8304652 len 4: 4b040000 (counter value 1099)
--- 1 messages dropped ---
Incoming data channel 0x20000134 flags 0x9 seq_num 658 ts 8314652 len 4: 4c040000 (counter value 1100)I am suspecting that the logging over UART can throttle the reception, starving available free buffers in the Controller due to slow processing in the application.
if clause hack in the iso_broadcastCONFIG_LOG_BUFFER_SIZE=4096 in the iso_receive. Or make the logged message shorter so that UART transmission is short enough to process to received ISO data quick enough.cvinayak
commented
1 year ago This is how I get, eventually logging starts dropping messages as it is not able to catch up:
whati001
commented
1 year ago Thank you very much for the hint. I will try to adjust the logging system.
But would not it be possible to simply send less data? Especially to cover my use case, a single channel send one message every 100ms would be sufficient. I am really not an ISO expert so please apologize this stupid question.
whati001
commented
1 year ago Hi, unfortunately, I have to finish my master thesis quickly, therefore, I have to postpone this project for some time. Thank you very much for your help and.
cvinayak
commented
1 year ago This may be fix by use of CONFIG_BT_CTLR_ISOAL_SN_STRICT=n in the iso_broadcast sample introduced in https://github.com/zephyrproject-rtos/zephyr/pull/58717. Closing issue, reporter can re-open if issue persists.
Hi,
as mentioned in the discord thread, it seems like that the current samples of the iso_broadcast and iso_receive do not work for the nrf52840dk board. The boards are able to exchange the BIG information and the broadcast sample seems to announce the counter value. However, the receive sample never receives the actual value and always prints the value 0. We would expect to see the counter values, send by the broadcaster sample instead of 0.
The problem can be reproduced by placing two nrf52840dk boards next to each other and flash the unchanged samples from the current upstream (git commit: d9637673694419abcbbb04d8a012da9a8380866d) as following:
Here are the logs of the two samples after the boot: broadcaster
receiver
Compiled:
Possible issue: As @cvinayak mentioned in the discord message, the receive may drop the message data because it receives it out-of-sync.