Yeah. This is Chris Fright, he's going to talk to us. Fried, Fried. Fried. Yeah. At least I get to learn how to pronounce his name. He's going to talk to us about the Internet of Things and afterwards I'm sure Mr. Internet of Toilets will want to talk to us.

He's looking for work. Nice. Okay. Yeah. So I'm here, I was sent over by my company, MMB Networks. We deal mainly with Zigbee, also everything else IEEE 802.15.4. So I'll just go ahead.

So I'm actually, I've done some work and I was a little bit surprised to find that Bastian was here and I basically implemented a whole bunch of 802.15.4 stuff and then I realized that someone else had done it only a year prior and I was like, oh, okay, let me try this one.

So here's a little overview. I'm not sure how many people are familiar with 802.15.4 but I'll just give a brief overview and I'll just show some devices that are out there for consumers. This is primarily Zigbee related but, you know, stack kind of agnostic.

And then I'll just go over kind of my implementation details. So it's been, I'll just say this right now, the last time I dealt with kidney radio was probably in 2000. So it's typically used in sort of home, well nowadays it's home automation, that's the primary focus. It used to be smart energy and my company was involved in a lot of this stuff.

So we have a lot of clients who we bring to market that have new 802.15.4 ideas and we're partnered with all of the silicon vendors and stuff like that. I've got a couple of modules in case anyone wants to see them.

I wanted to bring a couple to give away but unfortunately I couldn't order them in time. So, sorry, but they're relatively cheap. So in any case, so I'll primarily be focusing on the ISM band for Zigbee. So that's the, I don't know if you can see it, the OQPSK right here, 2450 direct sequence spread spectrum.

There's also the ultra-wideband now which I find really interesting because I did some ultra-wideband research as well. But I haven't gotten my hands on that stuff yet.

As you can see there are channels 11 to 26. I guess they're 5 MHz apart. I think the one on the end actually we're not supposed to use. That's just a rule of thumb because it interferes with some other medical equipment or military.

So here we'll get into the physical protocol data unit. So we've got a synchronization header which consists of a preamble which is all zeros, four octets or bytes. Then we've got the start of frame delimiter. It's one byte, 0xA7.

Minimum frame length, or sorry, maximum frame length is 127 bytes. This is kind of the odd thing. With most communication systems you have MSB communications. We just generally refer to that as network byte order. IEEE 802.15.4 is a little bit odd in that it's little-endian and least significant octet first.

So it comes into play later. In any case, we've got gray-coded differential modulation over here. So you can see that you've only got maximum phase shifts of 45 degrees. No zero crossings.

I mean zero decent components, which is great. It's more robust to multi-path. And then we've got a half-sign pulse shape over here. And then I'll talk about this bit, or sorry, symbol-to-chip converter.

So we take four bits and turn it into a series of 32 chips. The odd, or sorry, the even chips become the, let me just look at that for a second, the I in phase portion, and the odd chips become the Q.

So I don't know how many people remember block coding stuff, but this is kind of the typical characterization. So you have N, K, D. D is the minimum Hamming distance between the similar chips. I'll get back into that in a second.

So the PHY is responsible for link quality indication. And receiver energy detection. That has to do with collision avoidance and clear channel assessment. And we have the MAC. I don't think I included an example, but a really simple one is the acknowledge frame.

It's essentially, it's got a payload size of three. Yeah, I didn't have a full example, but let's see. This is acknowledgement request. So every packet that you send, you can actually request a challenge for. Kind of handy when you're debugging network stuff.

There is, I think the usual is 16-bit addressing, but you can actually do up to 64-bit as well. So the MAC layer, again, I used Bastian's implementation. I think it's sort of just, you know, kind of the minimum to get going.

But it's required, you're supposed to implement all of these different functions in the MAC layer. I think transmission reception is, you know, more or less the minimum. But in theory, you should also do sort of channel assessment and stuff like that.

ACK kind of delivery. So this is, I don't know if everyone's familiar with Zigbee, but it's a mesh network. So you've got a star topology. You've got kind of a regular mesh topology, and then you've got a tree topology.

You've got the coordinator. So there's usually one coordinator per network. And then you've got routers. And then you've got the device, the end devices. End devices usually are battery-powered. You'll often find switches that are battery-powered that you can just stick onto a wall. They actually now have switches that are mechanically actuated that generate the electricity required to run,

just by pushing the button itself, which is pretty, it's a pretty amazing feat. Most of these little devices are running a Cortex-M0. I think these ones are a Cortex-M3. There aren't yet Cortex-M4, but it's pretty fun to play with these little arms.

Okay, so here's just a couple of examples. I'm not affiliated with Nest at all, but my company helped to get a few of these guys off the ground. Here you have, I think, so there's eye control. There's the Zen thermostat, which was recently pretty successful.

We've done a lot of work with Marvell. Safe plug. These guys, Central Light. I've got a couple of these devices with me as well. Then, Somfy, Blinds, and Quick Set Door Lock. Here's the Thread sort of re-implementation, or whatever you want to call it.

So, Thread, I don't know if everyone knows, Thread is 6LoWPAN-based. Although we focus primarily on Zigbee, we're also doing a lot of work with 6LoWPAN, and even Apple's IO kit. There have been a lot of new things this year in home automation. So, I guess the question I'm trying to answer is, why would you want to use an open source 802.15.4 stack?

Why would you want to use a software-defined radio to do this stuff? I guess for me, because I've worked with a lot of these vendors, each vendor has their own software stack.

You don't license it, but you're pretty much fixed to using theirs when you buy their chip and use it in your application. So, and then I guess you're kind of tied to their, whatever bugs they have in their system, whatever security issues they have.

I'm not saying that there's a lot of bugs, but it's just nice to have some flexibility, especially if you want to do some experimentation with different standards. So, 6LoWPAN, for example, I'd like to do a little bit more work with that.

So yeah, if you're doing security research, it definitely helps to be able to inject noise, perhaps corrupt some packets, eavesdrop and whatnot. So, I don't know if anyone here has heard of Freak Zed. I think this guy is from Tokyo, but he developed this open source Zigbee stack.

I don't, it's not certified, obviously, because you have to be a member and all that stuff, but it's out there. And I just picked it up a couple of weeks ago and, you know, added AutoTools support and made it into a shared

library and reduced the dependency on Kon-Tiki and stuff like that, because prior it used to run in a Kon-Tiki simulator. So, and before that, it was kind of locked into the simulator. And what I did is I just opened up a UDP port so that you could send and receive packets via UDP.

And of course, GNU Radio has a pretty great kind of UDP block, actually. Bastion, I think, might have done that, where you put the MAC layer to the UDP. The MAC layer and the messaging and all that stuff.

So yeah, this is the hardware I'm working with. This little guy, it's kind of naked at the moment, but this is a rapid connect USB module. And this one I've actually got programmed to do a node test where you can basically tell it

to send out a tone or you can tell it to send out a series of random actual packets. 802.15.4 packets that are not corrupt and will actually be accepted. So this was fairly useful in putting together the whole receiver architecture and everything.

And then I was able to just connect with the UDP, say some hello world messages and other random things like that, some acknowledges, and pick up the communication. I didn't get so far as to create a really simple app where my computer would

be kind of a Zigbee end device and a router at the same time or a coordinator. But that was kind of the end goal. In any case, I'll show you a little bit about the FreakZ test app structure. It's pretty straightforward.

So yeah, here's the FreakZ. It's BSD licensed. Of course, if you want to do anything other than research, if you want to do a commercial product, if you want to do a Zigbee, then you have to pay the royalties, become a member, et cetera. But of course, you could use 6LOPAN and then you can just get going like that.

Let's see what else. Oh, yeah. OK, so here we are with the IEEE 802.15.4 block. I think this originated in UCLA. I don't know much about Seagram, but I feel like it was gone suddenly because there were all these references to it and then suddenly they're gone.

I think Bastian picked it up again somehow. I think there are a few people that are still working with it. So I was lucky enough to find his repository, cloned it. I just took the Rhyme part out of the block, fixed a couple of smaller issues that I have.

So let's see. Yeah, so this is essentially the Rhyme transceiver minus the Rhyme block. I've essentially circumvented the network layer here and I've just gone straight to PDU sockets.

It was quite simple. This is unmodified. And then here we are with this is the receiver. So I'll just quickly jump out to FreqZ.

Hopefully I have that open. So this was actually if you've ever worked with Zigbee, often you'll just find basically a test app. And what a lot of stacks tend to do is they tend to just provide you these stubs that you fill in, which is somewhat OK.

But I like to improve this interface a little bit. In any case, it's actually pretty straightforward to use their command structure here. I was able to send out messages and whatnot.

Let's see. Ideally, I think I would like to, with the shared library, have kind of a registration function where you actually register according to an interface or a structure that has a bunch of function pointers. I think that's a little bit more flexible.

So as I said, I'm sort of getting back into give me a radio. This is what I got when I finished. So this was me with my B200 and just two antennas right there. And I just had kind of a loopback test going.

So it's unfortunate this isn't a video, but what I noticed here is that I could actually see the group delay happening. And so I knew that there was definitely a synchronization issue. And I wasn't quite able to decode all the packets from this.

I was getting a lot of errors. And then I realized, yeah, for sure, I definitely need to get a clock recovery block in there because normally this would be pretty nice to have a nice QPSK constellation. Yeah? Okay. Yeah. Well, I mean, I think it's actually pretty great that I'm here because I'm almost a newcomer to GNU Radio again.

So if anyone has any pointers, I'm more than happy to hear them. So yeah, and then we just kind of decoded the hello world message down here, which is pretty nice. So a couple of things that I noticed from the 802.15.4 block was that the shift register internally was encoded the wrong direction.

So it worked really well with the Rime simulation block or whatever. But instead of having chip 0 in the LSB, it ended up sitting in the MFB after 32.

So it's kind of, I don't know, it's kind of weird. It took me a little bit of time to figure that out. I think the threshold was set to 10. And one thing I kind of remember was that you should be able to theoretically detect up to, sorry, deis rate here, 11 errors.

And I guess just kind of my interpretation of the receiver architecture is that setting the threshold to 10 and just passing it off to the CRT was kind of like best effort to recover the packet even with errors, I suppose, right?

So I would probably just insert a check to see if it's if the number of error bits were less than five. And then, you know, almost factually that you've got the correct packet.

So, yeah, I still need some frequency compensation, I think. But it was I think I probably spent about two to three weeks before the presentation. So I actually felt that it was fairly easy to pick up your mod tool and just get going.

I still have a little, you know, I guess just some feedback in general, but I'd even probably be willing to write some documentation once I understood a little bit more about kind of the PDU and message passing stuff. But it was a little bit unclear.

I found it quite useful, though. And then I guess because I originally tried to do this as a stream in my first implementation, which is a little bit tricky, right? Because with packets, you don't always have constant bits coming out. You end up having to stall or whatnot. So there's a setting for the block where you can set the max and output items and the min and output items.

So in this case, if you've got 32 bits coming out and four bits coming in, your min would be 32. And your max, I think I had set it to 127 because that was the max for the packet size or 120 or something.

But what I found was that it was going from 2048 all the way down past 32 and it wouldn't stop at 32. So there would just be I guess the output buffer wasn't allocated.

As I would expect. So it might not be a bug, but I kind of felt like it wasn't really respecting that min and output items. That should be min. In any case, I don't know if anyone has any questions. Feel free. I just want to say thanks to everybody, though.

Matt Edis for answering some USRP initial questions. Phil, again. Marcus Muller on the list was really helpful. Obviously, Thomas Schmidt and Bastian for their work initially. And I guess this Hongbo Zhang or I can't remember what he goes by, but he wrote the Freaks Out stack.

And obviously that's quite useful. Yeah. And obviously all the new radio authors and contributors. So thank you. Does anyone have any questions?

You mean in the industry in general? Oh, really? Oh, that's really interesting.

Oh, cool. Yeah. Yeah, neither have I, honestly. But I think there's a lot of interest in the ultra-wideband.

Because the preamble is so long that you actually get a really good channel estimation by the time you receive the first packet. I mean, CSS is quite interesting, too. Were you thinking about Zigbee or 6lopen?

Okay. I don't know. It's the same filer. Totally the same. Yeah, this is just network and above. So yeah, I would highly suggest using this Freaks Out thing because it seems really easy to use.

And you should be able to just kind of drop in a sample application whenever. What I wanted to do with my laptop was just have my laptop as a Zigbee app with an on-off. So that I could use, we have some pretty interesting desktop software. And then you just kind of go through the desktop through this.

You can toggle the on-off. So I was just going to get it to play a song or something like that, you know. But probably a couple more weeks and then I'll be all done. I'd be really interested to see the CSS stuff. Thanks.

Most of the vendors that I've seen have stuck actually very well to the specification. Very few actually diverged from that. I'll just go a little bit out and say that Ember is a very special provider.

So you're familiar with them? Any others? Okay. All right. Thanks a lot.