Each advertising event is a self-contained activity that happens on one specific advertising channel. Here is the sequence of what can occur within a single event:

The three packet types explained:

An Advertiser does not send just one packet per advertising interval. It sends advertising packets on all three advertising channels consecutively, then waits before repeating. The channel rotation is always in the same order: channel 37 first, then 38, then 39, then back to 37 again.

A sniffer capture of six advertising events shows this rotation clearly:

Notice frames #427, #428, and #429 — they are all on channel 37 and they together form a single advertising event. Even though three packets are exchanged, it is still one event because it is all on one channel without a channel change. This confirms the rule: an advertising event stays on one channel throughout.

The time between the start of two consecutive advertising events is controlled by two parameters working together. Understanding these is essential for balancing how quickly a device can be discovered against how much battery it uses.

Why is there a random delay? The advDelay is deliberately randomised by the BLE stack on every cycle. If two devices happened to be advertising at exactly the same interval, their packets would always collide on the same channels at the same time — every cycle. By adding a small random delay, the two advertising sequences quickly drift apart in time, so collisions only happen occasionally rather than every single cycle.

The BLE 4.1 specification introduced a low duty cycle directed advertising mode. This is useful when a device wants to reconnect to a specific known peer but does not need the reconnection to happen immediately. In this mode, advertising packets are sent at a very low rate, significantly reducing power consumption. If the peer comes into range, they will eventually discover the device and reconnect. This is the right mode for a fitness tracker that lost Bluetooth contact with its paired phone and is patiently waiting for the phone to come back within range.

/* Setting BLE advertising parameters with BlueZ HCI */
/* Equivalent of: hciconfig hci0 leadv */

#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>

int setup_advertising(int hci_sock)
{
    le_set_advertising_parameters_cp adv_params;
    memset(&adv_params, 0, sizeof(adv_params));

    /* Advertising interval in units of 0.625 ms */
    /* 0x0020 = 32 units × 0.625 ms = 20 ms (fastest/most battery) */
    /* 0x0800 = 2048 units × 0.625 ms = 1280 ms (balanced)         */
    /* 0x4000 = 16384 units × 0.625 ms = 10240 ms (slowest/lowest) */
    adv_params.min_interval = htobs(0x0800); /* 1280ms */
    adv_params.max_interval = htobs(0x0800);

    /* Advertising type:                                            */
    /* 0x00 = ADV_IND    (connectable undirected — most common)     */
    /* 0x01 = ADV_DIRECT_IND (connectable directed — fast connect)  */
    /* 0x02 = ADV_SCAN_IND   (scannable undirected — beacon mode)   */
    /* 0x03 = ADV_NONCONN_IND (non-connectable — broadcast only)    */
    adv_params.advtype = 0x00; /* ADV_IND */

    /* Use all three advertising channels */
    adv_params.chan_map = 0x07; /* bits: ch39=1, ch38=1, ch37=1 */

    /* No filter — respond to all scan requests and connect requests */
    adv_params.filter_policy = 0x00;

    struct hci_request rq = {
        .ogf    = OGF_LE_CTL,
        .ocf    = OCF_LE_SET_ADVERTISING_PARAMETERS,
        .cparam = &adv_params,
        .clen   = LE_SET_ADVERTISING_PARAMETERS_CP_SIZE,
    };

    return hci_send_req(hci_sock, &rq, 1000);
}

Once two BLE devices are connected, all data transfer happens inside connection events. A connection event is a scheduled window of time during which the Master and Slave exchange data on a single data channel. The channel changes between events using the adaptive frequency hopping algorithm discussed earlier.

The start of a connection event is called an Anchor Point. This is an important concept because it is the fixed timing reference that both Master and Slave synchronise to. The Anchor Point is always controlled by the Master — the Master defines when connection events start.

Key rules of connection events:

• All packets within one connection event are on the same frequency — no hopping during an event
• Channel hopping occurs at the start of each new event — frequency changes between events
• The Master always transmits first at the Anchor Point — the Slave listens and responds
• The Slave always responds to a Master packet; the Master may or may not respond to Slave packets
• Either device (Master or Slave) can close the connection event

The connInterval is the time between the start of two consecutive connection events — equivalently, the time between two successive Anchor Points. It is expressed as a multiple of 1.25 milliseconds and must be in the range of 7.5 ms to 4.0 seconds.

The connInterval is negotiated between the Master and Slave during connection setup and can be renegotiated during an active connection. For example, a heart rate monitor streaming data every second would want a short interval during active monitoring, but could request a longer interval when idle to save battery.

/* Requesting a connection interval update from a Peripheral (Slave) */
/* This uses the L2CAP Connection Parameter Update Request           */
/* In BlueZ, the application triggers this via the GATT layer        */

/* hcitool command equivalent: */
/* hcitool lecc --interval 40 --latency 0 --timeout 500 AA:BB:CC:DD:EE:FF */
/* --interval 40 = 40 × 1.25ms = 50ms connection interval                 */
/* --latency  0  = 0 events can be skipped (slave latency)                 */
/* --timeout 500 = 500 × 10ms = 5s supervision timeout                    */

/* In a C program using BlueZ GATT: */
/* bt_gatt_client_set_conn_params() can request new parameters from host  */