Extending Bluetooth LE Tracking via Satellite, Featuring Hubble Network

Hello, everyone. Good morning, good afternoon, good evening. Welcome to Silicon Labs September Bluetooth Tech Talk. I'm thrilled to be here today, joined with Hubble Networks. Today we're going to be talking about extending Bluetooth Low Energy, tracking with satellites, featuring Hubble Networks. So let's introduce today's speakers. Myself, my name is Tristan Cool. I'm a senior product manager at Silicon Labs. I have the honor of being joined by Daniel Reynolds, a senior product manager at Hubble Networks. Today, he and I will be going through the presentation, the demo, the conversation. At the very end, we'll be joined by my colleague, Chandana Dairyani, a product manager at Silicon Labs, and we're thrilled to have the head of product, Apoorva Nori, from Hubble Networks, who we'll bring back on at the end to address any questions.   

So that being said, let's look at today's agenda. So it seems like a packed agenda, but we have plenty of time for a very exciting demo from Hubble. We're going to have lots of time to address your questions, so by all means, please dump them into the chat, and we'll make sure to address and moderate as many as we can. Today we're going to be talking about the problem statement, the challenges behind asset tracking, remote monitoring, condition monitoring. We're going to propose a new global approach in IoT visibility. I'm going to walk through some of our key applications and inspire you to explore more.   

And then I'll pass the microphone over to Daniel at Hubble Networks to walk us through a very exciting demo, explain the solution, how it works, the problems we're solving, see it in action. I won't give any spoilers. We'll wait for that. And then, of course, we'll leave you with some call to action, some resource pages, so you can get started on your own. So, let's begin. So we preface this, we're talking about asset tracking, logistics management, remote monitoring, remote sensing, condition monitoring, all these different words to describe the idea of tracking and monitoring your property.   

So, there are many ways to solve this today, of course, multiple very viable solutions, in fact, but there's gaps and challenges. The first one, first and foremost, being coverage. Visibility, right? So you can imagine, as you know, your assets can be indoors, they can be outdoors, they can move within, they can be static, they can be moving, they can be very isolated and remote, or they can be in the middle of a very RF-crowded environment. So this coverage is unpredictable. Now, of course, there are solutions that solve this, but this entails increased investment in your infrastructure, right?   That means adding more modules, more radios, more gateways, paying for more packages and data plans, for example. So it can be sometimes impractical or not entirely cost-friendly. And then most importantly, adding all this hardware adds cost to your design, adds volume, size to your design, and quite importantly, a lot of these devices are, of course, battery powered, so we are adding strain on the battery lifetime as we solve this problem. So this is true for a number of technologies, but really what asset tracking as an application needs in order to scale is a viable hybrid solution that can work for both short and long-range tracking.   

So we're going to explore what that might look like. So, as I said, let's discuss what that type of solution could look like in an ideal scenario. How do we extend our current Bluetooth visibility from meters to hundreds of kilometers? Bluetooth being one of the de facto technologies used in this. So if we're looking at how we want to piece together this solution, ideally, we minimize or eliminate any additional hardware. So that means more antennas, more modules, front-end modules, different power amplifiers. All viable solutions, but they come with complications. You have to add different levels of solution, right?   

You can have a GPS, cellular, Wi-Fi, LoRa. Again, all viable solutions, but they come with hardware and certification challenges, of course, right? That being said, the idea of maximizing the return, the capacity of the solution you do choose, right? So lowering that cost, lowering that complexity, so that you can be as close to an experience of a real-time tracking solution when needed by leveraging what you already have. And then, of course, the idea is to leverage the platform of Silicon you've selected, right? A lot of these platforms are optimized for low power. Your application needs to take that into account.   

So we're going to discuss that in great detail. But there's ways to maximize your battery and to solve all three of these solutions, so that your solution can be viable for both long range and short range, and everything in between. So let's look at just a couple of examples here. So of course, we're speaking to you guys. You guys are the expert. You may see yourself in this slide. You may want to propose a new solution. This is one of the fastest-growing vectors at Silicon Labs and, of course, at Hubble. We deal with customers every day trying to solve these challenges with different solutions.   

So, we'll dive into a little bit of them, but I want to serve this as an inspiration to see if you guys resonate with these applications or if you have other ones you might want to bring up later or follow up on. But if we look at some of the key ones that suffer the challenges I listed before, we think of global logistics, shipping containers, for example, that will transition from rail, train, to the back of a truck, to onto a boat in the middle of the ocean. They may remain parked for several weeks or months.   

So the visibility and the need to be powered for that long is certainly a challenge. In the conventional asset tracking fleet management world of construction vehicles, pallets, bins, they face the same challenge. Tools and machinery are getting lost or damaged, and it's becoming an inefficiency at some of our customers, and certainly an incurred cost. Then we're seeing expansion into remote industries, agriculture, industrial infrastructure. So things, power plants, oil and gas pipeline, even solar panel fields, where it's expensive, perhaps dangerous sometimes, or complicated to get technicians there. We're talking highly remote areas, things like middle of the forest, things in very remote areas of the planet.   

So it's difficult to have reliable monitoring of these high-value assets throughout their life cycle, without incurring a cost or really finding the right solution. So, like I said, there's a lot of things that are solvable here. I'm going to pass the microphone over to Daniel from Hubble. I've set him up to explain the solutions that we can address in this space. And I'll join you back at the end to talk more about Silicon Labs, and we'll go through your questions. But over to you, Daniel. Thank you again for joining. All right. Let's begin. Thank you, Tristan, and good morning, everyone.   

Good afternoon. My name is Daniel. I'm on the product team at Hubble. We're very excited to be with you here today. Let's start at 600 kilometers above Earth, Bluetooth to space. Not possible, right? That's typically the first thing that people say when you tell them about Hubble network, and that's actually a good reaction. You want that. It's proof that they're listening. Because yes, Bluetooth to space is possible with Hubble. We demoed this back in January at CES, if any of you were there. Since then, multiple Hubble customers have brought their hardware online, and this is what we're going to demo today, that Si Labs Pro Kit on your desk.   

I'm using the EFR32MG24 specifically, can reach the constellation of Hubble-built low Earth orbit satellites 600 kilometers up. No new hardware, just a firmware update. And you can do it yourself in minutes, so now you have plans for the rest of the day. I'm going to explain how it works as we get into it, but there's more to Hubble Network than just satellite. We have a global ground-based terrestrial Bluetooth network. Combined, you get the full power of what we call the dual-stack network, satellite plus terrestrial, which lets you transmit low bandwidth data from anywhere. So before demoing, let me share a bit more about Hubble, what problem we're solving with Bluetooth, and how we're doing it technically.   

Hubble's built the world's first global Bluetooth network. It has two sides, which together unlock that global connectivity. There's terrestrial, which operates on standard Bluetooth Low Energy spec, BLE, and it's composed of more than 100 million access points globally distributed. That's 2,500 cities, more than three million square miles of populated areas and road network, to put that in perspective, and they're all listening for Hubble devices. The satellite side is a Hubble-built constellation listening for your devices from space, and this gives you that off-grid coverage. It's made possible by running the Hubble device SDK on your stock Bluetooth system-on-chip radio via firmware update.   

That's the thing that connects both sides of Hubble Network, the Bluetooth chip plus our firmware, and it's worth repeating. Both satellite and terrestrial use the same Bluetooth chip and rely only on a firmware update to run the Hubble device SDK. No hardware change required, no custom infrastructure on your part. Your device simply beacons on Hubble, and we do the rest. It makes sense to pause here and ask the question, why Bluetooth? Why are we so obsessed with Bluetooth? So as you know, the Internet of Things landscape is fragmented today. There's cellular, Near Band IoT, LoRaWAN, RFID, legacy satellite modules.   

There's also Bluetooth, but it's typically trapped in local networks. Bluetooth has several advantages. It's the most ubiquitous IoT radio on Earth. It's ultra-low power, and therefore battery power devices can stay alive in the field for years. It's the most competitive price point for a chip, which means you can get connectivity without blowing up your BOM. All of that means it's got the potential for the largest possible scale. Hubble sees a world where we have billions of devices transmitting data on the network every day. A global Bluetooth network is the solution to connect your edge AI devices, edge AI, the buzzword of 2026, and that's why IoT is having a renaissance.   

So we see a huge advantage for Bluetooth relative to some of those alternatives that I mentioned. Of course, you can build hybrid devices depending on your use case, so think multi-network connectivity strategy. But without getting into the specifics of each of these comparison columns, the Bluetooth TLDR, the bottom row. It's the competitive BOM. It's the coverage across borders, no country-based data plan required. It has the least power draw radio, meaning devices beacon longer, have a longer life. And with Hubble, you get global connectivity. You also get an enterprise-grade API first platform with everything you expect for APIs and webhooks to manage your deployment.   

Okay, let's get into the details of Hubble Network, both the terrestrial and satellite sides, the dual stack. First, what's the same? So both only require a firmware update, as mentioned. You do not need to redesign your Bluetooth-capable hardware. Both also allow you to transmit custom payload up to 13 bytes. This is enough for micro telemetry, so think sensor readings, event detection, log data off the device. This is where edge AI comes in. It allows you to move from just tracking to actual intelligence, whether it's environmental insight, information about the device itself, you get the idea.   

The custom payload is what unifies the two networks as well. You're getting that same structured payload, whether it's transmitted over terrestrial or satellite. Let's go deeper on terrestrial. It works like this. A scanning gateway is in range of your device and recognizes the Hubble service UUID in your Bluetooth advertisement. That gateway is appending its own location lock and metadata like the signal strength, RSSI, forwards that to the Hubble back end, where it's decrypted. The packet is sent to your organization via API or webhook. Because terrestrial's built on standard Bluetooth Low Energy spec, it means any SiLabs SoC or MCU is compatible.   

Any Bluetooth chip is compatible. When you think about RTOS, we're compatible with Zephyr, so SiLabs friendly, also free RTOS and bare metal. The device itself conforms to standard BLE transmission profiles, so think TX power between zero and eight dBm, decibel milliwatts, and advertisement interval, one to four seconds, and you can play with these variables to maximize your discoverability on the network. All this translates to years of battery life, even on a coin cell. What's the result of this in terms of real world detections? So remember, detection on terrestrial network is probabilistic. Did a gateway hear my device?   

So that's a function of scanner density, the gateway behavior itself, and then the TX on your device itself, the strength of the advertisement, the interval. The bottom line is you're easily going to see 10 or more detections per day in populated areas, and each one can transmit that custom payload, your micro telemetry. Terrestrial is great for mobile endpoints. We're going to pick it up on terrestrial network. Moving to satellite. So it's the same 2.4 gigahertz radio, but it's running custom Hubble protocol via our SDK. This slows down the bit rate of the broadcast to around 125 bps, bits per second.   

That, plus a high TX power, plus the processing gain on the satellite side, is what buys you the 600-kilometer link. So what TX power is required? The current generation of satellites requires 20 dBm transmit power. So most designs are going to require a front-end module or power amplifier, and in the case of the SiLabs board that we'll demo, it's a PA already in your pro kit. The peak current for 20 dBm rules out a coin cell, which is why we recommend static endpoints today for the satellite network, so plugged into power or with a larger battery. 

You need at least 40% antenna efficiency, and an accurate clock, so 40 ppm crystal. You need that clock because the transmission logic is based on satellite pass opportunities. Because our satellites have something called station keeping, they maintain predictable orbits. With our SDK, you provision your device once with the satellite orbital parameters, then as long as your device knows what time it is and where it's roughly installed, install location, then you can always compute when the satellite is going to be overhead. That's computed locally on the device. So this is why our current generation works best for static endpoints, something with an install location.   

With our current constellation of six satellites, you're getting at least one opportunity per day to transmit, often more. It depends on your location. And then the data that's picked up by satellite, it's available within six hours of the pass itself. That's because the satellite needs to downlink to a ground station to get it onto the cloud. For the record, the P50 latency on that is closer to two hours. Okay, last thing on this slide, that text at the bottom hints at major enhancements coming in 2027 for satellite. What are those? Briefly, our next generation of satellites is launching next year.   

They're five times the diameter, nine times the antenna surface area. All of this means much higher link margin, which allows you to connect down to a device beginning at just four dBm on the device side. This is what's going to open up mobile endpoints and coin cell power on the satellite network. The satellites are also sensitive enough to provide estimated device locationing as an alternative to GPS. So today's satellites are only capable of course locationing, and we'll see that in the demo. So if your device is not a static endpoint, you'll need to send custom payload there.   

That changes in 2027, so I'll leave you with that teaser. But let's move on to the demo You know how it works now. The fun part is actually building. So today I'm flashing the Silicon Labs EFR32MG24 Pro Kit. Why did I pick this board? Because it's satellite network capable. It has the 20 dBm PA on it built in. That means we can build something that beacons on satellite as well as terrestrial. So we're calling that a dual stack build. I'm going to demo a satellite-only bring-up with some basic firmware, just for testing transmission to satellite, and I'm also going to show off an existing dual stack build with custom payload.   

All right, let's see it. So what we're going to do in this demo, start by building and flashing a satellite image for the EFR32MG24 using a Hubble native flow. We're going to test it in the field, I've got some pre-recorded footage of that, and then back to the dashboard where we are now to see packet data transmitted. So I've logged into my Hubble dashboard. I already have some devices in here. They're beaconing on both networks. Off screen, I've plugged in my board to the laptop with a data capable USB-C. We're going to click Add a Device.   

This is that Hubble native flow I mentioned. It's a step-by-step guide for bringing a device onto the network, a dev kit, in just a few minutes. So I selected Satellite. I'm picking the EFR32. I'm going to click Guide Me, just to get some expectation of what happens next. So provision the board, place outside, see data come through. My board's already plugged in. On this step, I can copy this one line command. I'm on a Mac, so opening up Terminal, and this initiates something called the Hubble Install Application. It significantly simplifies provisioning your board. You can see that I've already authenticated to my organization.   It's already selected the board. You saw me do that on the dashboard side. I'm going to give my device a name so I can test it and see the data for this specific board, and then it's just running the command flash. All right, just like that, we've provisioned our board. Now, the Hubble install masks some of the complexity here. We're building a test image that beacons on the satellite network continuously. You could always start from our GitHub instead and do this manually. For example, a Zephyr RTOS build. You could also start with Simplicity Studio. We have a terrestrial reference app for this.   

That's often a starting point for a custom build. But for our purposes, let's move on to the next step, which is getting ready for the next satellite pass. We've got some basic pointers, to maximize the probability of a successful transmission. I'll mention this again in the recording we're going to see. Let's check out the device that we just registered to Hubble. Okay, so there's no data here yet. That's expected. It's also grabbed my browser location as an install location, so that allows me to know when there's a pass over where I'm located. I'm adding a tag here so I can get a countdown.   

That happens automatically now. We see there's a pass coming up in less than two hours. I'm going to show you one more thing on our dashboard. We call it Pass Explorer. This is an expanded tool to know when passes are coming up for a given location. We built this for organizations that are going zero to one for devices transmitting on satellite. So you can see all the upcoming passes for the next several days, and we see again, there's that pass coming up this afternoon. So we'll pick up here with real world device placement, shot on iPhone.   

And this is the end result, that Si Labs Pro Kit waiting for a satellite pass. We're going to go back a step in the video, to board provisioning. This time I'm building a dual stack image, satellite plus terrestrial. I'm using GitHub as my-- I'm using the sample app on GitHub rather, where it's a Zephyr RTOS build. You can see there, I'm using the integration guide. Got Terminal open. Hubble Network is my manifest repository on GitHub. Okay, we flashed the board. We're testing the terrestrial side now. So I have Hubble Connect app open. That turns my phone into an extension of the terrestrial network.   

I got some detections. Satellite side now. You've seen this tool. We're going to test satellite in the real world, so we're looking for our next pass opportunity. You can test this using a software defined radio as well, just to make sure it's beaconing properly. We're going straight for the real world test. So cutting over to some found footage of me leaving the office here in Seattle. We're going to test on the beautiful grounds of Seattle University. This is a stand-in for a rural environment where there's no coverage and you need satellite, so think about that.   

When it comes to the placement of the device, the key is unobstructed view of the sky. Imagine a 45 degree cone for your device to beacon in, ideally with no buildings or trees in the way. Then it's just about the pass opportunities. When is a satellite overhead? With our current constellation of six satellites, you get at least one pass per day, often more. The duration of that pass depends on the max elevation angle relative to the horizon. That's where the 45 degree comes in. Okay, there's a pass coming up in about two hours like we saw.   

If I was going to leave this overnight, I'd put an enclosure on it. We have 3D printed test beds at HQ. But with that, let's go back to our dashboard and see the data that's been transmitted. Back in the dashboard, we'll go find that device that I provisioned in the video. I recorded this a couple days later, so let's see. Going to go back seven days to get the full picture. Okay, we have data. Both networks actually, satellite and terrestrial. So you can filter just for satellite and see we've got successful transmissions. We'll go and expand the packet history.   

I want you to see the granular data that you can consume via API or webhook. So there's the device ID in there, device name of course. I've got the timestamp when it was detected by the satellite. There's a placeholder for location with that big accuracy error bound. Locationing is not priority for the current satellites. That's the next generation. There's no payload in this example that I built. So let's go see one that has custom payload. This is the same build except now custom payload is temperature data. Specifically, it's the board temperature sensor. Ton of transmissions for this device.   

You can see we graphed the temperature reading over time in the UI. It's the payload both for terrestrial and satellite. Now, custom payload, we talked about it, but in this example, temperature is just a placeholder for whatever you want it to be. It could be the battery level of your device, accelerometer event data, did something move, et cetera. You can see the hex code version of that transmission there. Just switch back to the auto decode for temperature reading. And filtering just for satellite now, you can see on the map an indicator of the course locationing that's possible with SatNet, and this is going to be significantly refined in 2027 with our next generation satellites.   

All right, let's talk about last thing, how you plug this into your backend. So Hubble is enterprise grade platform. We've built API first. So the next step here is go create an API token. It's very easy to do that. Then you can begin to interact with our cloud programmatically, manage your devices, access your data. You can use the Hubble CLI tool. We support webhooks as well, of course. That's where we're actually going to push data to your server at scale, and that makes a ton of sense in a production context. Okay, let's sum it up.   

So two points. Hubble is bringing global connectivity to Bluetooth. Your custom device can connect with Hubble on terrestrial and/or satellite network using your Bluetooth radio to transmit edge AI data from anywhere. It just takes a firmware update to implement the Hubble SDK. We demoed the EFR32MG24 Pro Kit, both a satellite-only image for testing and a dual stack build with custom payload. You can do that in an afternoon. So how do you get started? Three quick suggestions for you. First, go try it out. Try that Hubble native bring up in our dashboard. Sign up at dash.hubble.com for free.   

Second, for terrestrial coverage specifically, those 100 million globally distributed gateways, check out network.hubble.com. The heat map and configuration tools there give you an idea of what detection rates at scale look like globally. And then lastly, start building your own custom hardware. Go straight into our SDK. Docs.hubble.com is a good starting point. We have a quick reference chip matrix, which gives you jumping off points into GitHub for your chosen Bluetooth chip plus RTOS, so sample apps, reference apps that you can clone. Okay. With that, I'm handing the mic back to Tristan. Thank you. Daniel. That was really impressive, and I can attest in preparation for this, I did bring up my own kit, and it was truly as simple as that, and I'm beaconing to a satellite and seeing it on my phone, so well done.   

Expanding on your slide, in fact, and I'm answering a lot of questions in the chat, so the timing is great. We're going to discuss how to merge the two, how to merge the software solution to a Silicon Labs dev kit. And then, this is the process, in fact, right? So of course, if you're familiar with Silicon Labs or new to Silicon Labs, we start off with a dev kit, and we have dozens of them across multiple of our part range that support Bluetooth. So I will elaborate a bit further. Of course, we have a Zephyr stream, so we are Zephyr compliant.   

So you can build your native Bluetooth app on Zephyr, and then you can follow Daniel's really easy to follow steps and port the Hubble solution. But we're seeing that in the field, a lot of customers want to enhance an existing Bluetooth or other solution with Hubble. So that's where Silicon Labs offers a development space. So we have an IDE we call Simplicity Studio with a lot of built-in network analyzers, power analyzers. We have flashing tools. So this is really where the two meet, where Silicon Labs hardware and RTOS meet the Hubble software solution. And then, of course, very quickly, you're going to want to deploy.   

You're going to want to move from a prototype to a real product. And again, that's where Silicon Labs is going to be an asset. We offer a community of support led by users, so you can cross reference any challenges you're having. We offer schematic reviews, layout reviews, certification help, and tele-calibration. And most importantly, we're mentioning about that device key. Silicon Labs offers what we call a custom part manufacturing service, CPMS for short. So your chips, if ordered from Silicon Lab, can leave our facility with the Hubble key securely injected. So that's one of the reasons why Silicon Labs is a great choice.   

Let's dive into the MG24 that Daniel was using. So I agree. Well, part of the brilliance of Hubble is that it's really expanding Bluetooth. And truth be told, many Bluetooth vendors are capitalizing on this wonderful solution. So it's my job to display why it's advantageous to choose a Silicon Lab solution, in fact. So the MG24 in question is a multi-protocol part. So first of all, it's led by Bluetooth, but we also have what we call our radio abstraction layer, so you can do custom protocols. This is also a 15.4 Zigbee Thread Matter part. So, I know we're focused on Bluetooth, of course.   

That's what the Hubble is built upon. But the MG24 does quite a bit more. So that's part of the leading reason why we've piloted on the MG24. But that's not to say we haven't done other things with Hubble on the rest of our catalog. I encourage you to go check out their GitHub. There's a number of Silicon Labs part there and many more to be ported as our roadmap expands. So, part of the advantage of the MG24 for asset tracking is the small form factor. This is offered in a chip scale package. We have five by five QFN with enough GPIO to really be the SoC of your solution, the main chip with the RTOS.   

Like Daniel alluded to, the 24 comes at 20dBm out of the box. Right? You don't need an additional FEM, you need the power amplifier. It also comes in a 10dBm package, depending on where you live globally, of course. But that's one of the key advantages is our Bluetooth protocol out of the box is 20dBm. So that means you can start beaconing to a satellite out of the box. Beyond that, the part has an AI/ML accelerator, so combined with our 20-bit ADC, you can add sensors and you can deploy model training and really leverage the maximal of your application.   

So do things like anomaly detection and then transmit via Hubble. That being said, because these devices are often remote, we want to keep them tamper-proof. So we have PSA Level 3. We have secure debug, secure boot, so no level of security threat has been identified on these parts. They are secure. That being said, on the radio side, we have built our platform to be ultra low power, low sleep current, low transmit current, low sensitivity current when we're receiving things. So that's kind of a thing that's granted with Silicon Labs is best in class low power platform, as well as operating voltage range for different batteries that Daniel was talking about.   

And a key advantage of the 24, the XG24, is its 1.5 Meg flash and 256 KB RAM. So this allows you to use your current application, add Hubble with plenty of room for storing your logs of any sensor data. So it's really the one-stop shop for existing solutions, and we're thrilled that it's now intersecting Hubble. Lastly here, I'll just call out the last note before we move on. It's also our industrial grade temperature rated part. So this thing can be put everywhere I said it could be. put on tractors, it can be put in the Arctic, it can be put where you need it to be.   

So, I encourage you to explore other Silicon Labs parts, but the MG24, BT24 is really the part of choice for our Hubble intersection. So I'm seeing a lot of questions about this kit, and we will answer them, but you can see the one Daniel was using, that's our Pro Kit. So that comes with a J-Link debugger. You can trace your packets. You have a virtual COM port. You have a number of features here. Your built-in LEDs and buttons included, of course, different means of powering it. But if you wanted to start on something simpler, there's everything from Arduinos to Seeed Studio, Xiao MG24 kits.   

So a lot of our kits resemble this. We have plenty of partners building kits on our behalf, and we also own a number of form factors in this Pro Kit form and Explorer kits. So, that being said, these are our standard kits. Nothing was changed for Hubble. This is a standard Silicon Labs kit. That's truly the beauty of this Hubble solution is if you already have these or you want to procure one, you can bring up that Hubble solution as easily as Daniel demonstrated it. So I know there's questions on this, and we'll get into that.   

But I think we have just enough time. I'd like to encourage you guys to explore more. We've done other publications with Hubble. We did a case study in depth of a use case. I can point you to our developer community like I was talking about. All of Daniel's resources are hyperlinked, but you can go find their GitHub for all their stacks, and you can learn a lot more about the MG24 on our standard MG24 website and on our Bluetooth page, in fact. You'll get directed to a number of other parts. So I'm seeing a flurry of questions.   

I'm going to invite Chandana and Apoorva to rejoin us here. I'm going to pass the mic to Chandana, who will moderate while I go check some of those questions. So, thank you again, Hubble team, for joining us. Pleased to have you, and let's get chatting. No, thank you so much, Tristan, and hello everyone again. I'm so excited for all the questions that we have. Thank you again for joining us, and I would like to welcome Apoorva again on the stage for the Q&A. So thank you, Apoorva, but let's jump right into it. And the first question is for Hubble, so maybe Apoorva, you can But what is the Bluetooth output power for the terrestrial and satellite network?   

Is it also working in Europe with a lower output power? Yeah. Awesome question, and we've got some guidance on our technical documentation site, docs.hubble.com, around transmission guidance for both networks. But to quickly answer it, there's no output power requirement for the terrestrial network, though the output power will impact your performance on the network. So higher output powers, more frequent beaconing, will increase the likelihood that you hit one of our access points or gateways and thus receive your data back. So we make some recommendations based on the use case, but zero to 20, anything in between works on the terrestrial side.   

For our satellite network, as Daniel mentioned today, the current six satellites that are on orbit require a 20dBm output power to reach the satellites. But the generation of satellites with a kind of much more sensitive receiver that launch next year, can collect transmissions anywhere from 4dBm output power. So for those European customers who are conscious of sort of output power limitations, terrestrial network is fair game today. Start testing with our CubeSats outside of Europe so that you can work with the protocol and understand the SDK. But by the time our next-gen satellites launch, you should be good to go anywhere from 4dBm to 20.   

Okay. Thank you so much. The next question is also for Hubble, and Daniel, maybe you can take this one. But, what is the timeline for the satellite network to reach at least parity with the terrestrial network? Yeah, and feel free to jump in on this one, Apoorva, as well. I think the question I may have seen, it was a timeline around data latency, if that's in the question, Chandana. Question which is very similar, yes. Yeah. So right now we have six satellites, as Apoorva mentioned. So, physics limits the number of transmission opportunities you're going to get in a 24-hour period, versus terrestrial has very strong coverage in population-dense areas and kind of suburban areas as well.   

So the question kind of comes down to in what environment are you deploying devices and you need your data to come through. Ultimately, as we build out our constellation, what's called the revisit rate for satellites, that's actually constant, but as we add more satellites, we'll have more opportunities to transmit. So over time, we'll get to a place where you more or less will always have a satellite overhead to receive your transmission. That may take a few years to build out, though. And there's always going to be the data downlink question to think through. We're looking at a few solutions to tighten that up and reduce the latency, so it's a lot closer to parity with terrestrial, on the order of a few years.   

So I'd say to go one step deeper there, it's thinking about the devices you want to deploy and asking is terrestrial a better fit right now versus satellite, and over time, building devices that beacon on both. Oh, that is very helpful. Just to add there, based on our current launch plans, we'll have our full 60 satellite constellation on orbit by the end of 2029. So that's when you can expect this sort of parity between visibility, revisit rate of terrestrial and satellite together. And I think based on some of the questions I'm seeing in the chat here, to Daniel's point, there are some use cases that are best suited for one network versus another.   

And then other kind of global solutions that move from populated areas into more rural environments, over the ocean perhaps, that would actually benefit from having both networks. And so we always see that kind of optionality being available and customers can kind of tailor the solution to their use case. Perfect. That was going to be my follow-up, so thank you, Apoorva. And then the next question that I have, Tristan, maybe you can answer this. Somebody says that, "For the terrestrial network, I assume here mobile phones are acting as a gateway. Is there an official application to be installed?" I have it on my phone, but I'll let Hubble answer that.   

But I think absolutely yes. I'll let Hubble answer, but yes. Go ahead, Hubble team, please. Yeah, happy to jump in here. So really, the beauty of this terrestrial network is that you don't actually have to install anything for things to work. It's today a network of over 100 million access points and scanners. Some of those are specific smartphone applications. Some of these are telematics devices in trucks and fleets, just embedded gateways, access points in warehouses and buildings like the Hubble HQ. We actually distribute a gateway SDK, also open sourced, that allows any Bluetooth radio capable of scanning for Bluetooth to turn into one of these scanners.   

But that said, in order to kind of help with early onboarding, validation of the advertisement packet and everything, we do have our own mobile app called the Hubble Connect app, supported on iOS and Android. And you can use that as kind of a quick validation tool. It's actually using our mobile scanning SDK or our gateway SDK to scan for the Hubble advertisements, send it to the Hubble backend for decryption, and kind of follows the same flow that all 100 million other scanners do as well. Very cool. Thank you. Another question, and I'll just keep this open to whoever wants to answer this, but we also have a device that uses its own BLE protocol.   

Is it possible to add it to your base? Yeah, we're definitely seeing that. So a lot of our existing customers are coming to us first, then we're directing them to Hubble. So absolutely, we've had everything from Wirepas to everything in between. I understand it's a matter of time slicing or sharing your application bandwidth, but that's the beauty of the ZephyrRTOS. So absolutely yes, I'll let Hubble expand on that. But using the same radio and the MG24, multiple protocols within your application are possible. Can talk about concurrency and coexistence, so to speak. But I'm going to say yes, then I'll pass to Hubble to expand more technically.   

But yes. Yeah, I think that's kind of one of the things that we have tried to work really hard on the SDK side is to keep things really lean in terms of the terrestrial SDK and the satellite SDK components, so that the application that you have today can sort of continue to run as it was before. Maybe there's another network that you're broadcasting to, something local with local infrastructure. That should continue to go on, but you can, in addition to that, begin and broadcast in our protocols to our network to get just enhanced visibility and coverage.   

But to Tristan's point about concurrence, it does mean that you're kind of interleaving two different protocols or advertisement packets on the same radio. So would need to dig into kind of the specifics of your application. Can the application, is there enough space to support sort of broadcasting in your protocol to your network, versus the Hubble one? Okay, perfect. Thank you. Another question that we have, and I think this is for Hubble as well, how frequently can the 13-byte payload be sent to satellite and to terrestrial networks? Is that primarily limited by power considerations? And how long will the satellite be in range for a static location?   

And I can repeat the parts if needed, but... No, really good question. We get this one a lot because 13 bytes, as Daniel mentioned, there are a few different sensor readings you can send out, SOS messages, small texts, but it is just 13 bytes. And so one of the things that we don't do at Hubble is charge or throttle on the amount of data you send through. We want you to be able to send as much data through as is necessary for your application. So there's no sort of block on the number of times you can transmit that 13 byte size payload, and you can switch it, right?   

It can be two different sensor readings that you're switching between when you transmit each time. Now, that said, it does depend on obviously how long you're in proximity to one of our terrestrial gateways or how long a satellite is overhead to receive that data. On average, a satellite pass lasts from three to five minutes, depending on where you are geographically. That Pass Explorer tool that Daniel showed in our dashboard will actually tell you specific to where you are, how long is that satellite going to be overhead. That can help you kind of do the math on how much data you can send through in total.   

And one other note here, the transmissions to satellite, I think I saw a question in here about how long that actually lasts. It's a 400-millisecond burst of data for that full 13-byte payload, and you can send multiple of those, as you can imagine, in that three to five minute pass window. Oh, awesome. Thank you. Another question I have is, who owns the terrestrial gateways? Yeah, great question. Our terrestrial network is an aggregated network of scanners. We work with many different partners that are anywhere from those kind of more industrial IoT gateways at remote construction sites, to companies that have large fleet management kind of applications where they've got telematics devices and trucks and fleets all around the world, to smartphone apps.   

So what we do with these partners is broker these partnership agreements that enable their devices to scan for the Hubbell Bluetooth advertisement packet structure and turn into some of our scanners. We actually see that some of our own customers who are onboarding their end devices to the platform, maybe they had a network of 100,000 of their own gateways. That's how we've seen some of the expansion of our terrestrial network is our own customers bring those gateways to the network and kind of wash their hands of the gateway network infrastructure part of the puzzle, and offload that to Hubbell, and instead just worry about those asset tracking tags or sensors that are out in the field.   

So it's a wide variety of different partnerships that have allowed us to get to over 100 million today and growing. Perfect. Thank you so much. We'll take one more question since we are running out of time, but this one is, what devices are used for the terrestrial network? And I think we answered this, but just in case we want to reiterate, please. Yeah. Happy to restate. Go for it. Oh, go ahead, Tristan, you first. Well, I was going to say just a number of Silicon Labs, right? So of course, the 20dBm is your path to satellite, but everything in the Silicon Labs BG catalog technically could adhere to the terrestrial.   

So I'll let Apoorva exactly go part by part, but if a part is missing, we can address it via apps engineering, of course, but I'll let you add some color there. But technically, any one of Silicon Labs Bluetooth parts work in terrestrial. Yeah. That's exactly right. Tristan nailed it. If it has a Bluetooth radio and it's reprogrammable to use our advertisement packet structure, it is compatible with the terrestrial network. And then for the satellite network today, we require that 20dBm output power, so that's another consideration on the device side. But starting next year, only 4dBm is required.   

So that should open up the door to many, many more radios. One other thing for consideration is that maybe the chip itself doesn't have that required output power, but certainly with a PA, you can get there. So, lots of options there. One last- Yeah. Expanding on that, we have 0dBm, 4dBm, 6dBm, 8dBm, 14dBm, so it'll be there. Thank you so much, Tristan, Apoorva, and Daniel, for joining, and thank you so much everyone for joining us. We always appreciate the support, and we have so many more amazing tech talks lined up for you as well. So please take a look, please register, and we will see you all next time.