BT5: are the payloads of each packet are the same?

[planewave]

I think it is better to make it a separate issue. The payload I mean the payload of the Extended Advertising Secondary Packet. From what I read in the source code, the transmitter-Linux is sending the same ODID payload repeatedly.

the first 3+25 bytes reference payload (ODID) that is supposed to be transmitted is:

F2 19 09 02 12 31 31 32 36 32 34 31 35 30 41 39 30 45 33 41 45 31 45 43 30 00 00 00

But what I decoded from the recorded over-the-air data (captured with an SDR) is different from packet to packet. Below are the first 3+25 bytes of 4 packets.

F2 19 09 02 0A 31 31 0F 37 32 1C 36 35 30 41 39 30 25 33 41 45 91 36 43 30 00 08 00
01 1A 09 02 12 E1 EB 06 3F 32 DC 31 35 30 41 39 30 C5 32 41 45 31 45 43 30 B0 77 A6
6B 50 0A BA 1E 31 31 32 DE 33 34 31 35 30 41 39 90 44 33 41 45 31 ED 0C 4F 00 40 73 
3E B3 0E CA 13 31 31 32 36 32 34 B1 3A 30 41 39 30 45 33 29 45 31 45 43 30 00 00 00

I can see some bytes are the same as the reference, but some are not. So either they are actually carrying different payloads or I didn't decode them correctly. I'd like to confirm with you before I go into some dead end.

Thanks

[friissoren]

I assume you are able to pick up the signals with the Android receiver application? I think you mentioned earlier that you got that working at least. If yes, that should prove that the transmitter is working correctly.

Which mode are you transmitting with? "l", "4" or "5"?

Legacy mode using the non-extended HCI API (i.e. option "l") will use this header.

Legacy mode using the extended HCI API (i.e. option "4") will use this header.

Long range mode using the extended HCI API (i.e. option "5") will use this header.

Each of them have several header bytes that never change. Try to look for those bytes in the packet data that you pick up with the SDR. Please note that the message counter byte will always change from one advertisement to the next.

[planewave]

sudo ./transmit 5 p The Android receiver is working fine, and I am writing my own SDR receiver. My question is about the actual ODID payload, which is, I believe, independent of the protocol used. For example, the first 3 bytes mean: ODID version 2, each message is 25 (0x19) bytes long and there are 9 messages in total. The next 25 bytes are the first message, Basic ID. I assume these payloads should be delivered as they are and all the same between BT5 packets. That is why it bothers me doing the decoding. I don't know where I got wrong.

[friissoren]

What if you dump the raw bytes from the transmitter? Then you know exactly what you should be looking for on the receiver side?

In bluetooth.c, in the hci_le_set_extended_advertising_data_pack() function, modify it to be:

    printf("Bytes being sent %d: ", sizeof(buf));
    for (int i = 0; i < sizeof(buf); i++)
        printf("%2X ", buf[i]);
    printf("\n\n");

    send_cmd(dd, ogf, ocf, buf, sizeof(buf));

BTW: keep in mind that only for the BT4 transmissions ("l" or "4") will the advertisements consist of a single 25 byte message (+ the header stuff). For BT5 Long Range + Extended Advertising (the "5 p" option you are using), all the 25 byte messages will be bundled together in a message pack and sent in a single advertisement.

[friissoren]

I don't know what your end goal is, but if you are trying to setup a reliable receiver that can capture all the packets from a transmitter (e.g. for testing compliance with US and EU rules), one possible option is to buy a Texas Instruments Bluetooth development board and use this SW for sniffing the Bluetooth transmissions: https://github.com/nccgroup/Sniffle

I have not tried this myself but I do know that someone is using it for this purpose. When both the transmitter and receiver are placed in a radio shielded room, this combination should be pretty reliable.

[planewave]

for your piece of code, that is exactly what I did to get the reference payload. and yes, I expect the same 9 messages with 25 bytes in length from each BT5 packet. I just ordered a CC2640R2 launchpad, then found that it does not support sniffing.

what I found is that the print-out payloads are all same 3+25*9 bytes. if you say that is what is transmitted, there must be something wrong with my decoding algorithm.