S110 Advertising Access Address and other questions

[QuantumState]

I'm running the "Beacon Application for Eval Board" example for the S110 soft device on an nRF51822.

(devzone.nordicsemi.com/.../a00070.html)

I'm using another BLE device (not Nordic) to read the advertising packet and I'm curious as to some anomalies in its break down.

Here are the raw bytes of the packet I'm getting.

04:3e:2a:02:01:03:01:5b:31:04:a5:93:d5:1e:02:01:04:1a:ff:4c:00:02:15:01:12:23:34:45:56:67:78:89:9a:ab:bc:cd:de:ef:f0:01:02:03:04:c3:c2

Here is my (novice) break-down of the packet:

+----------+-----------------+------------+-------------------+------------------+
| ???      | ACCESS ADDRESS? | PDU HEADER | MAC               | LENGTH MFG INFO? |
|----------+-----------------+------------+-------------------+------------------+
| 04       | 3e 2a 02 01     | 03 01      | 5b 31 04 a5 93 d5 | 1e               | continued...
+----------+-----------------+------------+-------------------+------------------+

+----------------------------------------------------------------------------+
| MFG INFO A                                                                 |
+----------------------------------------------------------------------------+
| 02 01 04 1a ff 4c 00 02 15 01 12 23 34 45 56 67 78 89 9a ab bc cd de ef f0 | continued...
+----------------------------------------------------------------------------+

+--------------+-------------+-----+
| MAJOR, MINOR | TX STRENGTH | CRC |
+--------------+-------------+-----+
| 01 02 03 04  | c3          | c2  |
+--------------+-------------+-----+

Here are my questions:

I don't understand what the 04 at the begining is. It doesn't match what I thought were the only valid preamble values (0x55 or 0xaa).

Why is the Access Address value 0x3e2a0201? That doesn't match what I've seen elsewhere on the internet as the standard Access Address value of 0x8E89BED6 for advertisement packets.

I was under the impression that the second byte of the PDU HEADER was supposed to be the length of the rest of the PDU, but that doesn't seem to be the case with this packet.

I'm curious as to what beacon standard the PDU structure is complying (if any). Most information on the web is for the iBeacon and they don't have the byte after the MAC that I am interpreting as LENGTH MFG INFO or the byte at the end that I'm interpreting as some sort of CRC.

I'm guessing what I perceive as anomalies are just due to some bad information off the inter-webs, but I'm not sure how much of that info is bad and how much is good.

Thanks for helping a noob!

[QuantumState]

Lots of squinting at the 2000+ page Bluetooth 4.0 spec reveals that this is a host controller interface packet so there are indeed some bits and pieces added by the "host" (i.e. your operating system / driver). The packet decodes thusly:

04:3e:2a:02:01:03:01:5b:31:04:a5:93:d5:1e:02:01:04:1a:ff:4c:00:02:15:01:12:23:34:45:56:67:78:89:9a:ab:bc:cd:de:ef:f0:01:02:03:04:c3:c2

04 - This is an HCI Event packet (See "UART Transport Layer Table 2.1")

3e - The HCI Event Code is an LE Meta Event (See "Host Controller Interface Functional Specification 7.7.65")

2a - The total length of all event parameters is 0x2A octets (See "Host Controller Interface Functional Specification 5.5.4")

02 - The sub-event code is an LE Advertising Report Event (See "Host Controller Interface Functional Specification 7.7.65.2")

01 - There is 1 report in this event (See "Host Controller Interface Functional Specification 7.7.65.2")

03 - The event type is Non connectable undirected advertising (ADV_NONCONN_IND) (See "Host Controller Interface Functional Specification 7.7.65.2")

01 - The address type (of the remote BLE device) is Random Device Address (See "Host Controller Interface Functional Specification 7.7.65.2")

5b:31:04:a5:93:d5 - Device address (of the remote BLE device) (See "Host Controller Interface Functional Specification 7.7.65.2")

1e - The length of the data for the next (i.e. only) report (See "Host Controller Interface Functional Specification 7.7.65.2")

The rest (except the last byte) is a typical Apple Beacon format (you can find definitions of this on Stack Overflow and other places).

c2 - (Last byte) is the RSSI, i.e. the actual received signal strength (See "Host Controller Interface Functional Specification 7.7.65.2")

[Petter Myhre]

Thank you for answering your own question.

[QuantumState]

FYI for anyone else following the same learning ramp as me. The packet I was confused by was an HCI (Host Controller Interface) LE (Low Energy) Advertising Report Event. It is defined in the Bluetooth 4.0 spec - Volume 2 Part E Section 7.7.65.2. At least I think that is it. The 1st and 3rd octet of my packet don't seem to conform to that standard, but the rest of the packet does.

[Walter]

Hi, I'm running some tests on different kinds of beacons, and I found out that some of the stuff in that 14 bytes has actually a meaning, and may be not added from bluez. I have no idea about the first 2 bytes (04:3e) but the following 2a is the length of the packet. 02:01:xx is a pattern that shows the AD flags, and 01:xx:xx:xx:xx:xx:xx is the MAC address with 01 as header. The 1e after that is the length of the following MFG info. I agree that the last byte of the packets should be the CRC, but I'm still trying to figure out the meaning of the 04:3e. Since the question is old, do you have any updates to share about this?

[QuantumState]

Hey, Walter. Sorry I left this sort of hanging. By the time I figured it out, I forgot that I posted this question. I edited my answer to be more correct.