The Bluetooth 5.4 PAWR tag sometimes fails to receive broadcasts from the gateway.

[xht1987]

Both the NCS 3.0.2 NRF54L15 PCBA and DK development board occasionally fail to receive broadcast data. For comparison, running three PCBs simultaneously, the indicator light flashes when a broadcast is received. It can be observed that occasionally a few devices fail to receive the broadcast, while others do. These devices are placed next to the gateway, ruling out signal issues. 

> HCI Event: LE Meta Event (0x3e) plen 11 #217 653.068500
Unknown (0x25)
00 00 7f d1 ff 9e 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #218 654.160800
Unknown (0x25)
00 00 7f bf ff 9f 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #219 655.253200
Unknown (0x25)
00 00 7f d1 ff a0 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #220 656.345500
Unknown (0x25)
00 00 7f c7 ff a1 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #221 657.437800
Unknown (0x25)
00 00 7f cb ff a2 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #222 658.530200
Unknown (0x25)
00 00 7f d1 ff a3 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #223 660.714900
Unknown (0x25)
00 00 7f bf ff a5 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #224 661.807200
Unknown (0x25)
00 00 7f c7 ff a6 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #225 662.899500
Unknown (0x25)
00 00 7f d2 ff a7 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #226 663.991900
Unknown (0x25)
00 00 7f ce ff a8 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #227 665.084200
Unknown (0x25)
00 00 7f d2 ff a9 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #228 666.176600
Unknown (0x25)
00 00 7f ca ff aa 07 01 00 00 ..........

00 00 7f d1 ff a3 07 01 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 11 #223 660.714900
Unknown (0x25)
00 00 7f bf ff a5 07 01 00 00 The broadcast was lost here.

The image shows the timing sequence captured by a logic analyzer when no broadcast was received, with the GPIO pulled high during gateway transmission and the GPIO pulled high again during tag reception. The timing sequence indicates that the tag has correctly opened the receive window.  It can eliminate problems such as signal, interference, and reception timing. How to debug radio layer data reception?

[xht1987]

nrf52840: By examining the radio reception events through GPIO output, it was discovered that a CRC checksum error occurred when data was lost. Based on the AI's hints, a known bug was found. 

https://docs.nordicsemi.com/bundle/errata_nRF52840_Rev3/page/ERR/nRF52840/Rev3/latest/anomaly_840_245.html#ariaid-title1

How to solve this? According to AI, this is hardcoded into the underlying library, and users cannot modify it to verify it. Let's test whether 54L15 also has this problem.

[xht1987]

The device correctly opened the receive window, and the gateway's transmission timing was also correct, yet the device did not receive data. My testing revealed that this situation occurs frequently, averaging once a minute with a broadcast cycle of approximately one second. Occasionally, data is lost intermittently, receiving one data point only to lose it again. CRC checksum errors occur approximately once every 10 minutes.

We ran the ble_periodic_adv_sync_rsp and ble_periodic_adv_rsp examples on the 52840DK and 54L15DK development boards respectively. Through statistics, there are still cases of missed outputs, but the probability is lower. With a pawr cycle of 1 second, the output is missed about once every 400-500 runs.

[Sigurd]

Hi!

Can you test and see if you see the same issue with a newer NCS version ? e.g. NCS v3.2.4

[xht1987]

We also tested the latest NCS 3.2.4 and found that sync_cb itself can miss calls. That is, normally the gateway calls once per second, but sync_cb will occasionally miss one call, about once every few thousand times. This was just an accidental discovery during testing, which surprised us. We haven't investigated the specific probability and cause yet. The bigger problem is that when the RF underlying layer doesn't receive anything, buf && buf->len is empty when sync_cb is called back. Looking at the results captured by the logic analyzer using GPIO on the 54L15DK, the timing of the RF receive window opening is correct. At this time, the 52840DK receives the data, but the 54L15 receives nothing. Furthermore, the data whitening CRC check issue on the 54L15 has been resolved. We did not see this problem on the 52840 during testing.