bluetooth 5 & thread

An interview with Pär Håkansson of Nordic Semiconductor

All about Bluetooth 5 and Thread for the embedded engineer! Terry interviews Pär Håkansson, Product Marketing Manager at Nordic Semiconductor, to find out all about this new technology Serious is incorporating in the upcoming SCM318 Comms/Control Module.

Speaker: Terry West  Guest: Pär Håkansson of Nordic Semiconductor

read podcast TRANSCRIPT:

[00:00:01] - Terry West, Serious Integrated
I'm sitting here, at least virtually over the phone, with Pär Håkansson, Product Marketing Manager at Nordic Semiconductor.

And I asked Par to sit down with me today and talk about Bluetooth and Thread and Nordic is the world leader in these technologies. We've had a long relationship with Nordic; on our SCM208 products and our new SCM 318 product.

Bluetooth and Thread are just fascinating technologies. Personally, I believe that they're going to have a huge impact on the industrial, medical, and commercial marketplaces.

Par, maybe you could start off by just giving us an overview of for the Embedded Engineer and the Embedded Engineering Manager. Especially those who may think of bluetooth (and may not know what threat is) as a consumer technology. Can you explain Bluetooth and thread? what they are and how they relate to the embedded industrial industry? So let's start with with threat.

What the heck is Thread?

[00:01:10] - Pär Håkansson, Nordic Semiconductor
Thread is a networking standard. It's a fairly new standard. It was sort of formed it was around five years ago. Originally, the founders were the leader was Nest and Google. It's a mesh networking technology and it's IP based; IPv6. It's a mesh network that the carriers IPv6 traffic.

So what is a Mesh networks? A mesh network is where different nodes relay the traffic between them. So this is, from our perspective, a very interesting technology. It's very good from a technology standpoint because a lot of people that want to connect things to the cloud can have sort of IP in your local network. It makes it simpler, because you don't need maybe such complicated translations between the different things. Because they basically speak the same language as the cloud service.

[00:02:29] - Terry 
If you're talking about Thread as a mesh network, that's kind of like the z-wave stuff we see at home with our switches and all the automated Alexa-type things where we've connected them all together. That's a mesh network too. So, you're talking about a wireless mesh network.

Zigbee is old and has a lot of overhead. Is Thread lighter? And how does it relate to Bluetooth?

[00:03:01] - Pär
Thread and Zigbee are somehow similiar, I would say, it's a mesh technology. The major difference is that Thread is IP based. It doesn't specify the application layer. So it specifies the networking layer and so on. So it's similar to to Wi-Fi. Wi-Fi is typically run Http on top or FTP or something else. And Thread has the same sort of philosophy. So it doesn't specify on top, so on top you can run CoAP or MQTT; and there are other application layers you can use that on top of this because but it's IP.

So fundamentally, if you talk to a Thread device or if you talk to a Wi-Fi devices, it's from the club's perspective, you don't need to know that. Because it's an IP address from the same application layer.

[00:04:07] - Terry 
You could actually have an FTP server running on all your different embedded devices. And any device on that Mesh network could read and write files off of the other devices, for instance?

[00:04:22] - Pär
Yes. This is mainly for a low-power network with small throughput (and so on). But yeah, something like that you could do.

[00:04:30] - Terry 
So it's the equivalent of having an ethernet connection between all your devices without having the connection. And the Mesh networking element means that you get a lot better coverage from the wireless. Just because it hops between devices. If one device goes down it, can hop through a different device, and so on.

Now you say it was developed by Google and by Nest. How does this relate to Bluetooth, because I know you guys sell this nRF52 chipset and you've got the new one, the nRF52840, that has a ton of memory and processing (a ARM Cortex-M4F Processor on there). And I heard that you have a Thread stack for that processor, for that Bluetooth subsystem. Help us walk through, and maybe clarify my language here. How does Thread relate to the NR52 chipset and the modules that we put on our on our boards? How would a customer light up Thread on one of our boards, for instance, inside that module?

[00:05:38] - Pär
The new device that you have on your board is called nRF52840. It has a multi-protocol radio inside. So it can run both Thread and Bluetooth; and you can run it concurrently. There are some used cases where you want to have these big IP networks, but you also want to connect your phone via Bluetooth to do you do some configuration, upgrade, or to interface with the products. Some customers use this mesh, this Thread mesh, as the backbone network, and then, maybe use the beacon from the Bluetooth technology. The chip that we have in your SCM318 product can run both Bluetooth and the Bluetooth 5 with all all the features that you can get in Bluetooth 5. And it can run Thread; and it can do it concurrently.

[00:06:42] - Terry 
Is that normal? Are all Bluetooth chipsets also able to run Thread? Or is this something unique to the nRF52840?

[00:06:52] - Pär 
Not all of them can. There are a few chipsets on the market that that can do that. We have tried to be stay ahead of the game. And this is where the market is going; that you have this multi-protocol and maybe you want to talk to some legacy network as well. Yeah, lot of these devices now integrate more and more of the radio functionality in the device.

[00:07:23] - Terry 
The nRF52840, just like the smaller chip the NRA 52 family that we had on our prior comms and control module SCM208, they both support NFC Tag. Can you just help me understand a little bit how that fits in this picture with your chipset?

[00:07:44] - Pär 
Yes, we have NFC Tag type 2 and 4 on our device. So what we did (quite many years ago when we started assigning or writing the specification for the NRF52 family) we had an idea of how people should commission their devices into the network. So NFC is a really nice and secure way of doing that; where you touch to pair. And when we released this chip around three years ago, that there were was real support for the phone. It was an Android, but now it's also IOS; and Apple has opened up their NFC. So the idea is to use it, mainly, to commission devices, pair devices, and so on. You take it, take your phone ( or whatever you have) with an NFC reader and then tap on this IoT device you are creating to pair them; to make it easy to use. Ease of use is why we have it.

[00:08:52] - Terry 
And that's why we have Bluetooth to pair without having to type in all the codes and search for the device (all that kind of complex thing)?

[00:08:59] - Pär 
Yes exactly.

[00:09:00] - Terry
OK, so let me back up here. Because I'm mapping our SCM208, and now the SCM318 which has BMD340 Rigado, pre certified module. That includes:


  • your amazing new nRF52840 chipset,
  • we expose a connector to put that NFC antenna on,
  • there's a built in chip antenna for the Bluetooth Thread.

So here I've got my SCM318, and I want to walk through how a customer might use that in some sort of equipment; lets say that would be in the entranceway of food service company. A retail food chain in the fast food industry. You walk in and maybe you want to interact with a kiosk or any sort of device. You would first take your iOS or Android phone and you would tap on the front in NFC mode. And that would then, if I've got this straight, it would connect with the NFC Tag A Capability of your chipset. All of a sudden the Bluetooth would be paired.

Now I'm talking Bluetooth 5 between my phone and the module. I could configure the module. I could talk to the device, the machine, through my phone. Now at the same time, I could have many of these machines/devices, whether they're a tabletop little kiosks on tables in the restaurant or lockers in the restaurant, or whatever it is.

And all those could be talking together at the same time my Bluetooth is talking from my phone to the device. Those devices could be then talking amongst each other using IPv6 over Thread.

Then, somehow one of those devices might have a gateway out to the corporate network for the restaurant chain, or to the cloud, or whatever it is through Ethernet, Wi-Fi, or 4G.

So, you're seeing Bluetooth as the way that the phone or the tablet interacts with the device. Whether it's little IoT device or something more significant, like our commercial, industrial machine or medical device. The phone interacts, pairs, by using the Tag A; talks using the Bluetooth; and then those devices talk amongst themselves with Thread; and then somehow those devices are are probably connected somewhere using Ethernet or 4G to a cloud or corporate network.

Have I got that straight?

[00:11:31] - Pär 
Yeah, that's yeah that's one use case and absolutely. That's something we see our customers doing today.

Just going back a little bit to the Thread versus Bluetooth conversation. I just want to mention that Thread is IP. If you believe in the power of IP and that the Internet of Things should be similar to the Internet with IP traffic and so on. That's the way to do it.

But it is, of course, also possible to have Bluetooth to talk to between the different devices. For example, with our device and our stack, if you have one device it can talk to 20 devices at the same time. So it supports 20 different devices. You you can create a star network, or something like that, with 20 devices where you have one central device (connected through the Internet via 4G or ethernet or something) and it can talk to 20 different other, peripheral devices.

[00:12:41] - Terry 
So let's say I'm a manufacturer of, let's say, kitchen equipment for the industrial kitchen, restaurant equipment and all that stuff is getting connected. I could designate one of the nodes on my oven is the center of the universe or I could create a hub box and the hub box would be the center of the Star. It could talk Bluetooth to up to 20 different devices: the oven, the chiller, the warmers. The thermostats that are sitting inside the tray warmers for food safety, all the sensors, and actuators could all be done in a star topology using Bluetooth. Or I could set up a Thread network and have them all interconnected with IPv6. Either or? Is that what we're saying?

[00:13:26] - Pär
Yeah, that's what I'm saying.

[00:13:29] - Terry 
So that's fascinating, because I do think that there are companies out there that are potentially your customers, and my customers, that want to penetrate certain environments. Whether devices on a manufacturing line or smart building control system where they want to run everything that's in a conference room, everything that's in a building - all the sensors, actuators, blinds, and lighting. There would be value in creating a Thread or a Bluetooth topology, where if the end customer bought their lights and blinds or their ovens and chillers all from the same brand they would all talk together and be coordinated.

Both of those scenarios you talked about, with Thread as well as with Bluetooth 5, in a Star topology is that, generally one of the biggest values is that, there's an uplink somewhere. Whether it's to a corporate network or the cloud - there's an inevitability of getting these things connected to the cloud at some point. But you don't want to each one of those devices to have their own uplink, you want to manage a single uplink and then everybody gets to leverage it.

I guess the value of Thread being IPv 6 is that if your software that's written on the device side is meant to talk to the cloud, and it just happens to go out, it's going to be IP based. Whether MQTT, the CoAP, IoT protocols, custom TCP IP protocols, or even our SHIPBridge protocol (that we use for upgrades and moving data around with our boards). Whatever those protocols, are as long as we're on IPv6, or IP, you don't really know on the device whether you're talking through the mesh network or you're talking directly to a cloud. It's basically routed for you automatically. Is that correct?

[00:15:19] - Pär 

[00:15:20] - Terry 
So that certainly simplifies your software effort because you don't have to care whether the device that you're writing for is directly connected to the corporate network, or the cloud, or it's through a Thread network. You just write it the same way. That seems like a big advantage with a software perspective.

[00:15:41] - Pär
Yeah, I agree. Especially in Bluetooth, you typically have a gateway. In Thread, there is what is called a border router. So it's only routing IP traffic. Having IP traffic enables end to end security from cloud all the way to the to the node. Whereas some other technologies, you need to somehow translate that to IP traffic. Somewhere you need to check what type of traffic it is and then, write to route it.

[00:16:14] - Terry
Oh.... that's interesting point. Because the you know the software on our SCM318 has the Segger TCP IP stack built into it. It also has all the security elements like TLS1.2 and this certified crypto. By using TCP IP, it doesn't really matter all the stuff that happens in between. You get this end-to-end, secure connection between the application that's on the embedded device and the cloud, or even another device on the network. It's you know an encrypted pipe at that point, as opposed to having to lock down every little thing all the way along the way. That certainly has value as we look at hackers. Even devices or machines in the retail environment where the last thing you want is people learning how to hack into your your data traffic and order free French fries, or whatever it is that they would want to do.

Obviously Thread is relatively new, brewing for a long time, and has some very interesting applications for industrial, medical, and commercial device manufacturers and engineers. Tell me what else is is really cool and new related to the nRF52 series? And where you think that could apply to people who aren't building the latest Fitbit, but are building a device for the industrial, embedded, medical or commercial -type space.

[00:17:51] - Pär 
I want to highlight the Bluetooth 5. It's a it's really where Bluetooth is taking more of a step into the industrial world from my perspective.

[00:18:03] - Terry 
Oh, really? I think of Bluetooth 5 as a consumer technology. But, you really think it's a big deal for industrial?

[00:18:11] - Pär 
Yeah I think so. They have done a lot to to improve the robustness of Bluetooth. There is something called the long-range mode. Basically you're reducing the data rate and get a much longer range or a more robust link. You could you could say as well, right? So if you take our kits with nRF52840 and do line of sight measurements with the long range - you get 1.6 kilometres.

[00:18:45] - Terry 
Holy cow! One point six kilometres with Bluetooth 5!

[00:18:48] - Pär 
Yes, line of sight. Yeah.

[00:18:53] - Terry
Wow, OK. Now, that's not going to work too well with my little SCM318 because it has that built in antenna. The little chip antenna, right? But if I were to build a special edition for a customer with an external UFL connector and they put a special antenna, they would be able to get that range. Am I right? What do you need from an antenna perspective to be able to go that far?

[00:19:15] - Pär
No, We use PCB-integrated antenna's, so I don't think you need anything special. Obviously, antenna has something to do with physical size. So with the smaller the antenna, it's usually it's a bit limited. But since you're using modules from a more established, older company like Rigado that rigourous puts a lot of energy into making a very good antenna design, I'm pretty sure you'd get pretty far. You should try it.

[00:19:42] - Terry
Oh, we should try and get two of our SCM318s and put them you know a kilometer apart (or here in America we might put them roughly on a half mile apart) and see if they can talk to each other. That's so actually that's interesting because we were looking at a long range application. One application for our SCM 318 would be a landscape lighting and irrigation controller for commercial or even for home applications. Because we're all very frustrated especially here in Arizona, where Serious is based. We all have landscape lighting and drip irrigation to preserve water. And there are all these different zones, because we get to control it for the entire outside landscape. Some of that technology is absolutely ancient. When discussing that application, we looked at our SCM318 and thought, "you could just add a few valve controllers, and some switches, and this thing would be Wi-Fi connected irrigation controller extraordinaire.

But the problem there is how do you get it back and connect it to the cloud. A lot of people don't have Wi-Fi that would reach all the way to their irrigation controller. Potentially, you could run Bluetooth 5 and use that with 500 foot or longer easily range as the pipe between the inside of a house as the hub and various devices connected. In a in a commercial landscape lighting environment you could talk to it with a hub about a kilometer away. That's phenomenal.

[00:21:13] - Pär 
Yes. Basically, if you run Bluetooth 5 on our latest chip set, you get around four times the range compared to what you've got with our previous generation and it supports long-range use.

[00:21:27] - Terry 
Definitely some interesting usage models with that. What else is Bluetooth 5 bring to the table that are that engineer might care about?

[00:21:42] - Pär
It's also increases throughput. So it also supports two megabits per second now. So obviously you don't get that long range, but its dynamically adjusting depending on link budget and so on. But you can also get two megabits per second, so that enables some use cases where you can send more data in a much shorter range. But still if you can get quite high throughput between two devices (maybe up to one point three megabits per second), effective throughput.

That could open up new use cases which require more throughput. It could reduce battery life since you are basically transmitting twice the amount of data while consuming the same energy.

[00:22:40] - Terry
Interesting. How does that compare with bandwidth of Thread?

[00:22:44] - Pär
Thread is based on a on a different, physical layer. Based on this IEEE 802.15.4, over the air it's 250 kilobits per second. In a mesh network, you will get much lower throughput than.

[00:23:10] - Terry
Okay. So the advantage of doing your star topology or your Bluetooth type connection (using the same chipset right this is the same chipset same module concurrent capabilities) is the following:

If I were to use Bluetooth 5 as the methodology to move my data, I'd get to 2 megabits per second (or very close to that) but then it's not Mesh-networked and it's not IP.

If I use Thread, I get TCP IP connectivity, but much lower bandwidth than a mesh network capability.

So there are some tradeoffs between how you think about the architecture.

[00:23:43] - Pär
Yes absolutely.

Since maybe some of your some people have heard - Bluetooth is also moving into Mesh-type networking technology as well. To make the landscape even more complicated. It's a non-IP based and the first one that's coming out now is very tailored toward lighting actually. Bluetooth takes (as we were discussing before) what we call the full-stack approach. So you defined everything from the bottom to the top so. It defines how a lightbulb work and a light switch should work and so on.

Whereas in Thread, IP based, the application layer is not defining the standard. So you either define it yourself or you use some other IP-based application layer.

[00:24:47] - Terry 
So do you see Bluetooth, as it evolves with mesh take capabilities and Thread, kind of competing with the whole z-wave/zig-bee-type approach. Do you see it creating, in some ways, more fragmentation in the marketplace? Or do you think it's going to zigbee or z-wave, or how do you see that evolving?

[00:25:14] - Pär
That's a a good question. I guess only the future will tell. They are a lot of standards trying to solve a lot of similar problems. Yes, I would say so. Thread, Bluetooth, and Zigbee are all open standards whereas z-wave is more controlled by one company.

[00:25:36] - Terry
This is fascinating! We're going to have to wrap up here. I certainly appreciate your time Par!

I'd love to have you back again to talk more about usage models on Thread and how customers should think about Thread and Bluetooth 5 in embedded devices.

Bluetooth 5 and Thread are both supported in the nRF52 series and on that new SCM318 we have. Which is kind of one of the reasons we chose your chipset as, obviously, one of the leading, if not the leading, chipset in the industry.

With our short time together, what I'm taking away from our chat is this promise of an enormous value proposition for not just the commercial and consumer industry, but also for the industrial and embedded industry. The value of networking devices together very easily with lightweight things like Thread or long range things like Bluetooth 5, or even the future of Bluetooth 5 mesh networking, and adding a ton of value into embedded devices by having this capability. Whether it's lit up on day one or or is latent and can be turned on later.

So I absolutely appreciate the time you spent with me today sharing your expertise and your usage model. Thank you so much.

[00:27:03] - Pär
You are welcome. A was a pleasure to talk with you Terry, Thank you.

[00:27:06] - Terry
Thank you.

Return to Podcast Main Page

Read more insights from Pär Håkansson at Nordic Semiconductor's Get Connected Blog


embedded technology blog

Visit Blog



captain's log embedded podcast


The challenges of HMI and IoT can be overwhelming. Listen weekly to our Captain – Terry West, CEO – on industry trends he sees and implications for the embedded systems designer. 

You'll find practical thought leadership conversations covering all facets of embedded technology, human machine interface evolution, architectural challenges, IoT readiness, and much more.


Podcast General App Image-100.jpg

You can now stream the Captain's Log on Podbean, iTunes and Google Play Music!

Available on Podbean.jpg


Listen on Google Play Music