connectless CTE TX/RX problem

RE: connectless CTE TX/RX problem

loquat — Sun, 29 Oct 2023 23:19:46 GMT

The problem seems to be with PeriodicAdvertising rather than DirectionFinding.
This ticket will be finished and a new ticket will be created.

Thank you.

RE: connectless CTE TX/RX problem

Simonr — Tue, 24 Oct 2023 11:33:05 GMT

Our developer suggested to set CONFIG_BT_CTLR_SYNC_PERIODIC_SKIP_ON_SCAN_AUX=y (sorry if that wasn't clear) to allow the device to skip periodic sync events that overlap with extended scan event.

This means that when AUX_ADV_IND or AUX_CHAIN_IND auxiliary channel PDU scan radio event overlaps Periodic Sync radio event in unreserved time space, let the Periodic Sync radio event be aborted so that the auxiliary channel PDU can be received to generate Extended Advertising Reports. By default we want Periodic Advertising Sync Events to take priority over any overlapping Extended Advertising Primary and Auxiliary channel PDU reception in order to not skip Periodic Advertising Report generation.

Under simultaneous multiple Periodic Advertising Sync support with small Periodic Advertising Intervals where there will be a lot of overlapping Periodic Advertising Sync events, it is desirable to permit Extended Advertising auxiliary PDU reception be allowed in a round robin scheduling to skip the overlapping Periodic Advertising Sync event.

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Mon, 23 Oct 2023 09:03:30 GMT

sorry. Information was lacking.

When set "CONFIG_BT_CTLR_SYNC_PERIODIC_SKIP_ON_SCAN_AUX=n"

After EXT_ADV reception stopped, EXT_ADV reception did not recover even if all Periodic transmitters were stopped.

Is this correct behavior?

RE: connectless CTE TX/RX problem

Simonr — Mon, 23 Oct 2023 07:57:22 GMT

Can you explain what you mean about "EXT_ADV reception was not restored" here? Do you also stop and restart the device that is receiving data and are still not able to see the EXT_ADV working as expected?

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Sat, 21 Oct 2023 15:17:58 GMT

"CONFIG_BT_CTLR_SYNC_PERIODIC_SKIP_ON_SCAN_AUX"
I tested it.
Indeed, it seems that EXT_ADV reception never stops.
However, even if all CTE transmitters were stopped, EXT_ADV reception was not restored.
Is this normal operation?

RE: connectless CTE TX/RX problem

Simonr — Wed, 18 Oct 2023 08:31:18 GMT

One of our devs looked at this, and suggested trying the CONFIG_BT_CTLR_SYNC_PERIODIC_SKIP_ON_SCAN_AUX to skip periodic sync events on overlaps with extended scan events.

Best regards,

Simon

RE: connectless CTE TX/RX problem

Simonr — Fri, 13 Oct 2023 11:49:06 GMT

So you're trying to receive CTE data from 5 TX devices at the same time? If so, that makes sense, as CTE means Constant tone extension, so it will only be able to receive from one device at a time by default, and you'll need to give each of them separate timeslots using I.E. the MPSL I believe. Are you able to receive the EXT_ADV at all? What exactly is "long time" in this test case?

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Wed, 11 Oct 2023 14:19:10 GMT

An interesting phenomenon has occurred.
The phenomenon occurred in an environment I built into my product.
Similar to the test, you will receive a CTE.
nRF5340
Set CONFIG_BT_PER_ADV_SYNC_MAX=8
5 TX boards(with CTE)
If you are receiving for a long time, only EXT_ADV will not be received. (ADV_NON_CONN and ADV_CONN are received.)

Do you have any advice?

RE: connectless CTE TX/RX problem

loquat — Wed, 11 Oct 2023 02:05:54 GMT

OK.Thanks.

I'm also testing the modified version.
No issues have occurred at this time.

RE: connectless CTE TX/RX problem

Simonr — Tue, 10 Oct 2023 10:37:45 GMT

I just wanted to let you know that I'm back, and I checked up on Hieu's test setup which has been running over the weekend and can confirm it is still running. So it seems like the fix is a success as far as we can tell. I'll let you know if anything changes.

Best regards,

Simon

RE: connectless CTE TX/RX problem

Hieu — Fri, 06 Oct 2023 15:43:17 GMT

Hi loquat,

My apology for the long silence. I would like to confirm a fix before updating you.

Currently, we have a promising fix here: https://github.com/zephyrproject-rtos/zephyr/pull/63560.

During the tests that I have run the past week, I see that further power cycling the TX board a few times every now and then can cause the issue to happen much faster.
With the fix linked above, however, my current test setup has run more than 24 hours, with me frequently try power cycling the TX board.

If you wish, please consider giving it a try. You can cherry-pick that fix to your zephyr repository. If you do, please run cherry-pick with merge strategy to prefer "theirs" code.

I will be out of office next week, but Simon will resume supporting you for this case.

Best regards,

Hieu

RE: connectless CTE TX/RX problem

Simonr — Fri, 15 Sep 2023 14:48:09 GMT

Just wanted to give you an update. This pull does seem to mitigate the issue, as it happens less often, but it's still there. Sometimes it takes 10+ hours to recreate though.

We've found out that the reason this happens is that the RTC0 seems to stop for some reason after some time has passed, and we're currently looking into why this is.

I will be out of office for the coming weeks, but my colleague Hieu will take over DevZone communication, and let you know when the development team has any updates on this issue. Thank you for your patience!

Our development team also requested that you make a github issue for this, as it is a bug in the BT controller we would like to address in a future release, and adding it to the GitHub issues would be best for them to address this.

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Wed, 13 Sep 2023 23:36:10 GMT

OK.

I'll test it too.

Thanks.

RE: connectless CTE TX/RX problem

Simonr — Wed, 13 Sep 2023 13:20:58 GMT

Just wanted to let you know we found a bug in the Bluetooth controller that we've added a fix for and is currently testing on our end. Thus far it's been running for 1,5 hours without a failure on my end at least. I want to give it some more time to run before I confirm/accept that this fixes the issue, but the pull request is available here at least, so you can test this on your end as well if you're interested.

https://github.com/nrfconnect/sdk-nrf/pull/12315

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Tue, 12 Sep 2023 16:11:00 GMT

OK.

I tested it.
1. add "CONFIG_BT_CTLR_SCAN_ENABLE_STRICT=y" to RX side
2. Add button press->scan_stop() processing to RX side
3. Run the test until reception on the RX side stops
4. After stopping reception, press the button
5. Check the return value of scan__stop()
result is zero.

RE: connectless CTE TX/RX problem

Simonr — Tue, 12 Sep 2023 12:47:17 GMT

But can you try calling bt_le_scan_stop() when the scan "just stops" here and see if you're able to stop the scan or if it returns an error?

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Mon, 11 Sep 2023 06:07:21 GMT

I don't quite understand it.
"returned from function calls."
What function is this returning from?
bt_le_scan_stop() is never called by anyone.
But the scan stops.

RE: connectless CTE TX/RX problem

Simonr — Mon, 11 Sep 2023 05:46:17 GMT

And you're still able to reproduce the scanner stopping altogether, correct? Note that you should also enable logging if you haven't to see error codes that are returned from function calls.

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Thu, 07 Sep 2023 14:29:54 GMT

I try it.

bt_le_scan_stop() symbol is not found.(No one calls bt_le_scan_stop())
I set a break-point on "set_le_ext_scan_enable()".
but, not be called.

RE: connectless CTE TX/RX problem

Simonr — Thu, 07 Sep 2023 11:22:43 GMT

Try setting CONFIG_BT_CTLR_SCAN_ENABLE_STRICT=y and see if you still see the bt_le_scan_stop() being triggered if/when this issue occurs. I don't think it will fix the issue entirely, but you should be able to see a bt_le_scan_stop() trigger when the scanner actually stops, and likely glean some information from what exactly called this scan_stop() function.

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Wed, 06 Sep 2023 14:06:22 GMT

sorry. My understanding is lacking.
What I need to do is
Just to confirm that this bug no longer occurs after setting "CONFIG_BT_CTLR_SCAN_ENABLE_STRICT=y"?
Or do I need to do something more than that?

RE: connectless CTE TX/RX problem

Simonr — Wed, 06 Sep 2023 12:51:01 GMT

CONFIG_BT_CTLR_SCAN_ENABLE_STRICT enforces returning HCI error commands on enabling/disabling already enabled/disabled scanning, which is what the hypothesis of what's happening currently is.

Best regards,

Simon

RE: connectless CTE TX/RX problem

loquat — Tue, 05 Sep 2023 14:54:49 GMT

thank you
But if my perception and yours are the same, the problem exists in the scan process.
The scan actually stops, even though I didn't call bt_le_scan_stop().
Does using "CONFIG_BT_CTLR_SCAN_ENABLE_STRICT=y" prevent scanning from stopping?

RE: connectless CTE TX/RX problem

Simonr — Tue, 05 Sep 2023 12:34:07 GMT

So now I've been able to reproduce the issue. It triggered ~15 minutes after I left yesterday, and again after ~2 minutes today. Can you try using CONFIG_BT_CTLR_SCAN_ENABLE_STRICT=y in your receiver's prj.conf. Then if there's a mismatch in the state of scanning in the controller, using bt_le_scan_stop() should return a failure from the controller and we might see an error code. You can also try implementing duplicate filtering enabled when scanning.

Best regards,

Simon

RE: connectless CTE TX/RX problem

Simonr — Mon, 04 Sep 2023 13:20:38 GMT

Following these instructions I haven't been able to reproduce this after running the RX sample connected to a PPK2 for ~40 minutes (all LEDs are on/blinking as expected and the current consumption shows RX occurring as expected). I'll leave it running when I head out today and see if it has occurred when I come into office tomorrow. If not, do you have more than two DKs available for testing so you can make sure it isn't the specific DK(s) you're using? Also, how far away from each other are the two devices placed when you do these tests? I have them no more than 0.5m away on my end.

Can you also show me how the DK and PPK you're measuring on are connected physically, and if you're testing in source meter or ampere meter mode.

Best regards,
Simon