52840 advertising data not received by certain Android devices

[RickW]

We have a 52840 based beacon with two versions.  Both have exactly the same firmware and PCB, one has a N52840-Q1AAD0-2025KR written on the chip and the other has N52840-Q1AAD0-2045RN written on the chip.  In all cases, the advertising packets from both devices to any iOS device, and Android 7,9 and some 10 devices.  However, on some Android 10 devices, they only receive advertising packets from the 2025KR version of the beacon.

The full raw packet from the 2025KR version that is successfully received by ALL devices is:

00000000: 3E38 0D01 1326 01C3 DF6E B773 F081 00FF >8...&...n.s....
00000010: 7FcalcDB 0000 0000 0000 0000 001E 0201 0502 ................
00000020: 0A08 0302 0001 07FF 564C 32C9 0002 0B09 ........VL2.....
00000030: 4C76 4274 6E20 6466 6333 LvBtn dfc3

The full raw packet from the 2045RN version which is not received by certain Android 10 devices is

00000000: 3E38 0D01 1326 01FC 05C7 62D9 D781 00FF >8...&....b.....
00000010: 7FCC 0000 0000 0000 0000 001E 0201 0502 ................
00000020: 0A08 0302 0001 07FF 564C 32C9 0002 0B09 ........VL2.....
00000030: 4C76 4274 6E20 3035 6663 LvBtn 05fc

The latest version of nRF Connect is installed on the Android 10 devices (the ones which do not receive the 2045RN packets) also does not show anything.  We looked at advertising packets received by iOS in nRF Connect and the only difference we saw is the kcbAdvDataRxPrimaryPhy is 129 for the 2045RN packet, and this value is 0 for the 2025KR packet.  We have other 52832 based beacons which also show kcbAdvDataRxPrimaryPhy = 129 (and appear on all Android devices) so do not think this is the issue but it was noteworthy possibly. 

We have tried changing advertising intervals, transmission power, etc with no luck.  Also, on the same Android 10 devices which ignore the 2045RN version, bluetooth receives packets properly from other 52840 beacons we have.

Any ideas for a setting in the SDK we need to change on the firmware to get these packets to show up?

Thanks

[Susheel Nuguru]

That seems strange.

Are the two beacons transmitting at the same time? Is it possible that there are collisions? Are the advertising packets ?

Have you tested this with multiple 2045RN chips and the failing behavior is same on all?

Do you have a sniffer trace to check if the advertisement packet is being transmitted properly by the chips?

It is possible that the failing chip may have some clock accuracy issue. Can you specify which LFCLK you are using for your designs?

[RickW]

1) They are broadcasting at the same time, but it doesn't seem to have issues with iOS devices seeing both.  Also, other Android devices are able to see both.  

2) Yes, these are advertising packets

3) The only sniffer I have is on the receiver, where I captured the packets listed above.  There are some differences in the packets sent

2025KR

00000000: 3E38 0D01 1326 01C3 DF6E B773 F081 00FF >8...&...n.s....
00000010: 7FDB 0000 0000 0000 0000 001E 0201 0502 ................
00000020: 0A08 0302 0001 07FF 564C 32C9 0002 0B09 ........VL2.....
00000030: 4C76 4274 6E20 6466 6333 LvBtn dfc3

2045RN

00000000: 3E38 0D01 1326 01FC 05C7 62D9 D781 00FF >8...&....b.....
00000010: 7FCC 0000 0000 0000 0000 001E 0201 0502 ................
00000020: 0A08 0302 0001 07FF 564C 32C9 0002 0B09 ........VL2.....
00000030: 4C76 4274 6E20 3035 6663 LvBtn 05fc

4) The LFCLK seems to be a no-name brand 32Khz.  The same one is used on both PCBs, however I just noticed that on the PCB where it is not working, this 2-pin clock IC is reversed.  

5) I tried 4 devices that use the 2025KR and 7 devices that use the 2045RN and all had the same behavior.  All the 2025KR devices work and all the 2045RN devices don't

If there is a clock accuracy issue, I might be able to disable the low-frequency clock and see if it works.  Could an issue with the high frequency clock also do something like this?

Thanks for the help

[Susheel Nuguru]

The beacons are not required to have very strict timing in terms of their start time. There is also great tolerance in terms of adv delay of 0-10ms. If other phones are able to read the packets, then I assume that the transmission from the beacons are working fine. 

I would still try to check the XTAL clocks accuracy you are using. do you observe that there can be any difference in these both?

Also, can you please setup an BLE air sniffer and sniff the packets of both 2025KR and 2045RN to see if there are any ambiguities in terms of timing of the packets? I still strongly suspect that this is something from the Android BLE stack implementations on the phones that are not able to receive this beacon packets and not on the nRF side.