Phone does not decode advert packet properly

[Jonathan]

We have a problem that we thought was isolated (affecting only one phone) until recently we started getting more phones exhibiting the same issue.

We are Australia based, and the issue has been noticed with "international" phones.

Take Blinky, compile, run, no problem.
Now put device name "RMD_qqQ2HawMBtyQ", "RMD-qqQ2HawMBtyQ" or "LP-KEYFOB". These phones won't read the advert properly anymore, and our app won't be able to connect anymore.

The advert decoded by this phones has the first 6 letters (generally) correct, and after, the decoded value varies. We use nRF Connect for testing, and while scanning is active, you can see the advert name constantly changing.

All of this is using S132 6.1.1 on SDK 15.3

The issue started when we upgraded from SDK 11 and S130 2.0.1 or S132 3.0.0 to SDK 15 and S132 6.0.0

Attached, the system information of  2 of the phones having issues. The 3rd one we don't have much info, besides it was an iPhone bought in Taiwan.

Our hypothesis is there's a communication issue between the phones and the nRF52 (nRF52832_XXAA). We suspect from one soft device to another, something like timing may have changed a little, and these phone possibly don't comply with specs.

 

[run_ar]

Hi,

I would recommend that you capture a sniffer trace so we can see what is happening on air. If you capture one trace of each, both working and non working so you can compare these to find the difference.

Note that in Bluetooth 5.0 a new field was added to the PDU, so it might be that the phone you are using is decoding this erroneously:

[Jonathan]

What type of sniffer trace would you consider? All I have available is Ubertooth. I doubt the changes with Bluetooth 5 would be causing the issue, as said, the original Blinky works fine, then simply change a few characters and it tursn complete wrong.

[run_ar]

Ok, so the blinky example that works also have the chsel bit? Can you try to change the device name in this example to see if it still works.

As for sniffer. If you have an extra DK or a dongle you could use this: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Sniffer

[Jonathan]

Yes, that's actually what I described in the report: taking the example from latest SDK, and changing the device causes the issue (on SOME phones, which have all been determined to be international imports, typically from countries where they are cheaper)

[run_ar]

Would it be a solution to avoid the advertisement names that causes problems with the phones? Is there a particular length that causes the problem? I.e. have you tried to gradually increase the length of the advertisement name to see when it fails?

It would still be interesting to get a sniffer log so I can see what is happening on air.

[Jonathan]

We haven't found a real correlation. Some longer names worked fine, and for instance, default "Nordic_Blinky" causes no problem unlike shorter "LP-KEYFOB". We thought maybe some "special" characters so we replaced "-" with "_", and then also removed it. Did not fix the issue.

I'll try obtaining captures.

[run_ar]

That is strange, could depend on the bit sequence. I suppose the traces will show that the advertiser is advertising what it should. Would be interesting to see how the phone actually decodes the packages, but unfortunately we just have to guess what is happening on that end.

Note that we have limited staffing during the Easter holidays (next week). And will probably not be able to respond in a timely manner. I am sorry for the inconvenience.