Tuning the Bluetooth Advertising Interval on a Silicon Labs EFR32xG26 Beacon

Every Hubble beacon broadcasts on a schedule. That schedule, the advertising interval, sets how many times per second the radio keys up and how much battery the device burns doing it. Hubble’s sample firmware ships with a sensible default, but every deployment has its own balance of discoverability and power budget. A vehicle tracker that needs to survive on a coin cell for a year wants long gaps between transmissions, while a warehouse asset tag that needs to show up the moment it enters a scanner’s range wants the opposite. This tutorial tunes that interval on a Silicon Labs EFR32xG26 Dev Kit running Hubble’s Zephyr beacon sample, then proves the change actually reached the radio, using nothing but your phone.

The xG26 Dev Kit is built around the EFR32MG26B510F3200IM68, a 32-bit Arm Cortex-M33 that runs its 2.4 GHz radio on the same core as your application. There is no separate radio co-processor and no second firmware image to keep in sync, so this is one of the simplest boards you can use to connect to the Hubble network.

Getting Started

Before you begin, make sure you’re able to get a Hubble Beacon working on your Silicon Labs EFR32xG26 board by following our previous tutorial.

In this tutorial, you will continue to work with the Hubble beacon sample application in your Zephyr workspace. You also need to have the nRF Connect for Mobile app installed on your smartphone, which reads BLE advertisements straight off your phone’s own radio.

Modifying the Firmware

In the main() function in your main.c file, look for the bt_le_adv_start() call. It should look something like the following:

err = bt_le_adv_start(
    BT_LE_ADV_PARAM(BT_LE_ADV_OPT_USE_NRPA,
            BT_GAP_ADV_FAST_INT_MIN_2,
            BT_GAP_ADV_FAST_INT_MAX_2, NULL),
    app_ad, ARRAY_SIZE(app_ad), NULL, 0);

The Bluetooth advertising interval is defined by the second and third arguments to BT_LE_ADV_PARAM(), expressed in units of 0.625ms. By default, the sample uses BT_GAP_ADV_FAST_INT_MIN_2 and BT_GAP_ADV_FAST_INT_MAX_2, Zephyr’s built-in presets for 100 to 150 ms, respectively. Therefore, the sample firmware will automatically broadcast every 100-150 milliseconds.

To set a different advertising interval, change those arguments to your desired minimum and maximum values. For example, you can use BT_GAP_ADV_SLOW_INT_MIN and BT_GAP_ADV_SLOW_INT_MAX to advertise roughly once a second instead:

err = bt_le_adv_start(
    BT_LE_ADV_PARAM(BT_LE_ADV_OPT_USE_NRPA,
            BT_GAP_ADV_SLOW_INT_MIN,
            BT_GAP_ADV_SLOW_INT_MAX, NULL),
    app_ad, ARRAY_SIZE(app_ad), NULL, 0);

Note: Don’t confuse these firmware changes with CONFIG_HUBBLE_BEACON_SAMPLE_UPDATE_ADV_PERIOD in prj.conf. That option controls how frequently the encrypted payload content refreshes (five minutes by default), not how frequently the radio transmits it. You can change one without touching the other.

Build and Flash the Firmware

From your workspace root, build the firmware for your EFR32xG26 board with the command:

west build -p -b xg26_dk2608a modules/lib/hubblenetwork-sdk/samples/zephyr/ble-beacon

Then, flash your board with the command:

west flash

Tip: Before you try to validate your new Bluetooth advertising interval, confirm your board boots cleanly by checking the serial terminal. You should see the Hubble SDK initialize and the first advertisement get logged with no errors.

Validating Advertising Interval with nRF Connect

It’s tempting to check the Hubble dashboard for proof, but detections through the Terrestrial Network are probabilistic. They depend on how many gateways happen to be nearby and listening, not on your device’s actual transmit schedule, as Hubble’s own network documentation explains. A gap in the dashboard timeline tells you nothing about your true Bluetooth advertising interval.

The best way to validate the interval is with the nRF Connect mobile app:

1. Open nRF Connect on your smartphone and go to the Scanner tab.
2. Expand the filter bar and enter A6FC in the Filter by raw advertising data field. The Hubble service UUID is 0xFCA6, but 16-bit UUIDs are transmitted little-endian, so the bytes on air read A6 FC.
3. Tap the device row, then tap MORE to open its packet history.
4. You should see your Hubble beacon’s advertising interval in the Adv. Interval box and the timestamp differences between sequential packets.

When you inspect the advertising interval of the sample firmware before modification, you should see an advertising interval around 100 ms.

If you made the same firmware change specified earlier, you should see a new advertising interval of around 1 s.

Troubleshooting Tips

Two things will make the reading look wrong if you aren’t aware. First, your board automatically rotates its Bluetooth NRPA, so the beacon will periodically reappear as a brand-new row and its packet history starts over. Second, Android does not hand every advertising event to the nRF Connect app, so treat the numbers you see as an estimate. The comparison between the before and after readings is what proves your change reached the radio, not the absolute value.

If the filter finds nothing at all while the serial log looks healthy, work down the list in order. Confirm the filter reads A6FC and not FCA6, confirm “Only devices with names” is off, and confirm the log shows hubble_init() succeeding rather than halting on a missing NVS key.

Next Steps

A longer interval trades discoverability for battery life, which matters for a coin-cell asset tracker that needs to run for months, while a shorter one gets your device picked up faster in dense environments. Pair this interval tuning with the payload rotation period and your custom data payload, documented in the Hubble SDK configuration reference, to customize a beacon for your specific deployment. Register a production device at dash.hubble.com today to get started.

Ready to connect your devices anywhere on Earth? Get started with Hubble Network for free →