Fully understand advertising packet content?

RE: Fully understand advertising packet content?

Edvin — Tue, 10 Mar 2020 11:26:10 GMT

Oh. So it is not part of the advertising data (or in a way it is). It looks like the serial protocol that the connected DK or dongle (in your case dongle) use to pass the radio data to the computer. Nothing you need to worry about.

[quote user="an-erd"]This sequence (0a 2a c6 1e 51 c6) is clear, too, that's just the devices Bluetoth address, but what about the remainder?[/quote]

No, the address is found in:

peerAddr:[address:C6:51:1E:C6:2A:0A

(from your log).

I realize first now that you are in the logging module for the nRF Connect for Desktop. This is actually most for debugging nRF Connect. Not really related to BLE. All the information that you need is found in the actual application:

RE: Fully understand advertising packet content?

an-erd — Tue, 10 Mar 2020 09:45:10 GMT

The log entries I provided in my last message is produced by a clean unmodified version of the SDK example ble_app_beacon. So, it's exactly as provided with SDK 16.

The log file entry is produced with nRF Connect and the NRF52840 dongle, so also straight forward.

Don't care about the manufacturer specific data, that's everything well understood. I'm only interested in the beginning, so this data:

02 1d 00 ff ff 02 0a 2a c6 1e 51 c6 00 00 01 00 00 30 82 d1 06 1e 01

This sequence (0a 2a c6 1e 51 c6) is clear, too, that's just the devices Bluetoth address, but what about the remainder?

Regards

Andreas

RE: Fully understand advertising packet content?

Edvin — Tue, 10 Mar 2020 09:36:06 GMT

Oh, I missed the 02 01 04 1a ff ... part.

02 01 04 = len: 2 type: 01 (flags), value: 04 (BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED).

1a ff ... = len: 26, type: ff (manufacturer specific data), and the rest is probably the manufacturer specific data that you have set.

Where does that log come from? Is that one of our examples scanning?

What did you set up the manuf.specific data to be?

BR,

Edvin

RE: Fully understand advertising packet content?

an-erd — Mon, 09 Mar 2020 18:04:41 GMT

Hello Edvin,

thanks for your reply. My code was based on the example ble_app_beacon. Just to be sure I tested with ble_app_beacon, too.

The results are pretty much the same, since I only changed the manufaturer specific data, but did'nt touch everything else.

With the original ble_app_beacon example I get the following lines:

2020-03-09T17:55:51.876Z DEBUG GAP_EVT_ADV_REPORT/ADV_NONCONN_IND time:2020-03-09T17:55:51.875Z connHandle:65535 rssi:47 peerAddr:[address:C6:51:1E:C6:2A:0A type:randomStatic addrIdPeer:0] scanRsp:false advType:advNonconnInd gap:[adTypeFlags:[brEdrNotSupported,leOnlyLimitedDiscMode,leOnlyGeneralDiscMode] manufacturerSpecificData:89,0,2,21,1,18,35,52,69,86,103,120,137,154,171,188,205,222,239,240,1,2,3,4,195]
2020-03-09T17:55:51.978Z DEBUG    23/ 0 <-  [02 1d 00 ff ff 02 0a 2a c6 1e 51 c6 00 00 01 00 00 30 82 d1 06 1e 01 02 01 04 1a ff 59 00 02 15 01 12 23 34 45 56 67 78 89 9a ab bc cd de ef f0 01 02 03 04 c3 ] type:     VENDOR_SPECIFIC reliable:yes seq#:4 ack#:5 payload_length:35 data_integrity:1 header_checksum:b3 err_code:0x0

I used nRF Connect Bluetooth Low Energy with an nRF52840 dongle. After my device (I used a different test beacon with address C6:51:1E:C6:2A:0A was discovered I just copied those lines from the log file.

Again, after 02 01 04 1a ff.... everything is clear.

02 1d 00 ff ff 02 0a 2a c6 1e 51 c6 00 00 01 00 00 30 82 d1 06 1e 01 02 01 04 1a ff 59 00 02 15 01 12 23 34 45 56 67 78 89 9a ab bc cd de ef f0 01 02 03 04 c3

But I'm interested in the data from the beginning up to that 02 01 04 1a ff.

Regards

Andreas

RE: Fully understand advertising packet content?

Edvin — Mon, 09 Mar 2020 13:54:28 GMT

Hello,

All advertising packets consists of one or more chunks containing the following:

1st byte in each chunk contains the length of the chunk. In your case 02.

The second byte contains the advertising chunk type, in your case 1d.

Then the payload for that byte which is 00.

Are you sure the 4th byte is ff? That should be the length of the next chunk, but it can't be 0xff long.

Did you create the payload of the peripheral? Is it the ble_app_beacon example?

You can check out this guide from silabs, which explains how the advertisement packets are set up:

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/02/10/bluetooth_advertisin-hGsf

In addition, this page contains all the advertising type fields:

https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/

As you can see, the type 1d is Simple Pairing Hash C-256. Check out Core specification supplement part A section 1.6

So what kinf of peripheral is this?

Best regards,

Edvin