⏩ TL;DR: Bluetooth 6 channel sounding architecture options
Two architecture decisions actually move the needle on a Bluetooth 6 channel-sounding product. First, how you schedule ranging across multiple devices, since each connection is handled one at a time. Second, whether you go SoC or module, which barely changes design time but can save or cost weeks once international compliance enters the picture. Get the scheduling wrong and battery life and update rate fight each other. Get the sourcing decision wrong and you've either overpaid per unit or signed up for a certification slog you didn't need to.
⏩ In our multi-part series on Bluetooth 6, Part 1 covered what channel sounding measures and why it beats RSSI. This guide focuses on what it takes to actually build one
Table of Contents
What actually happens during a Bluetooth 6 channel-sounding exchange?
Every channel-sounding exchange starts with a calibration step, mode 0, which corrects for the difference between the two devices’ oscillators. From there, you configure one of three measurement modes:
- mode 1 runs Round-Trip Time only,
- mode 2 runs Phase-Based Ranging only,
- and mode 3 runs both together.
Combining the two is what gives you the cross-check that resolves the ambiguity we covered in Part 1, where a phase reading alone can’t distinguish a short path from one an extra wave-cycle longer.
Worth knowing before you commit to a chipset
Not every vendor's current silicon supports mode 3 yet. Some current parts handle RTT and PBR only as distinct separate operations whilst allowing for sub-modes. For example, PBR can be configured as the main mode with RTT as the sub-mode. What this means in practice is that the Bluetooth controller prioritises PBR over RTT and slots a RTT exchange in where it can, whereas with mode 3 you get RTT and PBR in the same exchange. This is configurable in firmware, but can also have an impact on the data you re acquiring, you trading additional PBR data for RTT data. Check directly with whichever vendor you're evaluating rather than assuming the full spec is implemented.
The phase measurement itself sweeps a wide set of frequencies across the 2.4GHz band, and the more of that spectrum you sample, the better the data you’ve got to work with, at the cost of more time and more power per measurement. That trade-off runs through everything else in this piece.
Why channel sounding can only measure one device at a time
Channel sounding runs over an open connection, one device at a time, and that’s the detail that catches teams out. A tag isn’t broadcasting a distance for anyone to pick up, it’s holding a session open with the initiator, running the exchange, and then handing off.
As an example, you could configure the channel sounding session to run for roughly half a second per device before moving to the next device in the group.
The amount of time that the channel sounding session runs for affects how many devices you can usefully track and how often, but it can also affect the accuracy of your estimation algorithm.
Add devices to a group, and the round-trip time before any one of them gets re-measured grows accordingly. If your use case needs to know where fifty tagged assets are within a few seconds of each other, that’s a very different system to one tracking three.
The upside is that this same connection-oriented model plays well with power budgets, if you design it that way.
As an example architecture, using a related Bluetooth feature; periodic advertising with responses, which lets a device sleep for the vast majority of the time and wake only for its assigned slot, transmitting its regular data (temperature, battery status, whatever the product needs) without needing a full channel-sounding exchange every time.
Then, the ranging session only needs to happen when something actually needs to know the device’s location, not on every cycle. Getting that split right, when do you ranging versus when do you just report, is one of the places we’d expect to add real value on a project like this, since it’s the kind of low-power scheduling work a reference design won’t have already solved for you.
This is the same low-power discipline we deploy in low-power wireless design projects.
SoC vs module: which one actually saves you money on a Bluetooth 6 design?
The common assumption is that choosing a pre-certified module over a chip-down design saves significant development time. In practice, that’s mostly not true – a point we’ve made before when comparing radio system trade-offs for IoT design. The firmware and signal processing work is close to identical either way, a module might save a day or two on the hardware side, rather than weeks.
Where the real difference shows up is compliance.
A module that already carries certifications across the regions you’re targeting, FCC, EU, and further afield if you’re selling into Australia or Japan, can save meaningful weeks per region on the regulatory path. If you’re only ever selling into the UK and EU, that saving is much more marginal, and you’re paying a higher per-unit cost for certifications you may not need.
There’s one case where chip-down wins regardless of volume: ATEX and other hazardous-area designs. A module locks you into whatever components sit inside it, which works against you if a component needs to change for cost, availability, or a hazardous-area approval reason down the line. For that category of product, chip-down keeps you in control of the full bill of materials, which matters more than any development-time saving a module might offer.
Practical takeaway: don’t let a module vendor’s certification story make the decision for you before you’ve worked out how many regions you’re actually certifying for, and whether ATEX or another constrained approval is in the picture at all.
Power budgeting and RF coexistence for Bluetooth 6 hardware
Every extra frequency you sample and every extra millisecond you hold a ranging session open costs power.
That’s the trade-off underneath the whole system: more data points mean better distance estimates, but they cost battery life you may not have if the product needs to run for years on a coin cell.
Channel sounding also has to share the 2.4GHz band with whatever else is running nearby, ordinary BLE data traffic, Wi-Fi, and in some industrial sites, other 2.4GHz protocols entirely.
None of that is unique to channel sounding, but it’s a more demanding scheduling problem than a simple BLE data link, since other 2.4GHz traffic could further degrade the phase measurement beyond signal reflections.
Getting from proof of concept to a shippable Bluetooth 6 product
A Bluetooth 6 channel-sounding proof of concept comes together quickly. Getting from there to a shippable product is where the topology, the scheduling, and the sourcing decision have to be thought through together, because each one pulls against the others if you treat them separately.
In Part 3 of our Bluetooth 6 series, we’ll cover how to validate a system like this properly, because a clean bench result and a working deployment are two different things.
Working through a Bluetooth 6 architecture decision?
We help product teams get past the reference design, working through topology, SoC versus module trade-offs, and the signal processing that turns raw channel-sounding data into something a product can actually rely on. If you're at that stage, talk to our engineering consultants.
Bluetooth 6 channel sounding architecture FAQs
Does Bluetooth 6 channel sounding support tracking many devices at once?
Yes, but not simultaneously. Each device is measured over its own connection, so the more devices in a group, the longer before any single one gets re-measured. System design has to account for this.
Is a module or a chip-down design cheaper for a Bluetooth 6 product?
Development time is similar either way. The real difference is compliance cost, where a certified module can save real time if you’re selling into multiple regions, and matters far less if you’re only certifying for one or two.
Why would you choose chip-down over a module for an ATEX product?
A module locks you into its internal components. For ATEX and other hazardous-area designs, keeping control of every component on the bill of materials matters more than any development-time saving a module offers.
Is periodic advertising with responses (PAwR) a Bluetooth 6 feature?
No, PAwR was introduced in Bluetooth 5.4. It’s often used alongside Bluetooth 6 channel sounding for the same kind of power-saving architecture described above, but it’s a separate feature with its own version history – not something new to Bluetooth 6.
How much extra power does channel sounding use compared to a normal Bluetooth connection?
There’s no fixed figure worth quoting here. It really depends on how wide a frequency sweep you configure, how long each ranging session runs, and how often you run it – the same trade-offs covered above. A system that ranges occasionally will barely register against a coin cell; one that ranges continuously across many devices needs real power budgeting, not the assumption that channel sounding is inherently low-power.
Liam O’Donnell is a Senior Software Engineer at ByteSnap Design. With over 18 years in embedded systems and microcontroller development, he works across firmware, industrial wireless protocols, and connected device design. He has implemented systems across oil and gas, petrochemical, and industrial automation facilities. Liam has a particular interest in the engineering decisions made early in a project that determine whether the field deployment goes smoothly or doesn’t.
