Beacon advertising packet format

RE: Beacon advertising packet format

Einar Thorsrud — Mon, 03 Jun 2019 12:51:26 GMT

Hi,

nRF Connect behaves differently depending on the platform it is running on. For instance, on iOS, you will not even see the MAC address of the device, but using nRF Connect for desktop you can get a lot of information. If you need to look at the raw packets you should instead us a sniffer. You can use nRF Sniffer if you don't have access to a professional BLE sniffer.

[quote user="abyr"]Question2: if I want the source address to be advertised without the type and length before it i.e I only want 6 bytes of the address after the header can I do it and how ? [/quote]

You can build the payload as you like, and keep it empty if needed. The rest is handled by the link layer in the SoftDevice and you cannot modify it directly. This is because the SoftDevice is designed to enforce that you send valid BLE packets. If you want to hand-write the packets, then you could just use the radio directly. It is usually not a good idea though.

RE: Beacon advertising packet format

abyr — Mon, 03 Jun 2019 11:34:12 GMT

Hi,

I did so but when I check the advertised data using NRF connect I find that the packet starts from the payload. the Preamble , access address , header and CRC calculation are not showing in raw data.

What could be the reason and how can I fix this ?

Question2: if I want the source address to be advertised without the type and length before it i.e I only want 6 bytes of the address after the header can I do it and how ?

RE: Beacon advertising packet format

Einar Thorsrud — Mon, 03 Jun 2019 07:05:32 GMT

Hi,

The stack handles the addresses automatically, yes. The default configuration is to use the static address, but you can choose to use a private resolvable address by calling sd_ble_gap_privacy_set(). Note that this cannot be done while advertising, so you should do this before starting to advertise. By default, the address will change every 15 minutes when using a resolvable address, but this can be changed by adjusting ble_gap_privacy_params_t::private_addr_cycle_s.

RE: Beacon advertising packet format

abyr — Fri, 31 May 2019 13:28:48 GMT

I have checked the ibeacon format here and I want to insert another field between the PDU header and data payload which is source address. My application should support both Static source address and private resolvable address, how can I do so is this also added automatically by the stack ? if not how can I add it it is not a manufacturer specific data

RE: Beacon advertising packet format

Einar Thorsrud — Fri, 31 May 2019 07:16:51 GMT

Hi,

Since you just need a simple beacon with manufacturer specific data, then you should probably use the Beacon Transmitter Sample Application. The advertising data in the example matches the iBeacon format, but you can easily replace this with your own. Most of what you need to think about is handled by the advertising_init() in the example.

[quote user=""]

My question is other than the raw data to be sent and size what should I change also ?

In other words, is the preambles access address, header, and CRC handled by the API or should I take care of it?

[/quote]

The link layer in the BLE stack (SoftDevice) will handle preamble, access address, header, and CRC automatically, so that is not something you have to think about. You just need to encode the advertising data and then provide it to the stack which does the rest. You should do that as shown in the beacon example:

Populate an array with your manufacturer specific data.
Make an ble_advdata_t and set the required fields (refer to the example), and point to your manufacturer specific data array as in the example.
Build the raw advertising packet by providing this to ble_advdata_encode()
Configure the SoftDevice to use this advertising data by calling sd_ble_gap_adv_set_configure().

[quote user=""]I have read the advertising tutorial, tried to inspect the code and it is still not clear, also the included driver files I do not see anything related to security which confuses me even more[/quote]

There is no security in a normal beacon. It just advertises clear-text packets that can be received by anyone. if you need security, then a beacon is probably not what you want to use. Instead, you should consider a BLE connection or similar (depending on your requirements).