BLE decode advertising header packet incorrect

[WilliamMcCoy21]

I have been decoding a BLE advertising packet, I am getting correct preamble and access address but once I try to decode the PDU starting with the header it is incorrect. The preamble and access address are simply decoded through GFSK , with the endian swapped on the access address. Is there typically some form of encoding used in the PDU header that could explain why I cannot decode the correct header? 

for example I am decoding the header to be 0x6F5B but using a BLE sig tester I can confirm the header is 0x201F, I know my decoding is working well before the header so I do not expect such drastic differences,

Thanks for your help in advance.

[tesc]

Hi,

Can you elaborate a bit on what you are doing?

Both in the old nRF5 SDK and in the new nRF Connect SDK, you get access to BLE on a much higher level. Are you instead using the radio peripheral directly?

Regards,
Terje

[WilliamMcCoy21]

Hi Terje,

Yes thats correct i am decoding directly from the radio peripheral,

Thanks,

William

[tesc]

Hi,

In that case I think you are basically down to consulting the Bluetooth Core Specification, as well as checking you do have the correct buffer sizes, etc., for correctly receiving the package. Please note also that depending on interference, you could receive erroneous messages (which checksums in the BLE protocol should detect.)

Are you consistently decoding the same wrong value?

Regards,
Terje

[WilliamMcCoy21]

Hi,

Thanks for your help, i dont think I'm having any buffer problems, I am consistently receiving the same value for the advertising packet header 0x6F5B, using another device I know it is really 0x201F. The preamble and access address are all correct, I think I may be missing some step in decoding the header of the advertising packet PDU, do you know if there is some encoding in place in the header?

Regards,

William

[tesc]

Hi,

There shouldn't be any encryption if this is a normal advertising packet, no. Maybe a missing field, or trouble with endianness or field sizes in the packet?

The bit patterns of 0x6F5B and 0x201F don't seem to map in any way shape or form.

Looking at the same packet from a sniffer should reveal the full contents, and should make it possible to look at and match bits for the whole packet.

Basically, you should see, after the preamble, a 4 octets access-address, followed by a 2 to 258 octets PDU. The PDU should have a 16 bit header and a 1 to 255 octets payload.

Bit and byte order can be a headache, I see from the Bluetooth Core Specification volume 6 part B section 2.3 Advertising physical channel PDU, that the header is in the "LSB" end of the PDU. Checking the "other end" of the packet and/or the "other" bit ordering might be worth a try. Also, check if the end of the packet payload or any other part of the PDU somehow maps to 0x6F5B, for figuring out how it all maps.

Regards,
Terje