⏩ TL;DR
A clean bench demo and a working Bluetooth 6 channel-sounding deployment are two different things, and the gap between them is almost always down to environment: reflections, metal, and RF congestion that a vendor's reference algorithm wasn't built to handle. The honest way to validate a system is to test in the actual environment it'll run in, not just in open space, and to be upfront with clients about what the numbers will and won't tell them before they commit to a design.
Table of Contents
Does Bluetooth 6 channel sounding work as well outside the lab?
We’re currently putting Bluetooth 6 channel sounding through its paces on the bench, and results split cleanly in two. In an open office, distance readings hold up reasonably well. Move the same two devices onto a cluttered desk surrounded by screens, equipment, and metal, and the accuracy drops fast.
The reference algorithm is built to handle a clean signal path, not the reflections you get in a real workspace, the same first-peak detection problem we walked through in Part 1.
One prospective client saw the same thing. A technically capable team, running their own development kits in parallel, independently reached the same conclusion using the same class of hardware. The gap sits with the technology and the vendor tooling at this stage, and it shows up the same way no matter who’s testing it.
Independent academic testing backs this up too.
Researchers at the University of Antwerp (Wieme et al., IEEE Access, 2025) measured channel-sounding performance in a warehouse environment with metal racking, using millimetre-accurate, motion-capture ground truth against commercial hardware. The test found the technology well-suited to close-range use cases. But it noted that outliers from multipath and reflections can significantly affect accuracy and need to be actively managed, not assumed away. That matches what we’re seeing on the bench.
What to test: power consumption against update frequency
The single biggest trade-off to test for is power consumption against update frequency, the same scheduling tension we cover in Part 2. A system that ranges continuously to keep tight track of a moving asset will drain a battery far faster than one that only needs to confirm a device’s location once an hour.
Getting this right depends entirely on the use case, and it’s the first question worth asking before any other testing begins: how often does this product actually need to know where something is? We cover this low-power discipline in low-power wireless design.
Beyond that, testing needs to happen in the environment the product will actually live in, rather than at a clear desk or in an open room. Reflective surfaces, metal equipment, and a congested 2.4GHz environment all degrade performance in ways a clean bench test won’t reveal.
How to talk to clients about accuracy without overselling it
There’s a real tension in how to talk about this with clients – enough detail to be useful, without implying the reference design is production-ready when it isn’t. The most credible approach is being straightforward that a working proof of concept is very achievable quickly, and that turning it into a reliable production device is a separate piece of work, one that depends on the specific environment and use case.
What does a testing failure actually cost?
How much a test failure costs depends on how severe the fault is and how much margin was built into the original design. The fix ranges from a minor PCB revision right up to starting the design again, though that extreme end is rare.
The most common Bluetooth-specific EMC failure is spurious harmonics being re-radiated from the board, often traced back to poor ground plane design, exactly the kind of issue pre-compliance EMC testing is designed to catch before it reaches a formal test.
The other common failure mode isn’t an EMC problem at all; it’s a radio that simply underperforms, showing up as shorter range than the product needs. Where a fault does require a PCB respin, budget around two months to redesign, build new prototypes, and retest.
What a testing failure typically costs
| Failure type | Typical cause | Typical fix | Time impact |
|---|---|---|---|
| Minor design issue | Small margin problem within an otherwise sound design | PCB revision only, no full respin | Fastest |
| Spurious emissions (EMC) | Poor ground plane design | Layout rework, respin, new prototypes, retest | ~2 months |
| Poor RF performance | Radio underperforming, shows up as short range | RF/antenna rework, respin, new prototypes, retest | ~2 months |
| Fundamental design flaw | Insufficient margin across the design, rare | Start the design again | Significant |
Based on ByteSnap Design's own experience of what test failures typically require to fix, not a formal quote. Real timelines vary by project.
What sign-off actually requires, and how long the whole process takes
Before a design gets signed off for production, test results need to show the radio working reliably in both receive and transmit, without producing spurious out-of-band emissions, the same RF parameters covered in the Bluetooth SIG’s own qualification process. That’s the bar, not a specific accuracy figure, but proof the radio itself is clean and dependable.
On timeframe: how long to budget from a working demo to a deployable product depends heavily on what else is in the product. If Bluetooth is the only feature, a tag with no other functionality, three to four months from working demo to production-ready is realistic.
Most products aren’t that simple; Bluetooth is usually one part of a larger design, and a meaningful chunk of that time isn’t engineering at all – it’s waiting on construction, prototype builds, and setting up factory test.
If your own proof of concept is stuck at this point, that’s the kind of problem our Design Rescue Service can help with.
Deciding whether your Bluetooth 6 concept is ready for production?
We test channel-sounding systems in the conditions they'll actually run in, not just in open space, so you know what you're really getting before committing to volume.
Bluetooth 6 channel sounding real world deployment FAQs
Why does Bluetooth 6 channel sounding perform worse in real environments than on a clean bench?
Reflections off metal, screens, and equipment confuse reference algorithms that are built to demonstrate the technology under good conditions, not handle real-world clutter. Many of these algorithms only look for the first, strongest signal peak, which breaks down exactly where reflections are worst. Testing only in open space will overstate how a product performs once it’s actually deployed.
Is this a problem specific to one chipset vendor?
No. It reflects where reference algorithms across the industry currently stand right now, not a flaw unique to any one supplier. We’ve seen the same pattern on our own bench, and a prospective client running their own tests independently reached the same conclusion, a useful sign this isn’t specific to any one team’s setup.
Has independent testing found the same accuracy challenges ByteSnap Design has seen on the bench?
Yes. Researchers at the University of Antwerp (Wieme et al., IEEE Access, 2025) reached a similar conclusion testing in a warehouse environment with metal racking: channel sounding performs well for close-range use cases, but outliers from multipath and reflections need to be actively managed in real deployments, not assumed away.
What's the most important thing to test for in a Bluetooth 6 channel-sounding product?
Power consumption against update frequency is the biggest trade-off to get right. A system ranging continuously to track a moving asset drains a battery far faster than one confirming a location once an hour. Test it in the actual deployment environment, not a clear bench or open room, since reflective surfaces and RF congestion both affect real-world performance.
How long does it take to get from a working demo to a production-ready Bluetooth 6 device?
For a simple product, a Bluetooth tag with no other functionality, three to four months is realistic. Most real products have more going on than that, and a meaningful part of the timeline is waiting on prototype builds and factory test setup, rather than engineering itself.
Dunstan is a chartered electronics engineer who has been providing embedded systems design, production and consultancy to businesses around the world for over 30 years.
Dunstan graduated from Cambridge University with a degree in electronics engineering in 1992. After working in the industry for several years, he co-founded multi-award-winning electronics engineering consultancy ByteSnap Design in 2008. He then went on to launch international EV charging design consultancy Versinetic during the 2020 global lockdown.
An experienced conference speaker domestically and internationally, Dunstan covers several areas of electronics product development, including IoT, integrated software design and complex project management.
In his spare time, Dunstan enjoys hiking and astronomy.
Expand your knowledge
- Bluetooth Core Specification 6.0 Technical Overview (Bluetooth SIG)
- Bluetooth Channel Sounding Feature Overview (Bluetooth SIG)
- Performance Evaluation of Bluetooth Channel Sounding on Commercial Hardware (independent academic study)
- Bluetooth Qualification Process Quick Start Guide (Bluetooth SIG)
- ByteSnap Design: From RSSI to Channel Sounding
- ByteSnap Design: Designing a Bluetooth 6 Channel-Sounding System
