• Loading…

Post 3: I’ll Take Those Odds (Frequency Hopping and Retransmission)​

The last article left us with a 60-byte packet that spends about a third of a millisecond on the air in each 10 ms broadcast interval. For the remaining 97% of that time, the radio could be idle, saving battery life. But we also need to balance energy savings with reliability and range, even amid RF interference. 

 

In contrast to two-way wireless standards like Wi-Fi, an Auracast™ receiver cannot ask for a packet it missed. Auracast therefore fills part of the idle time with repeated copies of the packet. The listening device only needs to catch one copy of a packet for the entire audio frame to be successfully received. The transmitter decides in advance how many chances each frame of audio gets, and where within the 2.4 GHz band each packet copy will be sent. 

 

Spare Copies 

The number of times the transmitter sends the packet within each broadcast interval is called the immediate repetition count (IRC). Our worked example uses five; the actual count is a choice made in the transmitter’s programming. Each copy takes about 0.3 ms on the air, and at the tightest spacing the standard allows (and likely the most commonly used), all five finish within about the first 2 ms of the interval, using about 1.5 ms of total airtime. The radio is still idle more than 80% of the time. 

 

Every copy belongs to the current interval, so in our example, repetition itself adds at most about 2 ms of latency in the signal chain. The receiver keeps the first copy that arrives intact and may skip listening for the rest, further saving battery life. 

Each 10 ms frame can go out multiple times; here, five copies of about 0.3 ms each. At the minimum spacing the standard allows, all five finish in about the first 2 ms, and the rest of the interval stays idle.

Channel Hopping 

Bluetooth® LE divides the 2.4 GHz band into 40 channels, each 2 MHz wide. Thirty-seven of the channels are used for data. Each copy of an audio packet hops to a new data channel in a pseudo-random sequence. The remaining three channels, one each near the bottom, middle, and top of the band, are advertising channels. A broadcast transmitter repeats a short announcement on all three in turn, typically every 30 to 200 ms, a repetition approach similar to that used for the audio packets. 

 

Each announcement points to a longer packet on one of the 37 data channels that carries the broadcast’s name. A third packet, repeated on its own schedule, carries the audio settings and timing a receiver needs to find the audio. Following this scheme, a receiver is able to lock on to the audio data broadcast without any two-way handshake. The secondary announcement packets hop through the data channels much like the audio does, so with many broadcasts in one space they may occasionally collide with another broadcast’s audio, and our simulated statistics in this article do take this into account. The audio itself uses only the data channels, and all the announcements together take roughly 1 to 3% of the airtime. 

 

The specification also requires consecutive audio packet copies to land well apart in frequency. With all 37 data channels in use, each copy lands at least 11 channels, 22 MHz or more, from the one before. A standard 20 MHz Wi-Fi channel covers 10 or 11 Bluetooth LE channels. So, two back-to-back copies can never both land inside one 20 MHz Wi-Fi channel. In the most common scenarios where only one Wi-Fi channel is especially strong in a location, this is a clever and free way to protect frame survival. 

 

As the first article showed, Wi-Fi isn’t the only occupant of the band, but we can generally assume it is the widest, most common, and busiest, so it serves as our example. However, in many venues Wi-Fi’s 2.4 GHz footprint is also shrinking. For example, large-venue design guides from Cisco and HPE Aruba advise against general client access on 2.4 GHz, reserving it for IoT devices such as building sensors and controls (which usually communicate at low duty cycles), plus legacy equipment. Many network designs now disable 2.4 GHz entirely on some access points. The direction of travel is toward less Wi-Fi traffic in the 2.4 GHz band, but we’ll use demanding circumstances for our analysis here to keep the numbers conservative. 

 

Wi-Fi transmits in bursts, and data packets are considered lost only when they land inside a Wi-Fi channel at the moment that channel is transmitting. In our model, against only a single active 20 MHz-wide Wi-Fi channel, two packet copies separated by at least 22 MHz are enough to ensure 100% survival because one of any two consecutive Auracast packet copies always lands outside the active Wi-Fi band. 

Wi-Fi channels 1, 6, and 11 each active about 30% of the time, with five copies of every audio frame hopping across the 37 data channels. Copies that touch a Wi-Fi transmission turn red; a frame is lost only if all five do. The three advertising channels are shaded yellow, and all announcement packets are yellow. Wi-Fi traffic is simulated; hop spacing and timing follow the Bluetooth specification. 

Strength in Numbers 

The numbers in this section come from a simulation of the specification’s timing and hopping rules, designed as a deliberately difficult scenario. Wi-Fi channels 1, 6, and 11 are all active, burst independently, are strong at the listener’s seat, and each is busy 30% of the time. Together the Wi-Fi channels cover 31 of the 37 Bluetooth LE data channels. No other interference sources, such as Bluetooth Classic, Zigbee, or microwave ovens, are modeled here. Real signals often survive an interfering overlap and still decode thanks to advantages we’ll discuss in the next article. To be conservative, in this article Auracast gets no credit for that strength; any Auracast/Wi-Fi overlap, even just a microsecond, counts as a lost packet. Depending on how many times each packet is repeated within each broadcast interval, the share of audio frames lost in simulation is: 

One percent is one 10 ms gap per second, on average; the simulator in the previous article lets you hear what that does to speech. For a published benchmark, Perceptual Evaluation of Speech Quality (PESQ) is an ITU-standard algorithm that objectively predicts how listeners would rate a speech recording on a scale usually topping out near 4.5. In a 2024 study simulating LC3’s basic packet loss concealment method, all speech samples score at least 2.0 (“poor,” but still intelligible) up to about 2% frame loss, with half of the speech samples achieving that score even at 6 or 7% frame loss. Since 2% marks the worst sample, and assistive listening should be designed for the listeners who struggle the most, we treat it as a conservative benchmark. 

 

Heavier traffic, traffic that swings between light and heavy, and very short Wi-Fi transmissions all push the loss percentages up. At 50% load on all three Wi-Fi channels, five packet repetitions lose 5 to 9% of frames. Swings hurt more than their average suggests because losses climb steeply with load: a stretch at 50% costs far more than a stretch at 10% saves. So while moderate loads are well handled by packet repetition, in unusually demanding circumstances where interference is strong across the entire band at the listeners’ seats (not just near the access points themselves), repetition alone may not ensure reliability.

Bar chart of frames lost against copies of each frame, with Wi-Fi channels 1, 6, and 11 each busy 30% of the time. One copy: 29 to 38%. Two: 8 to 15%. Three: 4 to 6%. Four: 1.9 to 2.5%. Five: 0.9 to 1.0%. A dashed line marks about 2%, a conservative limit from published LC3 tests; only five copies sit below it.
Frame loss as copies are added, with Wi-Fi channels 1, 6, and 11 each busy 30% of the time and any overlap counted as a loss; each bar spans short to long Wi-Fi bursts. The line marks about 2% frame loss, a conservative limit from published LC3 tests. Simulated, at the tightest copy spacing the standard allows.

Head Start 

As another lever for reliability, the Bluetooth specification includes an option for additional redundancy. Pre-transmission, set by the pre-transmission offset (PTO), pushes the main IRC sequence back by one or more intervals and sends one or more copies of that frame’s packet in the preceding interval(s). In other words, it transmits another packet copy, but in an entirely different, earlier interval, either in addition to or in place of one or more of the IRC copies. 

 

Copies 10 ms apart rarely fall under the same Wi-Fi burst, though sustained heavy traffic can still interfere with both. In simulation, when Wi-Fi bursts run long, moving the fifth packet copy into the previous interval loses about 40% fewer frames than keeping it in the current interval. Against short Wi-Fi bursts, PTO may have less benefit. 

 

The cost is latency. Playout must wait for the last scheduled packet copy, which adds at least one 10 ms interval, or more when copies are sent two or more intervals ahead. Spreading five copies across five intervals, for example, adds 40 ms. Our worked example prioritizes low latency, so pre-transmission stays unused. 

Two stacked charts of the same 20 ms of simulated Wi-Fi traffic, showing one audio frame's copies hopping across the band, with other frames' copies in gray; one broadcast announcement appears in yellow: three short packets on the advertising channels, a details packet on a data channel just after, and a separate stream-info packet on another data channel. Top: all five copies in the frame's own interval; one long Wi-Fi burst on channel 6 and another on channel 1 each catch two copies, so 4 of 5 are lost and the frame survives on the fifth. Bottom: four copies in the frame's own interval and one sent 10 ms ahead in the previous interval with pre-transmission, which lands clear; 3 of 5 are lost, at the cost of 10 ms of added latency.
The same Wi-Fi traffic against two schedules for one frame, with its copies hopping across the band, other frames’ copies in gray, and announcement packets in yellow. Top: all five copies in the frame’s own interval; two long Wi-Fi bursts each catch two copies, and the frame survives on the fifth. Bottom: the fifth copy is sent 10 ms ahead with pre-transmission and lands clear, at the cost of 10 ms of added latency. Simulated.

Crowd Control 

While Bluetooth LE has 37 data channels available for audio, it is not required that they’re all used. The transmitter publishes a channel map and every receiver follows it. A transmitter could be manually configured to use a subset of channels or scan for interference at its location and make decisions automatically. For example, in Auri™ Manager, the Channel Restrictions feature can be used to deactivate one set of up to 18 contiguous channels. That is enough to clear any one Wi-Fi channel. 

Bluetooth LE channel numbers and corresponding ranges covered by each Wi-Fi channel’s nominal 20 MHz.

Restriction has a cost. Fewer channels leave less room to spread copies, and the required spacing between consecutive copies shrinks as channels are removed: 8 positions instead of 11 when 27 channels remain. That is less than the width of the Wi-Fi channels left in the band, so two back-to-back copies can now land inside one of them. 

 

The most common case needs no restriction at all: if one Wi-Fi channel is busy and the others are silent, the spacing rule already keeps it from taking a frame, even at 100% load. Restriction pays off when one channel is clearly busier than others. With channel 6 busy 50% of the time and channels 1 and 11 at a light 10%, restricting channel 6 roughly halves losses, from about 0.23% to 0.12%. With all three at 30%, restriction could help or hurt a little depending on the traffic. Adding additional “guard” channel restrictions around Wi-Fi bands hurts performance. 

 

Using Channel Restrictions is effective for a Wi-Fi channel that carries a lot more traffic than its neighbors and stays consistently assigned. However, the default on many access points is that the channel changes on its own, so a restriction could go stale. If Auracast reliability and range due to heavy 2.4 GHz Wi-Fi interference are a big enough concern to consider manually steering the channel map, it is best to manually configure Wi-Fi access points to static channel selections first, carefully coordinated with Auracast transmitter and seating locations. For interference that comes and goes across Wi-Fi channels, it is better to let packet repetition alone do the work.

The same traffic twice, with Wi-Fi channel 6 busy 50% of the time and channels 1 and 11 light at 10%. Top: copies hop across all 37 data channels, and some land under channel 6. Bottom: Bluetooth LE channels 11 to 20 are restricted, no copy lands there, and none are lost in this window. Announcement packets are yellow. Traffic is simulated.

Full House 

The last article noted that quality and resilience draw from the same airtime budget. As the air becomes busier, the odds of Auracast packets interfering with each other become a factor. In our series’ example, one mono stream at five copies uses about 15% of each interval; two use about 30%. Going to stereo simply doubles the packets. Each added broadcast stream brings its own packet copies. High Quality audio at 48 kHz sample rate makes every packet about 60% longer than at 24 kHz Standard Quality. Conversely, dropping to 16 kHz sample rate reduces airtime by nearly 30% vs. 24 kHz, a choice that may make sense for the most heavily congested venues or when broadcast counts grow large. 

 

Independent broadcasts’ transmission intervals and channel-hops are not coordinated, so occasionally two packets may interfere at the same time and frequency. Every source of collisions adds to the chance of losing any one copy, and because a frame is lost only when all its copies are, those chances compound. Additional broadcasts alone barely affect the odds, but added to other interference sources, the effect grows. In the simulated conditions in the figure below, frame loss rises from about 0.2% with one broadcast up to 0.9% with 24. In the busy, three-channel stress case, loss rises from about 0.9% to 2.3%. Venues deploying many simultaneous broadcasts in the same room may warrant careful consideration.

One Auracast broadcast, then 2, 4, 8, 12, 16, 20, and 24 mono broadcasts in the same space, with Wi-Fi channel 6 busy 50% of the time and channels 1 and 11 at 10%. Copies lost to another broadcast are dark gray, and announcement packets appear in yellow on the advertising and data channels. The chart tracks long-run frame loss: the share lost to Wi-Fi holds near 0.2%, and other broadcasts add the rest, reaching about 0.9% at 24. Simulated. 

Takeaway 

Each frame gets several chances to survive with packets spread across the frequency band, and only one packet has to arrive for the frame to be successful. With all 37 data channels in use, the hop spacing rule keeps consecutive copies out of any single 20 MHz Wi-Fi channel. Even with three Wi-Fi channels at moderate, steady load at a listener’s seat, utilizing five packet copies holds frame losses within what the codec’s packet loss concealment algorithm comfortably covers. In this article we have assumed difficult conditions and absolute interference from even the smallest overlapping signal. However, Auracast has yet more advantages that help packets arrive strong and clean enough to decode. That is the subject of the next article. 

 

 

The Bluetooth® word mark and logos are registered trademarks owned by Bluetooth SIG, Inc. The Auracast™ word mark and logos are trademarks owned by Bluetooth SIG, Inc. Any use of such marks by Listen Technologies Corporation is under license. Other trademarks and trade names are those of their respective owners.