nRF52832 SDK14.2.0 advertising tutorial

This value might, e.g., enable other units to roughly estimate the distance to
your device. (keep in mind that you will have to use one of the valid tx power
levels in nRF52 Product Specification). It is also important to know that this
doesn't change the actual transmit power, just the information that is advertised.

add code below in advertising_init()

int8_t tx_power = 0x04;

init.advdata.short_name_len = 2;
init.advdata.p_tx_power_level = &tx_power;
                  

Note: To add the tx power level according to the TLV format, (Type: 1B, Length: 1B,
Value: 1B) at least 3 Bytes needed, the content size should <= 31 bytes. So, we
change the name length to 2. You can check:
https://devzone.nordicsemi.com/question/37952/setting-tx_power_level/

set code below in advertising_init()

init.advdata.include_appearance = true;
                  

set code below in gap_params_init()

err_code = sd_ble_gap_appearance_set(BLE_APPEARANCE_HID_MOUSE);
APP_ERROR_CHECK(err_code);
                  

The appearance feature might be useful to developers of e.g. mobile phone apps.
If you have a BLE enabled phone (or a laptop) your kit should now show up with
the name "Th" and a computer mouse icon if you search for BLE devices.

Tips: Your advertisement packet is already getting dangerously full so you
might want to shorten your manufacturer data size or device name.

Advertising is the act of broadcasting data. We broadcast data for device discovery
and data publishing. There are 2 types of data packets that can be transmitted,
Advertising packet and Scan Response packet, each can have up to 31 bytes payload.
The advertiser address is included in the broadcast data in addition to the payload.

The advertiser constantly broadcasts advertising packets with an advertising interval.
Advertising interval can be changed on the fly. There is a requirement for minimum and
maximum advertising interval.

For normal, undirected advertising, the advertising intervals ranges from 20ms
to 10.24s (Section 7.8.5 Part E Vol2)

The scan response packet is transmitted by the advertiser when it receives a scan
request from a scanner. The advertiser have to enter a RX period to wait for the
scan request. This RX period can be used to receive Connect Request as well.

In some applications when we don't expect a connection and don't have extra data
in scan response packet, we can advertise in non-connectable mode and can skip
the RX period to save power. The beacon application is one of the use cases.

Note that all Advertising packet, Scan Request packet, Scan Response packet share
the same on-air Access Address = 0x8E89BED6. This common address allows any
device to scan and receive advertising/scan response data.

Bluetooth Smart uses 40 RF channels in the ISM band (2.4GHz). These RF channels
have center frequencies 2402 + K*2MHz where k ranges from 0 to 39. Note that k
is not the same as "Channel Index", or channel number (Section 1.4 Vol 6 Part B).

Three of them is dedicated for advertising which is channel 37 (2402MHz), 38(2426MHz),
and 39 (2480MHz). They were selected to avoid interference with the busy channels
used by Wifi.

In the implementation of SoftDevice stack, by default it transmit the advertising
packet in all 3 channels on every advertising event, on channel 37, 38, 39 respectively.

When advertising, the network topology is Broadcast topology. There could be
multiple advertisers and multiple scanner at the same time.

Note that one device can do scanning and adverting simultaneously. And one can
be in a connection with a central or peripheral and can do advertising at the
same time.

The only packet the active scanner can send to advertiser is the Scan Request
packet, which contain only the scanner address. Passive scanner doesn't do
Scan Request.

There are 4 defined types of Advertising (Section 2.3.1 Vol 6 Part B)

• ADV_IND: connectable undirected advertising. This is the normal advertising
  type where any device can send scan response packet and connect request to
  the advertiser.
  

• ADV_DIRECT_IND: connectable directed advertising. You use this to direct your
  advertise packet to one specific central to ask for connection. The packet is
  still a broadcast packet but other scanners will ignore the packet if the peer
  address is not matched with them. And connect request or scan request from
  unmatched central will be ignored by the advertiser. Directed advertising usually
  comes with high duty cycle with interval fix at 3.75ms. For low duty cycle directed
  advertising, it's configurable and should be <10ms. (Section 4.4.2 Part B Vol6)
  

• ADV_SCAN_IND: scannable undirected advertising. This advertising packet won't
  accept connect request but accept scan request.
  

• ADV_NONCONN_IND: non-connectable undirected advertising. This is non RX mode,
  which mean the advertiser will not accept any connect request or scan request.
  Staying in this mode the advertiser doesn't need to switch to receiver mode
  and can save power. The main application for this is beacon application, where
  maximize battery life time is most important and the beacon doesn't need to
  interact with the scanner.
  

The advertiser can use a whitelist to limit the interaction to a number of scanner/central
device. The whitelist contains an array of the peer device addresses or IRK numbers
(when central use resolvable random address). It will reject packets from scanners/centrals
whose addresses are not in the list. Whitelist can be configured to filter scan
request packets, connect request packets or both.

This shows whether the device is bonded to another device or not. The purpose
of bonding is:

The purpose of bonding is to create a relation between two Bluetooth devices
based on a common link key (a bond). The link key is created and exchanged
(pairing) during the bonding procedure and is expecteed to be stored by both
Bluetooth devices, to be used for future authentication.

• set, clear or update advertising data and the scan response data
  

  sd_ble_gap_adv_data_set(uint8_t const* p_data, uint8_t dlen, uint8_t const* p_sr_data, uint8_t srdlen)
                        

• start advertising
  

  sd_ble_gap_adv_start(ble_gap_adv_params_t const* p_adv_params, uint8_t conn_cfg_tag)
                        

—
Check how the 31 bytes Advertising data and Scan reponse data should look like
(chapter 11, part C, vol3)

It's up to the application to prepare the advertising data and set it in the
softdevice using sd_ble_gap_adv_data_set().

Note:

• The data in the input parameter is an array of uint8_t. You need to encode data
  to match with this.
  
• You should set the length of the advertising data (dlen) to match with the significant
  part length so that the non-significant part (zero padding) will not be transferred
  over the air.
  
• 31 bytes includes also the overhead so the actual payload for application is
  27 bytes when using manufacturing data type.
  
• Flags can only be excluded if non-connectable advertising is used.
  

—

After you have set-up the advertising packet you can tell the softdevice to start
advertising by calling sd_ble_gap_adv_start(). For this call, you need to configure:

• Advertising interval (the period between each advertising)
  
• Advertising timeout: how long you want to advertise. You will receive
  BLE_GAP_EVT_TIMEOUT event after this timeout.
  
• Advertising types (connectable, non-connectable, directed, etc)
  
• The peer address if you do directed advertising
  
• The whitelist list if you have
  
• Filter policy: Choose how to use the whitelist, filter scan request, connect
  request or both
  
• Channel(s) you want to advertise, you can choose one or two or all 3 channels
  to advertise
  

• BLE_GAP_EVT_TIMEOUT
  Occurs when the advertising timeout is passed. The application can decide to
  continue advertising in different mode or to enter sleep mode. The application
  should check the src parameter to check if the timeout event is from adverting
  timeout or not.
  

• BLE_GAP_EVT_SCAN_REQ_REPORT
  the application receives this event when there is a scan request received by
  the advertiser. The event comes with address of the peer device and RSSI value.
  Note: you only get this event if you enable it using the option API
  sd_ble_opt_set()
  

• BLE_GAP_EVT_CONNECTED
  You receive this when there is a central device send connect request and the
  connection is established.
  

• Why am I seeing the advertising period is not the same between each packet?
  Bluetooth spec defined a random delay (0~10ms) on each advertising peroid
  to perturb interval and avoid interference (Section 4.4.2.2 part B vol6)
  
• If I want to advertise my custom data how should I put it in the advertising packet?
  You should use Manufacturer Specific Data ADtype (0xFF). Note that with that
  type, the 2 first bytes are for Company ID.
  check:
  https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile