Adaptive frequency hopping (AFH) lets Bluetooth and Bluetooth Low Energy devices dodge interference by hopping across the 2.4 GHz band and excluding noisy channels. Here is how the channel map, hopping sequence, and developer APIs actually work.
What Is Adaptive Frequency Hopping and Why Does It Matter?
Adaptive frequency hopping (AFH) is a spread spectrum technique that helps wireless systems stand up to radio frequency interference. Rather than sitting on a single fixed frequency, it rapidly shifts the carrier between channels and steers clear of crowded ones. The transmitter and receiver stay in sync and follow a shared hopping sequence, so the conversation gets spread across many channels in the 2.4 GHz ISM band. In Bluetooth, connected devices keep an eye on their surroundings and update a channel map accordingly—noisy channels get dropped, and only the good ones stay in use.
The 2.4 GHz band is a mess, and that's really why AFH matters. Wi-Fi access points, microwaves, cordless phones, and a flood of IoT sensors are all fighting over the same slice of spectrum. If your hopping pattern is fixed, there's nothing you can do about an interferer that just won't go away. But if it adapts, you can hop around the problem. The Bluetooth Special Interest Group (SIG) built AFH into the spec as a core coexistence mechanism, and it's actually mandatory if you want to transmit above +10 dBm. Skip it, and higher-power Bluetooth links would jam each other far worse than the band could ever handle.
AFH also has a security angle worth mentioning. Since the hop sequence is pseudo-random and keeps shifting, it's much harder for an attacker to predict where the next packet will show up. That's not a substitute for encryption, obviously, but it does make passive interception and jamming more expensive to pull off. If you're building wireless products, the cleanest way to think about AFH is as a dynamic spectrum-management layer sitting between the radio hardware and the application.
Before we go any further, it's worth getting the terminology straight. AFH also shows up in the literature as adaptive frequency-hopping spread spectrum, and it sits under the larger FHSS (frequency-hopping spread spectrum) umbrella. In datasheets and spec documents, you'll run into terms like channel map, channel classification, channel assessment, channel exclusion, channel re-inclusion, hop sequence, dwell time, piconet, RSSI, PER, and PDR. They sound like a lot to memorize, but really they all describe different parts of one feedback loop: check how a channel is performing, decide whether to keep using it, and then let the other device know what changed.
How AFH Works: Channel Maps, Hopping, and Interference Detection
In Bluetooth, every connection event picks a channel from the ones currently available, and it does so deterministically through a channel selection algorithm. Both devices then hop onto that channel, so communication ends up spread across a constantly shifting set of frequencies in the 2.4 GHz band. The primary device keeps track of a channel map that marks each channel as either used or unused, and it passes that map along to the second device via a link layer procedure. This shared state is really the foundation of the whole scheme — it guarantees that both sides are always on the same page about which channels are allowed at any given moment.
How a device decides which channels to keep or drop comes down to its own implementation. When a channel that used to work fine starts to degrade, the channel map gets updated to exclude it. On the flip side, if a channel that was performing poorly improves, its status is updated and it can be re-included. The assessment itself usually comes down to RSSI (Received Signal Strength Indication) and PER (Packet Error Rate). If a channel shows sustained high received power or keeps racking up packet errors, it becomes a candidate for exclusion. But if it stays clean across repeated measurements, it can earn its way back in.
Silicon Labs gives us a concrete look at how this loop actually runs in firmware. A background task periodically sweeps through every channel and measures the received power on each one. If that measured power goes beyond -71 dBm, the channel gets blocked. Once a sweep finishes, a fresh channel map is built, and the central device passes the new map along to its slaves. By default, the afh_scan_interval is set to 1 second, with a unit of 10 ms. Sweeping all 40 channels takes about 10 ms, and the extra energy this adds comes out to roughly 240 uW.
Later research took this idea a step further. In December 2021, Valentin Poirot and Olaf Landsiedel from Kiel University and Chalmers University of Technology presented eAFH in arXiv:2112.03046v1. Their approach adds what they call informed exploration for channel exclusion and inclusion — instead of blindly retesting channels, it leans on past measurements to figure out which frequencies are most likely to be worth bringing back. The results are impressive: 98–99.5% link-layer reliability even with dynamic Wi-Fi interference, only about 1% control overhead, and 40% more channel diversity than the best existing methods at the time.
Zoom out a bit, and FHSS is pretty simple: you chop the communication into chunks and send each chunk on a different frequency, following a repeating sequence. Both ends share that sequence, and it's typically generated from a pseudo-random plan. AFH then layers a feedback loop on top of it. The hopping pattern isn't purely fixed anymore, since the pool of usable channels keeps shrinking and growing as the radio environment around it changes.
AFH in Bluetooth vs Bluetooth Low Energy: Channels and Specifications
Bluetooth Classic and Bluetooth Low Energy carve up the 2.4 GHz band in very different ways, and those numbers actually matter when you're trying to tune a link. Before AFH came along, Bluetooth devices used 79 of the 83.5 channels available in the 2.4 GHz band and hopped 1,600 times per second. Bluetooth LE takes a different approach, splitting the band into 40 channels, 37 of which are general-purpose channels you can use for connected communication. On top of that, the Bluetooth Specification sets a floor of at least twenty channels whenever AFH is in play, which means you're guaranteed some usable spectrum even in a really crowded environment.
Bluetooth LE handles BIS PDUs with Channel Selection Algorithm #2, which is spelled out in Vol. 6 Part B of the core spec. The channel map update procedure goes back even further—it was introduced in Bluetooth 4.0—and here's the catch: only the central (master) device is allowed to kick it off. That asymmetry matters more than it might seem at first glance. A peripheral device can't just decide on its own that a channel is bad and drop it. Sure, it can report link quality through the link layer, but the central device is the one that actually owns the channel map and pushes out any updates.
The table below puts the key parameters side by side. Use it as a quick reference, not as a replacement for the actual specification—vendors and SDK versions differ, so the implementation details won't always line up.
| Parameter | Bluetooth Classic (pre-AFH) | Bluetooth Low Energy |
|---|---|---|
| Channels in 2.4 GHz band | 79 of 83.5 | 40 total, 37 data channels |
| Hop rate | 1,600 hops per second | Per connection event |
| Minimum AFH channels | At least twenty | At least twenty |
| Channel selection | Classic hop sequence | Channel Selection Algorithm #2 for BIS PDUs |
| Who updates the map | Central/master only | Central/master only |
| AFH required above | +10 dBm TX power | +10 dBm TX power |
Audio traffic adds another constraint. Bluetooth audio generates roughly 300 kbit/s with data transmission every 15 ms, which means the link cannot afford long disruptions on a bad channel. When AFH excludes a noisy channel, it protects that continuous stream. The scale of the ecosystem explains why this matters: more than 4 billion Bluetooth and BLE devices were produced in 2020 alone, according to Bluetooth SIG figures, and every one of them shares the same crowded band.
Implementing AFH: Scan Intervals, Blocking, and Developer APIs
Enabling AFH in the Silicon Labs SDK starts with installing the AFH software component. In current SDKs, sl_bt_init_afh() is automatically called inside sl_bt_init() by the code generator, so most applications get AFH without writing extra code. In older SDK versions, you call gecko_init_afh() after gecko_init(&config). This is a good example of how AFH is usually a configuration concern rather than an application-logic concern.
Changing the scan interval requires a few specific steps. You define AFH_SCAN_INTERVAL_CONFIG_KEY 7, set the afh_scan_interval value, and then call sl_bt_system_linklayer_configure or gecko_cmd_system_linklayer_configure. Because the unit is 10 ms, a value of 100 corresponds to the default 1-second scan interval. Nordic Semiconductor documents related behavior for its nRF5340 chip and in Nordic DevZone discussions, while Texas Instruments covers AFH in application note swra487.
The blocking behavior is worth understanding before you tune anything. A measured power beyond -71 dBm blocks a channel for at least 8 afh_scan_intervals. Unblocking requires 8 consecutive measurements with no interference. That hysteresis prevents a channel from flapping in and out of the map every sweep, but it also means recovery is deliberately slow. In a rapidly changing environment, a channel that just cleared may stay excluded for several seconds.
One operational caveat: the AFH sweep has the highest priority and may block other operations if multiple operations occur within the same 10 ms window. If your application schedules time-sensitive radio work, account for the sweep. Zebra's TC57 and PS30 product reference guides and Honeywell SPS documentation show how these constraints surface in real deployments, where AFH settings are often tuned per site rather than left at defaults.
For developers who want explicit control, sl_bt_gap_set_data_channel_classification allows the host to influence channel classification. That path is useful when the application has context the link layer does not, such as a known interferer location or a scheduled quiet period. Used carefully, host-side classification complements the automatic sweep rather than replacing it.
AFH Benefits, Limitations, and Coexistence with Wi-Fi
The benefits of AFH are well established. It improves interference resistance, enhances security through pseudo-random frequency changes, optimizes spectrum utilization, and enables dynamic frequency allocation without manual intervention. Compared with non-adaptive channel blocking, which requires someone to manually disable channels, AFH dynamically blocks low-quality channels as conditions change. That difference is decisive in consumer products, where no one is going to hand-tune a channel map after installation.
The limitations are equally real. There is no AFH during connecting and discovering devices, because the link is not yet established and the channel map cannot be exchanged. Every device in a piconet must be AFH-capable for the mechanism to work as intended. Channel re-inclusion is genuinely challenging in dynamic environments, since a channel that looks clean for eight sweeps can degrade immediately afterward. And because the AFH sweep has the highest priority, it can delay other operations scheduled in the same window.
Coexistence with Wi-Fi is the main practical battleground. Wi-Fi traffic is bursty and wide, so a Bluetooth link may see interference that appears and disappears within milliseconds. eAFH's reported 98-99.5% link-layer reliability under dynamic Wi-Fi interference shows how much headroom informed channel selection can add, though that result comes from research rather than a shipping product. For most deployments, the practical advice is to keep AFH enabled, avoid pinning the scan interval too aggressively, and test in the actual RF environment rather than a lab.
FHSS as a family carries one inherent trade-off: lower throughput than some broadband methods, because the radio spends time hopping and cannot occupy the entire band at once. AFH does not remove that trade-off, but it makes the hopping smarter. For low-power IoT sensors and audio accessories, the reliability gain is usually worth far more than the raw throughput cost.
AFH in LE Audio, IoT, and Future Wireless Systems
Bluetooth LE Audio raises a fair question about whether AFH still applies. According to Nordic DevZone discussion, AFH is a term used in the context of BR/EDR support mode. For LE Audio broadcast, the core specification describes channel classification and Channel Selection Algorithm #2 on the LE link layer, but host channel classification was not supported in the upstream Zephyr Bluetooth host stack at that time. In other words, the mechanism exists at the link layer even where host APIs lag behind.
For IoT, AFH is close to mandatory in any dense deployment. Warehouses, hospitals, factories, and smart buildings pack hundreds or thousands of radios into a small area, and without adaptive channel selection the packet error rate climbs quickly. The minimum of twenty channels required by the specification gives designers a predictable floor, while vendor sweeps and host-side classification provide the tuning knobs.
Looking at where the technology is heading, the trend is toward more informed adaptation rather than faster hopping. Research like eAFH points to using historical measurements to decide which channels deserve re-inclusion, rather than waiting for a fixed number of clean sweeps. That is a meaningful shift: the radio stops treating every channel identically and starts reasoning about probability.
For anyone building Bluetooth or BLE products today, the practical checklist is short. Keep AFH enabled, understand your vendor's scan interval and blocking thresholds, verify behavior under real Wi-Fi load, and remember that only the central device can update the channel map. Get those basics right and the 2.4 GHz band becomes far more workable than its reputation suggests.
What is adaptive frequency hopping (AFH)?
AFH is a spread spectrum technique that improves resistance to radio frequency interference by rapidly changing the carrier frequency and avoiding crowded channels. In Bluetooth, connected devices continuously monitor their environment and update a channel map so that noisy channels are excluded and only known good channels are used. It is required for TX power above +10 dBm.
How does adaptive frequency hopping work in Bluetooth Low Energy?
At each connection event, connected devices select a channel using a channel selection algorithm and hop to it. The primary device maintains a channel map classifying channels as used or unused, shares it with the second device, and updates it as interference changes, so communication spreads across the 2.4 GHz band. Bluetooth LE uses Channel Selection Algorithm #2 for BIS PDUs.
Does Bluetooth LE Audio support adaptive frequency hopping?
According to Nordic DevZone discussion, AFH is a term used in the context of BR/EDR support mode. For LE Audio broadcast, the core specification describes channel classification and Channel Selection Algorithm #2 on the LE link layer, but host channel classification was not supported in the upstream Zephyr Bluetooth host stack at that time. Check your stack version before relying on host-side control.
What is the difference between AFH and fixed frequency hopping?
Fixed frequency hopping uses a fixed sequence of channel hops, while AFH dynamically adapts its hopping sequence to the changing environment. AFH identifies fixed sources of interference and excludes them from the available channel list, whereas non-adaptive hopping cannot avoid conflicts with other wireless technologies such as Wi-Fi. AFH also keeps at least twenty channels available.
Frequently Asked Questions
What is adaptive frequency hopping (AFH)?
AFH is a spread spectrum technique that improves resistance to radio frequency interference by rapidly changing the carrier frequency and avoiding crowded channels. In Bluetooth, connected devices continuously monitor their environment and update a channel map so that noisy channels are excluded and only known good channels are used. It is required for TX power above +10 dBm.
How does adaptive frequency hopping work in Bluetooth Low Energy?
At each connection event, connected devices select a channel using a channel selection algorithm and hop to it. The primary device maintains a channel map classifying channels as used or unused, shares it with the second device, and updates it as interference changes, so communication spreads across the 2.4 GHz band. Bluetooth LE uses Channel Selection Algorithm #2 for BIS PDUs.
Does Bluetooth LE Audio support adaptive frequency hopping?
According to Nordic DevZone discussion, AFH is a term used in the context of BR/EDR support mode. For LE Audio broadcast, the core specification describes channel classification and Channel Selection Algorithm #2 on the LE link layer, but host channel classification was not supported in the upstream Zephyr Bluetooth host stack at that time. Check your stack version before relying on host-side control.
What is the difference between AFH and fixed frequency hopping?
Fixed frequency hopping uses a fixed sequence of channel hops, while AFH dynamically adapts its hopping sequence to the changing environment. AFH identifies fixed sources of interference and excludes them from the available channel list, whereas non-adaptive hopping cannot avoid conflicts with other wireless technologies such as Wi-Fi. AFH also keeps at least twenty channels available.
What is adaptive frequency hopping (AFH) in Bluetooth?
Adaptive frequency hopping (AFH) is a spread spectrum technique that lets Bluetooth and BLE devices avoid interference by rapidly changing carrier frequency and excluding noisy channels. Devices share a channel map that marks channels as used or unused, and they hop only across the allowed set. This dynamic spectrum management improves reliability in the crowded 2.4 GHz band.
How does AFH differ between Bluetooth Classic and Bluetooth Low Energy?
Bluetooth Classic uses 79 of 83.5 channels and hops 1,600 times per second, while Bluetooth Low Energy divides the band into 40 channels, with 37 used for connected communication. Both require at least twenty channels when AFH is active, and only the central device can update the channel map. BLE uses Channel Selection Algorithm #2 for BIS PDUs.
