Bluetooth Channel Sounding: From Performance to Real-World Applications

Hello everyone, and welcome to today's Tech Talk. 
I am Chandana Deviani, a product marketing manager here at Silicon Labs, and I will be your host for today. 
Before we get started, I would just like to bring your attention to the Q&A chat box. 
Please feel free to ask any questions there, and we will try and answer some as the session goes on, and then some at the end. 
I would also like to take a moment to invite you to our upcoming Bluetooth Tech Talk, where we will be joined by the Bluetooth SIG for a deeper technical discussion on the latest Bluetooth innovations and how these capabilities fit into the broader Bluetooth roadmap. 
So, without any further delay, and with that, it is my pleasure to introduce today's amazing speaker, Tiago Mont, who is a product manager here for Bluetooth at Silicon Labs and brings extensive expertise in Bluetooth and wireless technologies. 
So thank you, Tiago, for joining us today, and the floor is all yours. 
Thank you, Chandana. 
Not sure about the amazing part, but thanks for the amazing intro, at least. 
Yeah. 
So hello, everyone. 
Welcome to today's Tech Talk. 
So my name is Tiago. 
I'm a product manager for Bluetooth here at Silicon Labs. 
And I'm really excited because channel sounding is a really promising technology, part of the Bluetooth standard. 
So today we're going to talk about channel sounding. 
More broadly, we'll talk about performance, real-world applications, and also the solutions that Silicon Labs has for channel sounding. 
So just a quick run-through of the agenda. 
Just get my pointer here ready. 
So we'll start with a technology overview, look at channel sounding from a higher level and how it compares with other technologies used for ranging. 
Then we'll talk about the Silicon Labs algorithm, so what we offer to be able to do the ranging on the Silicon Labs wireless SoCs. 
Within that topic of algorithm variants, we'll talk about the different performance that we offer and the comparison and the trade-offs that can be made in the selection of those variants. 
Then we have some really cool application demos. 
So we'll go through some of the use cases, and we'll show some demos related to those use cases. 
We'll also touch a topic that I'm sure is in everyone's mind, related to channel sounding and support on mobile, because when we think about Bluetooth, naturally you'll think about mobile handsets. 
So channel sounding kind of falls into that. 
So we'll touch that topic as well, and then we'll wrap up with the Silicon Labs channel sounding offering, and we'll have then the Q&A after that. 
So feel free to put your questions, as Chandana mentioned. 
Okay. 
So what's been the challenge here? 
So IoT is growing every day, every year, more applications, more use cases, and there's clearly a need to have more spatial awareness. 
So it depends, of course, on the use case, what that is used for. 
But not just that you need that spatial awareness, but also you want that to be more secure, more reliable, and you want that to be more responsive as well. 
So up until now, the Bluetooth LE spec hasn't really had native support for any sort of ranging mechanism. 
So in the early days, it was RSSI that was used for getting a sense of ranging, but this was not the most accurate approach. 
It was unreliable, and in real-world use cases, it kind of fell short. 
In many applications, it didn't give the range that was necessary. 
But then you get Direction Finding introduced in the Bluetooth 5.0 spec, which gave ranging and direction, but it also brought that as a bit more complexity. 
You need multiple antennas, and that brought a bit too much complexity for simpler use cases. 
And then you have also UWB, which is a bit more accurate, but it also has some trade-offs, more on the cost side, as you need a dedicated chip. 
So there's an opportunity here for Bluetooth to come with something that is dedicated to ranging. 
That's where channel sounding comes in, right? 
So it was introduced in Bluetooth 6.0 core specification, and if I had to summarize it in a few words, it's really introducing accurate, interoperable, which is very important, and secure ranging. 
And this enables sub-meter accuracy, and it brings much more robust performance, especially compared to RSSI-based ranging, even in non-line of sight. 
That's what this acronym stands for. 
It also offers flexibility, so you can use either one or two antennas. 
So it can adapt depending, are you more on the cost optimization side, or do you want higher accuracy with two antennas? 
And it, in terms of cost, is more efficient than UWB because in terms of BOM, it's much simpler and essentially a Bluetooth 6.0 design, when you have an SoC that supports channel sounding, you can add channel sounding to that design as a feature, even just having the one antenna there. 
So it broadens the possibilities a lot compared to what was possible in the past. 
Okay. 
So overview, what are the actual mechanisms? 
And we'll look into these in more detail in the next slide. 
So there's basically two distance mechanisms that are used for the ranging. 
One is called phase-based ranging, so PBR. 
That's an acronym that you'll hear a few more times during this presentation. 
And the other one is round-trip time, or RTT. 
So one of the key things is that channel sounding basically uses the same physical layer as Bluetooth LE, right? 
So it runs alongside or interleaved with a connection so that there is no new PHY or anything that hasn't been there before, let's say. 
So it means that you can keep a regular Bluetooth LE connection data exchange as you also do ranging through channel sounding. 
So it's connection-oriented. 
So again Building on what I said earlier, and it's two-way ranging, so it means that the ranging needs to go from one device to the other and back. 
So there's actually two roles. 
The initiator, that's the device that wants to calculate the distance, so that's the one that initiates this channel sounding ranging procedure. 
And the other device, the one that sends the signal back, is called the reflector. 
And it's just the device that responds to the initiator. 
So the initiator is the one that then runs the calculation or the algorithm for estimating the ranging. 
It supports up to four antenna paths, so this means two antennas on each side would be two times two, so that's four antenna paths. 
But you can also have a combination of one antenna and two antennas, or just one antenna on either side. 
So all these combinations are supported. 
It brings more security into this ranging compared to RSSI and even direction finding. 
So one of those things that because it's connection-oriented, it actually requires you to go through the bonding procedures for a regular connection. 
So it has that as a baseline, and it still builds a little bit on top of that. 
And if you're looking at ranging and you also want to have the direction, it's possible to combine it with AoA or AoD. 
Some additional resources here that you can explore later that we've had over the past couple of years on channel sounding. 
So diving a little bit deeper into these channel sounding step modes. 
So there's four modes, three of them are mandatory. 
So mode zero is calibration. 
So here there's actually no ranging procedure being done. 
This is just where the two devices basically exchange information that is needed to eventually compensate, for example, clock drift, or actually frequency offset. 
So as you know, there are going to be oscillators on both sides. 
They have a certain accuracy, so parts per million, they might not be the same. 
So these two devices, they need to know what their configuration is to be able to compensate and offer the highest accuracy. 
So it's just a calibration phase. 
No actual ranging is done, and this is basically done only one time when the devices connect. 
Then you have the round-trip time. 
So I think this is pretty self-explanatory. 
So you have the signal going from the initiator to the reflector, and you know the speed at which RF radio waves propagate, so you can measure the time of flight, and then the reflector has a kind of a known turnaround time, sends a signal back, and the initiator, based on this information, can use that to calculate or to estimate the distance. 
And mode number two, phase-based ranging. 
So this is based on the phase of the signal, but it's kind of the same principle. 
So the initiator is the one that sends the signal first, and the reflector turns that signal around, and then the initiator can see based on the phase difference between the departing signal and the received signal. 
They can use that to estimate the distance. 
And also here, the antenna paths can be exercised. 
So the more antenna paths means that you're going to have higher accuracy. 
And then there's a third mode, which is an optional mode that combines both PBR and RTT in each step. 
They can also be done individually, which takes a little bit longer, but with mode three support, this can be done in a more, let's say, time-effective way. 
And so the motivation to do PBR and RTT there, it's twofold. 
On the one hand, doing both means that you have two distance estimations to cross-check it, one against each other. 
So you can check if they're too far apart, probably there's something there that isn't quite right. 
And the other one is that it offers higher security, because if you see this mismatch in the distance estimation, it means that one of these methods might be being subject to a relay attack. 
So you can use that to sort of get an additional layer of security into your application. 
So in terms of markets and use cases, so we see basically three key markets or segments, let's say. 
So the first one is proximity awareness. 
So this is, I guess, where RSSI has traditionally been sort of the way of getting this awareness of how close are you to a certain application. 
So that could be a door lock. 
In terms of use case, could be for keyless entry, so your phone being the key that allows you into a certain part of a building or a house. 
So of course, the application there being building access systems and also geo-fencing, where you set certain limits and you get alerts if someone moves beyond those limits based on the proximity estimation. 
The other one is localization. 
So just being able to know where assets are within a building. 
If you're thinking about a hospital, where certain equipment is. 
If you need an equipment, normally you might need it in an urgent situation, so it's much faster if you know exactly where it is instead of having to waste precious time looking for it, or in warehouses for logistics management, for example. 
And then for tracking inside the home, pets, and the regular item finding where you attach trackers to things like your wallet, your keys, your backpack, and then you can have a better sense of localization using channel sounding. 
And the other one is auto mapping. 
So this is where you can use channel sounding, and we'll look into this in the demo as well. 
You can use channel sounding so that devices can range relative to each other. 
And with that, you can build sort of a 2D map, which can really fast-track things like commissioning of solar panels, commissioning of large lighting systems that traditionally are done by hand, so they're labor-intensive. 
Obviously, that represents cost for the installer. 
And you can have this done in an automated way, kind of creating a digital twin of whatever installation you're commissioning. 
And if we want to sort of look at these different mechanisms, so Bluetooth RSSI, direction finding, channel sounding, as well as UWW. 
So there's a lot of specs here. 
I'm not going to go through all of them in detail. 
But I think Normally, the key things that customers are concerned about or they want to know more about is on the accuracy. 
So as we know, Bluetooth RSSI and Direction Finding don't offer the highest accuracy. 
And then between Channel Sounding and UWV, it's not as close. 
But of course, this is essentially more of a trade-off between accuracy and cost. 
So with Channel Sounding, with PBR mechanism, you can get under a half a meter accuracy with RTT between one and five meters. 
Right? 
And also depends a bit how far apart the devices are from each other. 
In terms of measurement latency, this also can be important for certain applications, especially for tracking moving objects. 
So with Channel Sounding, you get about 10 hertz measurement rate, so about 100 milliseconds for each measurement using PBR. 
It brings improvements, of course, when it comes to being more immune to RF noise. 
It's still sensitive to multipath and certain interferences, but it's much more robust if you compare with both Direction Finding as well as the RSSI mechanisms. 
UWV has even stronger immunity to these kind of issues. 
Brings more security than the previous mechanisms. 
One of the things to know today is that Channel Sounding, because it is connection-oriented, it kind of limits the scalability, right? 
Because you need to actually connect first before you do the ranging. 
So if you want to track multiple things at the same time, you're going to have a limit because basically your on-air time will be divided by the number of connections that you have in parallel. 
So in that sense, it doesn't scale as well as some of the other mechanisms. 
But it's a very cost-effective solution. 
So when comparing maybe in a bit simplistic way between Channel Sounding and UWV, it's really between the accuracy and the cost. 
So depending on the application, sometimes the UWV accuracy might be even too accurate in the sense that it's something that the application probably doesn't need, but it comes at a cost. 
So those are really the two main things to consider between Channel Sounding and UWV. 
Basically just at a technical spec level, but then, of course, you need to think about mobile phone support, for example, which is something we'll talk about in one of the next slides, because Channel Sounding will slowly be coming as a standard feature in mobile phones. 
So that will make it basically ubiquitous as a ranging technology. 
So moving to the algorithms that we have at Silicon Labs for the ranging, what we call in the RTLs Real-Time Library. 
So there's three configurations or three variants. 
Two of them are for tracking moving objects. 
One is optimized for latency, so it will track objects moving a little bit faster. 
The other one is optimized for accuracy, so it's more for devices or objects that don't move as fast, but it will offer you higher accuracy. 
And then we have another variant that it's optimized for stationary. 
So mostly to cater to the auto mapping use case, where we have devices that will not move relative to each other. 
So light bulbs will be one example of that. 
And how they compare in a little bit more detail. 
So I just wanted to, before going through the parameters, give you sort of the baseline where we got the data from. 
So this is using one connection, so one reflector and one initiator, four antenna pads, so two antennas on each side. 
It's using our Channel Sounding dev kit that you'll see in some of the next slides. 
And it's using all the 72 channels that are available for Channel Sounding. 
So yeah, using the DK2606A, which is our Channel Sounding development kit, and it's using the SDK that's coming out in a couple of weeks now in June. 
So the name of these algorithms actually change compared to what is there today. 
So in a few weeks, you'll be able to get this SDK when it becomes available. 
And these are the new names that we're using to describe these algorithms. 
So as mentioned, you have two algorithms or two variants dedicated or more towards this tracking and then one towards the stationary use case. 
And as seen here from the accuracy optimized, obviously the expectation is that you're going to have a little bit better accuracy. 
This is on a line of sight, so unblocked view between the two devices. 
It also offers a little bit more range, but the measurement rate is a little bit slower. 
That's why the other variant is latency optimized in the sense that it has a higher measurement rate at the cost of a little bit lower accuracy. 
So one thing to keep in mind is that the ranging algorithms at Silicon Labs are constantly evolving. 
So this is something that we are working on all the time to improve together with our customers, and all the different use cases that we put these algorithms through testing. 
So some of the known issues that we have on the tracking is body blocking. 
And specifically for tracking, this tends to be the back pocket situation where you put your device on a back pocket, so it's close to the body, so it's kind of not the best RF environment. 
And right now, the performance is not the best, but again, this is something that we're working on improving. 
And then on the stationary also offers accuracy, which is very close to the accuracy optimized algorithm. 
Similar resource needs in terms of flash and RAM. 
And then when it comes to target moving speed or just measurement rate, that's not something that is relevant for this use case. 
Normally for stationary, you can do the ranging as a one-shot, so just do it when you want to commission your devices, but you can do it more often. 
There really no rule there. 
And when it comes to non-line of sight, we actually measure this here at our office. 
And here we're not talking about body blocking. 
That's not so much of a problem. 
That's more of a transient thing if someone walks in between the two devices. 
It's really about static obstacles that you typically find in offices and hospitals and different kind of scenarios. 
So you're going to have walls of different materials. 
You're going to have glass doors and various other objects. 
And we've seen that the performance there is actually quite satisfactory, but again, something that we're working on improving as we move forward. 
Okay, so moving to some of the application use cases. 
So the first one is wake on approach, which again, I think it's quite self-descriptive. 
So you have a device, and as you get close to that device, so it detects your proximity, and then it will react depending on what the device is. 
It could be a light bulb. 
We walk into the room, it detects your presence, it detects you're in the room, and it activates light bulbs, a certain dimming configuration. 
It really depends on the application. 
But the point here is that compared to RSSI, channel sounding offers more accuracy, and this should result in a much better user experience. 
So that's kind of the key thing there. 
And because of this compatibility with smartphones, this will make this kind of experience more accessible to a variety of customers out there. 
And there's nothing like a good demo to show what this looks like. 
So let me just remove your laser pointer, and I'll start this demo for you all. 
Imagine walking up to your computer and having it unlock automatically. 
No touch ID, no password, just your presence. 
And then when you walk away, it locks automatically as well. 
So here's what we're working with. 
On my wrist, I have a Pixel Watch 4 running a custom app. 
This acts as the reflector. 
So that means in channel sounding that it responds to ranging requests but does not calculate the distance itself. 
On the other side, we have a Silicon Labs EFR32MG24, and this specific development kit is the DK-2606A, which has dual antennas for more precise measurements for antenna diversity, which helps with accuracy for distance measurement. 
So on my Mac, I have a Python script that is connecting to the serial port on the SoC, the development kit, and reading the distance measurements, and then making decisions whether to lock or unlock my Mac based on the distance. 
So in terms of distances, we have 0.8 meters is the threshold where we unlock the Mac. 
So when we get closer to 0.8 meters, as soon as we hit 0.8 meters or closer, then the device or the Python script decides to unlock my Mac. 
In terms of the distance to lock my Mac, that's at two meters, and then we have kind of a dead space in the middle or a dead zone between 0.8 meters or 80 centimeters and two meters. 
So just to show you the serial port in general, what it looks like out of the box. 
So this is just connecting the serial port to a terminal program and not through the Python script. 
I have a serial port, and this is what the firmware displays in the serial in the terminal. 
Now, I'm going to disconnect this because we are going to run the Python script, and we can only have one of them connected to the serial port. 
So here's the serial port. 
I have the watch here, I have the SoC, the development kit, and in the first time, there's going to be a bonding or a pairing between the two devices, and this is a requirement by channel sounding. 
So if I hit start, it's going to connect, and the first thing it's going to ask me is to pair. 
And there we go. 
Now it's connected, and we have them paired together. 
The distance is being shown. 
If I move my watch a little bit far away, you'll see that it's getting farther away. 
I'm not going to move it far from the screen to detect the locking because that will kill my screen recording. 
But we'll get to a real-life demo and testing of this later in this video. 
But I just wanted to show you kind of the application and how it looks, what it looks like. 
It just updates based on the distance between the two devices. 
So moving far away or closer, you'll see that the distances get updated automatically. 
All right. 
Let's give this a test. 
So here's the development kit connected to my Mac, and I'm about to run the Python script. 
Now, the devices are already paired, as you can see here. 
If I click start, it should connect right away. 
So they are bonded already, and the screen shows the distance, and I can just increase this to make it more obvious. 
Okay, so now we have all the distances showing. 
I'm going to move back to about 0.8. 
So I have the measuring tape here on the ground. 
This is around 0.8 meters right here, and you can see here the distance is pretty close to that, and we're going to move back all the way to two meters. 
So this is the two-meter mark. 
Now, as you can see on the screen, it just locked. 
So basically, it locked at the two meter. 
It detected a few concurrent or subsequent measurements of two meters and decided to lock. 
If I move back, nothing happens. 
Obviously, we're moving past the two meters. 
If I come close, I'm going to stay here. 
This is in the dead zone around 1.1, 1.2 meters, and I'm just going to move closer until we hit the 0.8 meters, which is around here. 
So this should detect that we're in that range, and it will automatically unlock the Mac. 
So there are different tests that you could make. 
Again, this source code, all of it is available for you to download and try it yourself. 
The Python script, the SoC firmware, the watch app, and even if you don't want to run the watch or build and compile the watch app, then I have the APK included in that package as well. 
Feel free to download it, test it out, and try it out. 
Again, disclaimer, this is demo code for information, for demonstration purposes only. 
Use it at your own risk because you do have to enter your password in for the shell, the Python application, in order to save that to your password keychain and be able to unlock your Mac for you based on the distance. 
But that's a very good starting point. 
It showcases what will possibly happen in the future when channel sounding becomes embedded and integrated within laptops and many other devices around us. 
Hope you enjoyed this video, and if you have any questions, feel free to reach out to me via the contact page or comment on my LinkedIn post. 
I'll see you next time. 
All right. 
That was a really cool demo. 
So that was done by Novelbits, our partner, Mohammed. 
So that's the person you would need to reach out to and check the Novelbits website if you're interested in trying out this demo with the materials that Mohammed has made available. 
Okay, so the other one is then for auto-mapping, so this static device positioning. 
So it mentioned a couple of use cases there, for example, for solar farms, where you might have dozens or even hundreds of devices with their power electronic units. 
So what this can really help with is the commissioning piece and being able to use the channel sounding data to build a 2D map basically automatically, without going one by one and commissioning manually, which is a really time-consuming application. 
And then once you have that data, of course, you can use that to improve the maintenance aspect. 
What you see is that in some of these large solar farms, often the inspection is done using drones, and if you know the exact location of what you're trying to inspect, obviously you're going to make that operation much, much faster. 
So that's really the benefits here of using channel sounding for auto-mapping. 
So the way this works is that you're going to have the devices ranging against each other, so think of relative measurement, and then you can use that information to build out this 2D map. 
So the devices will act both as initiator and reflector. 
So they'll always range in both directions. 
And we have also a demo that shows how this would work in a real use case. 
In our second demo, we will show how channel sounding can enable auto-ranging between stationary devices like access points or luminaries. 
In this demo, we will run a script that gathers data from five of these devices. 
They are all Silicon Labs boards used for internal development placed around an office space. 
Each board measures distance with other boards, and the script running on the PC generates a map of the space based on those measurements. 
This accurately represents the actual placement of these boards in a physical space. 
Okay. 
Much shorter demo, but also it's, I would say, a concept that's relatively simple to understand how you can build a map based on the range in between the different nodes. 
In our- Okay. 
So one of the key topics or one of the key questions that customers often have on channel sounding has to do with phone interoperability. 
So channel sounding has made its way into mobile phones. 
So if you look at Android, since Android 16, there has been a channel sounding API, and there are devices you can purchase today that support channel sounding. 
So the expectation is that channel sounding has the potential to become sort of the standard for ranging when you're using your phone. 
The same way that if you think about with Bluetooth LE kind of becoming a standard for data exchange between devices, channel sounding has a lot of potential to kind of become that for ranging. 
So that's where interoperability really plays an important role because this just needs to work. 
Just the same way that Bluetooth LE just works, channel sounding needs to reach that same level of interoperability. 
And even though, I guess in a logical sense, the expectation is that the phone will be the initiator, and it can. 
Phone can actually work as both. 
It can be the initiator, so meaning that you're ranging to, for example, an asset tag, so that you're running the algorithm on the phone. 
But it could also be use cases where the phone, the intended use is as a reflector, where you actually want to run the ranging algorithm on the device and not on the phone. 
For example, keyless entry is a good example, or the proximity use case as well, where your phone is the reflector and the ranging is being done on your light bulb or on a lock or wherever you're using the phone to get that proximity detection. 
So it's really important to have that interoperability and standardized behavior to really be able to ensure that channel sounding scales and sort of penetrates different use cases across different markets. 
And with that, we go to our last demo that shows exactly how, using our mobile app, you can demonstrate the phone both as an initiator as well as a reflector against the channel sounding dev kit that we have. 
Okay, so last demo of today's tech talk. 
In this video, we are going to demonstrate Android support for channel sounding using Silicon Labs devices. 
We will be using the EFR32 XG24 channel sounding dev kit We have two scenarios. 
In the first scenario, the Android phone acts as the channel sounding initiator. 
Using the Simplicity Connect app, we pair and connect the phone to a channel sounding enabled device. 
In this case, a tag, which is the DK2606. 
Once connected, we then start the channel sounding ranging directly from the app. 
The phone initiates the ranging process, the device responds, and the measured distance is displayed live on the phone screen. 
This scenario demonstrates how channel sounding can be seamlessly integrated into Android applications. 
In the second scenario, we take a quick sneak peek at how channel sounding can also support reversed roles, where the Android phone acts as the reflector while the DK2606 device becomes the initiator. 
Together, these scenarios showcase how Silicon Labs devices enable channel sounding with Android, offering flexibility across a wide range of applications. 
Okay. 
So with that, we move into the Silicon Labs solution. 
So starting at the hardware, so we have the BG24 or MG24. 
So this is our wireless SoC that enables channel sounding optimized for battery power. 
So it's a very low-power device. 
I won't go through all these specs, but I do want to highlight that it's a very compact device, so it's also available on... 
Let me bring back the laser pointer in the previous slide. 
The form factor, it's available in a very small WLCSP package. 
And yeah, it has all the sort of specs that you would expect from a Silicon Labs wireless SoC. 
And then we have the dev kit that kind of introduced itself through all of those demos. 
It's been available for a bit over a year now. 
So it's based on that MG24, BG24 part. 
It has two antennas, so you can test both with one or with two antennas, so up to four antenna pads if you're using two kits talking to each other. 
And it's fully supported in the SDK as well as in Simplicity Studio. 
So you have ready-made sample apps and even demos that you can flash straight into the kit to get that early evaluation done really fast out of the box. 
And a bit of a reveal here. 
So one of the main questions that we often have from customers when we talk about the hardware offering, and because they know that Silicon Labs has a broad portfolio of modules, is: Do you have a module for channel sounding? 
And the answer is that we don't have it today. 
We're actually coming out with a module in the second half of the year. 
So this is the BGM241S. 
It is based on the BG24 part that I just shown earlier. 
So essentially all the specs are the same, but really it brings all the benefits of using a module in a wireless design as you would basically use for selecting a module. 
So basically, you got all the components that you need pre-certified. 
So it reduces the risk when it comes to RF design and simplifies your design of your end product without having to do the RF part yourself. 
Okay. 
We also have tools in Simplicity Studio, the CS Analyzer tool. 
So this works together with the samples, and allows you to get the visualization of the distance and different variety of parameters that you can use to evaluate channel sounding, and also to do your own development and troubleshooting throughout the development cycle. 
And kind of wrapping it all up. 
So the one thing that we could really say about channel sounding at Silicon Labs in terms of our offerings, that we have a complete solution, especially now with this module coming out later this year. 
Because you get from the hardware with IC and module option, you get the development kits for a quick evaluation. 
You get the Bluetooth 6.0 stack that is our own in-house stack. 
It is qualified. 
It supports PBR and RTT modes. 
You also get the algorithm that allows you to do the actual ranging and computation, and the SDK and the tools with the samples to get you really through the development phase as quickly as possible and increase your time to market. 
Why this is important is because this is really a one-stop shop for channel sounding. 
Often, especially if you want to use a module, what you might find yourself in a situation that you're getting a module from a vendor, which has an SoC from a different vendor, and then you need to get the ranging algorithm from yet another vendor. 
So you try to put the channel sounding solution together, and you have three interfaces and potentially three companies you need to interface with if you're running into issues or if you want to optimize the accuracy or whatever it might be on your end application. 
With Silicon Labs, we offer everything. 
From the hardware, both the SoC or the module, depending on what your needs are. 
Then you have all the software, including the algorithms and the tooling to get you through evaluation and development to your end product go to market. 
So that's really important to keep in mind. 
And yeah, we're starting to wrap up, I guess, just in time. 
Just if you want to learn more about Silicon Labs channel sounding, you can visit our Getting Started page, grab a kit. 
You have a lot of information online, and in addition to the earlier slide that I showed with different resources from previous events. 
And if you have any questions about our offering or any technical questions, reach out to our developer community, and I'm sure our apps team will be able to get you on the right direction. 
And with that, I'll hand it over back to Chandana. 
For a Q&A. 
Perfect. 
Thank you, Tiago. 
We have quite a few questions here. 
So the first one is: Does channel sounding have distance advantage over UWB? 
Distance advantage. 
I guess it's about accuracy is the question there, or distance in terms of how far you can range? 
I guess we can take it in both directions then because that's the question I have. 
So on accuracy, that was shown on the slide. 
So indeed, UWB offers higher accuracy, almost centimeter level accuracy, and channel sounding, best case, you're within a sub-meter accuracy. 
Normally, I try to turn this question around, and really, what is the accuracy that your application needs, right? 
Because better accuracy doesn't mean that you need to go with that solution. 
You really need to think about what are your requirements, right? 
What do you need to enable the best experience to your users and the end users of your application? 
So, and often you might get the answer that channel sounding fulfills your needs, and that allows you to build a much more cost-effective solution. 
With mobile phone interoperability, that will be more and more true as we move forward, as channel sounding continues to get deployed across mobile devices. 
But of course, if you truly need centimeter level accuracy, then UWB is the solution to go with. 
So there's really no question about that. 
So it's really about evaluating your requirements and what best fits those requirements in terms of accuracy, in terms of cost, power consumption, across some of those parameters. 
Yeah, no, for sure. 
I agree, and even totally depends on your application. 
So moving on to the next one, will you elaborate why having multiple antenna paths is helpful for channel sounding? 
I would just say that more data is always a good thing, right? 
So you get more antenna paths to measure from. 
Right? 
So if you only have one antenna on each side, that gives you one set of data points. 
But if you increase the number of antennas, you can just measure the different antenna paths against each other. 
And when you have more data, you increase the accuracy. 
So again, it goes back to, it's a bit like the decision between channel sounding and UWB, but maybe in a smaller scope, in the sense that if accuracy is something that you want to optimize for, then definitely two antennas will give you more accuracy. 
If cost is something you want to optimize for, then the one antenna would be the solution, assuming that the accuracy is good enough that fits your application requirements. 
Yes, perfect. 
And again, agreed. 
It all depends on your application, mainly. 
But the next question that I have is, again, for channel sounding. 
How power intensive is the channel sounding process, taking into account battery-operated devices? 
Is it possible to duty cycle the channel sounding process for further energy savings? 
Yeah. 
So your application will have control, right, over when you want to run the channel sounding procedure. 
I think it depends a bit, are you initiator or reflector? 
So the initiator is the one that requests the ranging. 
But you're essentially interleaving channel sounding procedures with a regular Bluetooth LE data exchange. 
But if the question is, is channel sounding low power? 
The answer is definitely yes, because it builds on top of Bluetooth LE technology. 
Right? 
So it basically uses the connection interval. 
You have data exchange, you have channel sounding procedures. 
And if power consumption is a concern, then of course you can throttle and you can control the frequency at which you're doing the measurements. 
So there's always some trade-offs you can make between power consumption and how often you run the channel sounding procedures. 
So a lot of these go back to what does your application need, but I think the essential thing is that your application will have control, and therefore, you can make these decisions even in the lifetime of the application. 
Obviously, if your battery starts draining, you can throttle the channel sounding, so that it doesn't happen as often, and you sort of preserve some battery with that. 
Makes sense. 
Thank you. 
I think we already addressed this in the presentation, but just because we got another question, what phones have started supporting channel sounding, and do we see more phones supporting it? 
Maybe you can help me on this one, Shana, because I don't remember the models from the top of my head, but I believe Pixel 10 supports it. 
Yes. 
And there's also some Samsung models that support it. 
I don't remember specifically which ones. 
So Google's latest Android versions include it. 
So that includes Pixel 9 and 10- 9 and 10. 
Okay ... as far as I know. 
And we are, at Silicon Labs, actively involved in the interoperability testing, so stay tuned for that, but just not only with phones, but also other silicon vendors. 
But yes, for now, confirmed is the latest Android version in Google phones, so Pixel 9 and 10. 
Mm-hmm. 
Yep. 
The first of many, hopefully. 
Yeah. 
And then another one that we have is how many access points can you map using auto mapping? 
I think with our current algorithm, we're somewhere in the ballpark of 10, basically, that you can range from this sort of observer node. 
But of course, then they can range against each other. 
But I think that's kind of the limit that we have today. 
Yes, and I would just like to add to that, we have tested up to 10 tags per access point, and then when it comes to ranging, we are supporting the one-to-four initiator/reflector combo and the four-to-one initiator/reflector. 
So one-to-four or four-to-one. 
And then the next question that we have is can we exchange Bluetooth data while channel sounding ranging is happening? 
Yes. 
I feel like I've, in a way, kind of answered that question in the sense that channel sounding is basically a procedure that happens on top of Bluetooth LE. 
So you can have your regular data exchange, and you interleave that with channel sounding. 
Of course, the caveat here is that nothing is for free. 
So airtime is the same. 
And either you want to have channel sounding, which will affect your data throughput, or the other way around. 
If you want to have high data throughput between two devices, then of course you reduce, let's say, the airtime, which is available for channel sounding procedures. 
So again, it goes back to what does your application need at a given point in time, and you need to be able to make the decisions which one you prioritize in a In a specific use case or specific combination. 
Perfect. 
Thank you. 
Another question that I have is more about channel sounding protocol support. 
So is it possible to support 15.4 and Bluetooth channel sounding? 
So today, we don't support channel sounding in a dynamic multi-protocol scenario, but that's something that we're working on. 
So I would say stay tuned to updates from our side, and you might see something new coming out in the range of channel sounding as part of a DMP. 
And that would not be exclusive to 15.4. 
Potentially, you could use it with other protocols. 
So that's something that's probably going to be available, but we don't have it today. 
So stay tuned. 
Perfect. 
And then how does the new module performance compare with the existing channel sounding dev kit that we have? 
So the goal with the module is pretty simple. 
The same way that you would choose a module for a BLE design, let's say, you would expect the performance to be on par with the chip down design. 
The same thing applies to channel sounding. 
So the performance that you can find today with the development kit that's based on the BG24 will be on par with the performance for the kit that will have the module, the BGM241S. 
So expect parity performance when it comes to channel sounding, just as you would with any other chip versus module type of comparison. 
Okay, perfect. 
And then this will be the last question that we will be able to answer with the time that we have, but what is the per unit licensing cost for the algorithm? 
So there's absolutely no cost on the algorithm. 
So this is license-free. 
It's provided as part of our SDK. 
It's there ready to use. 
When you bring up a sample, the algorithm is already there. 
You only need to configure the variant that you want to use. 
And this is, I think, again, emphasizing that this is a key differentiator of Silicon Labs. 
So we provide the full solution from the hardware to the SDK to the algorithm, and having the choice of both module and SoC, really a one-stop shop for channel sounding. 
Absolutely no license or no cost involved when it comes to the software availability. 
Okay, perfect. 
So thank you so much, Thiago, for answering all those questions. 
Thank you.