Fully understand advertising packet content?

[an-erd]

I configured a NRF52832 with non-scannable and non-connectable as well as scannable/connectable advertising. Everything is working fine.

But I want to fully understand the advertising and scan response packets. I did found a couple of tickets here, but they did not answer my questions.

The packets I receive in NRF Connect / Bluetooth low energy are as follows:

Non-scannable non-connectable advertising:

02 1d 00 ff ff 02 6b 7b 1d 9d 59 d7 00 04 99 42 19 eb 84 ce 06 17 01 02 01 06 13 ff ...

scannable/connectable advertising and scan response

02 1d 00 ff ff 02 6b 7b 1d 9d 59 d7 20 04 99 42 19 eb 84 ca 00 17 01 02 01 06 13 ff  ...
02 1d 00 ff ff 02 6b 7b 1d 9d 59 d7 20 04 99 42 19 eb 84 cb 01 17 01 0e ff ...

Everything starting with 02 01 06... almost at the end is clear (flags and manufacturer specific data). Unclear are the data at the beginning:

Length 2, Type 1d, 00: Simple Pairing Hash C-256, set to 0?

After that, it's completely unclear: Length 0xFF?

6b 7b 1d 9d 59 d7 is the device address.

Can you please support me or give a reference where to look at?

 

Regards

Andreas

[Edvin]

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

[an-erd]

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

[Edvin]

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

[an-erd]

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

[Edvin]

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. 

 

an-erd said:

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

 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: