Since we work deeply with Bluetooth technology at all levels, it’s not unusual for us to try out some devices. Recently I was looking to see whether we could find a real Bluetooth 6.2 or 6.3 dongle to add to some of our systems.
I won’t say that I went searching widely. Rather, went to Amazon and started looking. Most of the dongles there are Bluetooth 5. Most don’t even have a claimed specification. A few are 5.3 and 5.4 (or so they claim).
But I couldn’t find any Bluetooth 6.2 or 6.3 dongles. Not really surprising – the specs are still new and the features are very specific to where most users won’t need them. It only makes sense to people like us testing the latest Bluetooth features. I wouldn’t expect much here.
But, after a bit of searching I found a Bluetooth 6.0 dongle from Asus. Now that’s a reputable company. That means the dongle is more likely to be spec compliant and actually registered with the Bluetooth SIG instead of some low cost dongles I’ve seen before. You won’t find any 6.2 or 6.3 dongles from what I saw, so this is the best we can do.
It’s hard to complain about $21 to be honest. What’s more important is this dongle supports both Bluetooth Classic and BLE which tends to be convenient for all kinds of dual mode applications, though they often sacrifice LE features. But as Bluetooth Classic is slowly going away, that’s going to be less and less of an issue.
But the question is, does this Dongle supports Bluetooth 6.0? I discovered the answer was, Yes, and No.
The USB adapter reports HCI version 0x0E, which officially corresponds to Bluetooth Core 6.0. However, it doesn’t actually support the major Bluetooth 6.0 controller features. And most importantly: it does not support Channel Sounding. Or pretty much any Bluetooth 6.0 feature.
I’m not surprised. Channel Sounding is a very specific feature and the need to locate devices with a dongle is not really a consumer use case because you need a lot of software to support it – how will you tell the user what the devices are and where they are?
Here’s some of data I got from talking to the dongle:
- LE feature bitmap:
FD 77 FE F7 8E 00 00 00- Channel Sounding bit 46: No
- Channel Sounding Host Support bit 47: No
- LL Extended Feature Set bit 63: No
- Decision-Based Advertising Filtering bit 42: No
LE CS Read Local Supported Capabilities(0x2089) returned status0x01: Unknown HCI Command.LE Read All Local Supported Features(0x2087) returned Unknown HCI Command.LE Read Monitored Advertisers List Size(0x209B) returned Unknown HCI Command.- The supported-command bitmap also has the Bluetooth 6.0 command ranges cleared.
Ok so a bit disappointing, but not surprising. What about the rest?
Well, the dongle isn’t without its features. It has a lot of earlier Bluetooth features like
- CIS central and peripheral
- ISO broadcaster and synchronized receiver
- LE 2M and Coded PHY
- Extended and periodic advertising
- LE power control and path-loss monitoring
- Direction-finding/CTE-related
- Channel classification
So even though the Bluetooth dongle says it’s a Bluetooth 6.0 dongle, the features it actually supports are more Bluetooth 5.2 and Bluetooth 5.3. There’s no Channel Sounding, DBAF, Monitoring Advertisers, LL Extended Feature Set, ISOAL enhancements, or Frame Space Update which are the core Bluetooth 6 features. We covered some of these in Bluetooth 6.0 Adopted and other articles about the specs that you can read about what they are.
In fact what’s more interesting is that the Firmware file for it is RTK_BT_5.0. The chipset is almost certainly a Realtek chipset, and the the firmware heavily implies it’s based on 5.0 features. Yeah.. we know…
This isn’t wrong per se (although very annoying). A product can claim compliance with Bluetooth 6.0 Specification but leave out all the optional features. It can be misleading because you’d assume (as I did) that a Bluetooth 6.0 device actually supports at least one of the core features.
But building a complex spec like Bluetooth (the latest page count for the spec is around 4000 pages) and the need to make it backwards compatible means that some features have to be optional to avoid forcing companies to implement features they don’t think they need, that take more silicon die space (and add cost) or that require significant development. Bluetooth has some features that haven’t worked all that well (ever heard of AMP? yeah….)
This isn’t new – plenty of chipsets claimed Bluetooth 5.0 compatibility but didn’t actually have the 2Mbps PHY, a core feature. For the most part companies do end up adding the features because customers demand them, but it can be confusing when you’re trying to figure it out.
Part of the challenge here for companies is that you have to move up in the specs – the Bluetooth SIG deprecates and withdraws them every 10 years or so, which means you can’t use an old spec even though your device technically supports just those features. That’s the case for a lot of chipsets that were essentially Bluetooth 4.2 in features but were certified under Bluetooth 5.0 and Bluetooth 5.1 (CC2564 is a good example) because Bluetooth 4.2 can’t be used anymore.
What’s important here for developers and users is that you look at the actual features supported by the chipset and the product. Even looking it up in the Bluetooth SIG database if possible, or testing it before assuming.
There’s also a difference between what the hardware supports, what the stack supports, and what actually works. We’ve seen some stacks that were terrible at this. Although they technically supported the feature, it was unreliable enough that the claim was pretty farfetched. It took the vendor months to get it to the point where it was usable, and it had a big impact on the project.
So remember to actually check the features, not just the marketing version.
Until next time.
Cheers,
Gustavo
