Uncovering the Hidden Use Cases of Narrowband Cellular for the IoT - On Demand Webinar

Speaker: Rob Lauer - Director of Developer Relations 00:00

Hey everybody. I think we're ready to get rolling here. Now welcome to our webinar today. It should be really fun. This is all about uncovering some of these “hidden use cases” for narrowband cellular for the IoT. We are covering a wide variety of use cases and functions that themselves aren't uncommon, but you may primarily think of them more in terms of being accomplished with lower latency and/or higher bandwidth communication protocols. There are always some key advantages to using these with cellular, as we will see today. Let’s start with quick intros. My name is Rob Lauer. I'm Developer Relations Lead here at Blues Wireless, but far, far, far, far, far more importantly, today, with me are TJ Van Toll and Zach Fields. They're gonna help me by showing off some pragmatic use cases around our theme today. Now, as questions come up during the webinar, please enter them using that little Q&A panel that you have in your GoToWebinar interface. After the three of us are done chatting away, we're going to be answering as many of your questions live as we possibly can. Likewise, I want to mention, if you run into any issues at all with audio or video stops, or stuttering, what have you, have no fear. Everything you see will be available on our YouTube channel here in the coming days. You can access that at bitly/blues-youtube.

There's actually a lot of great content there already. We have past webinars, some of our featured projects have little trailers there, and we have our awesome new Blues Wireless TV segments. Shameless ask from me is that you subscribe to our channel as well in YouTube; that helps us kind of get the message out. A little more visibility out there in YouTube land, but I will say don’t rely on YouTube for everything going forward, as only attendees of this webinar today will be eligible for our giveaway. To that end, we're giving away free of charge some starter kits of your choice, either the Raspberry Pi kit, which is what I'll be using later on, or the Feather starter kit with our new microcontroller Swan, and I'll talk about Swan at the end of the webinar. These do come complete with a Notecard and the appropriate Notecarrier, so you can start prototyping your project as soon as possible. We will be reaching out to the lucky winners in the coming days. Okay, with the logistics behind us, I do want to start with this: What the heck is Blues Wireless? If you've been to one of our webinars in the past, you'll know that I do like to level set here and make sure all attendees, whether they are seasoned veterans or brand new to Blues, have at least a high level understanding of what we're up to. If you've heard this intro from me before, feel free to tune out for the next couple minutes. I'll warn you when to start listening again. For the rest of you, let me start by stating that the core mission at Blues Wireless is to make wireless IoT easy for developers and affordable for all. To that end, one of our core focuses is on securing your data from the moment it's acquired by a sensor all the way through to landing on your cloud app of choice. Also, all of our hardware solutions are low power out of the box to the tune of about eight micro amps when they're idle. We're also a very developer-focused company, so our developer experience, all of our web assets, this is all a huge priority for us. We do provide a very elegant and easy-to-use JSON-based API as well. Zooming into the hardware for a bit here. Of course, the Notecard is the core of what we provide. It is a low power cellular and GPS module measuring a tiny 30 by 35 millimeters. It does have that M.2 edge connector at the bottom there for embedding in your project. As I mentioned, the API, the way you interact with a Notecard, it's all JSON.

Now gone are the days of those archaic AT commands for managing your cellular modem. We also have SDKs for Python, Go, Arduino, C, C++, and there are Notecard models that work globally, so we use NB-IoT, LTE-M, and Cat-1 cellular standards. Now, to make it easier to use your Notecard when you're prototyping or when you're even ready to embed in a more permanent solution, we provide Notecarriers. These are development boards that allow you to snap in a Notecard using that M.2 edge connector and connect it to virtually any solution you can dream up. For instance, we have the Notecarrier AF, which includes a Feather-compatible socket. We have an A, the A model includes headers that let you hook it up to any microcontroller you want. The A and the AF also include onboard antennas.

Speaker: Rob Lauer  04:55

The B is a small form factor Notecarrier, no antennas here, but this is a very, very tiny little board, so you can supply your own external antennas. Finally, the Notecarrier Pi is a Pi HAT, so it plugs right into the top of your Raspberry Pi. This works with any Raspberry Pi-compatible single-board computer. Finally, you might be wondering how you get your data to the cloud. Well, Notehub is a thin Blues Wireless cloud service that receives data from the Notecard and in turn securely routes it to your cloud app of choice. Also, within Notehub, you can manage fleets of devices, so you can update both host microcontroller and Notecard firmware over the air. TJ is going to touch on this. Notehub is also all about securely transmitting data from both the Notecard to your cloud and vice versa, actually.

When I say secure, I mean secure as in data is transferred off the public internet via private VPN tunnels between Notecard and Notehub. Now to help visualize at a high level where Blues Wireless fits into your current IoT solution, we can start with sensors. You're probably acquiring data of any and all types from temperature, humidity, motion, gases, I don't know, it could be anything. This data is probably being processed by a host or some sort of microcontroller, single-board computer, but you really need to get that data to your cloud. That’s where the Blues Wireless Notecard is used to securely deliver data over cellular to our thin Cloud Service Notehub. Notehub then lets you route that data to your cloud of choice. So Notehub is really there to take a lot of the pain out of this secure data transfer process and even optionally optimizing data payloads, conforming the data structure to whatever structure your remote endpoint is anticipating. Again, you can route data to any big cloud, any IoT platform, like your Ubidots, your Datacake, Losant, for example, or even to your own custom RESTful endpoint. When we say any cloud, we mean any cloud.

All of this, everything you've seen so far is accessible via this developer-friendly, JSON-based API. Everything is JSON in JSON out. This applies whether you're in Arduino or Python or even experimenting with your Notecard using our web-based REPL at dev.blues.io. A common question we get about using the Notecard is around some of the more promising or obvious use cases for cellular IoT. None of these should be big surprises: you've got your asset tracking, cold chain monitoring, you've got remote monitoring, condition monitoring of virtually anything, you've got smart meters, there's plenty of smart city scenarios here. Really, anytime you want to relay data from device to cloud, whether it's as a primary means of communication, or when you're using cellular as a backup or a fallback, or if you need a more secure data solution, Notecard really has your back here.

Now as a relatively simple example of what I just covered, let's say you have a DHT-11 temperature and humidity sensor. Kind of as basic as it gets, right? You want to use the Notecard to send this data to your cloud endpoint. Well, Notecard is going to take that sensor data, and it's going to send it to Notehub along with some metadata about the request. You can see the temperature and humidity in the middle of the request there, but there's also metadata like timestamps, cell tower location, all that kind of stuff. You may not need or even want that data to end up on your cloud for whatever reason, so Notehub is there to kind of transform or optimize that data payload per your requirements and send just the data you want to your cloud. That's really a high level look at what the Notecard and Notehub provide.

Speaker: Rob Lauer  08:44

Today, we're gonna get a little more nuanced with what are called “Hidden Use Cases.” What do I mean by that? Well, I'm going to kick things off by talking about file transfers. Now we don't really often think about how we can use narrowband cellular for what are traditionally high-bandwidth tasks like transferring files, so I'm going to look at this through the lens of Python on the Raspberry Pi. Zach is then going to show us how you can use cellular in a remote-control scenario to remotely control machinery, which I think is really cool. TJ is going to talk about some firmware update strategies over cellular, which can really improve your team's velocity when it comes to managing fleets of devices in the field. So remotely updating firmware just through a few clicks really.

Speaker: Rob Lauer  09:40

Let's really kick things off here by starting to talk about file transfers. Specifically, I do mean bidirectional. I want to transfer a file from my device to a server, and then from a server back to my device. Specifically, I'm going to show taking a file on my Raspberry Pi right, I'm gonna use some Python code that's on my Pi here, and we're gonna split that file up into some chunks—into manageable chunk sizes—and you'll understand what I mean when I show off the code. We're gonna send those chunks individually to the server, and then we're gonna have the server reassemble that file. That's kind of the general workflow. Then we're gonna flip it on its head. We're going to take this file that’s on the server, we're going to chunk up that file, like we did on a Raspberry Pi, we're going to send it back to the Raspberry Pi, not directly back, and you'll see what I mean by that as well. Then using Python, we're going to reassemble that file locally. Hopefully that makes sense. Let's jump over to the demo here, then.

All right, hopefully, you can all see my VS code interface here. What I wanted to start with for the demo is to go through some of the source code that is involved on both the client side and the server side for this. Again, we're doing something that's fairly simple, right? We're transferring a file, you know, we've done this a billion times, but now we're doing it over narrowband cellular. There's other issues we’ve got to overcome with a narrowband protocol like this. In my case, I'm using Python, because I'm using a Raspberry Pi for this example. You have to trust me that to my right is a Raspberry Pi mounted on the wall with a Notecarrier Pi HAT on it and a Notecard configured to work with this in this file transfer mechanism. What I'm going to do is, let's walk through this first script. You can tell the steps here, I ordered them appropriately, or numbered them appropriately, as 1, 2, 3, and 4, and these are relative to the Raspberry Pi in this case. One outgoing means this is the script that’s going to post a file, or post the file chunks rather, to the server.

Now, let's walk through some of this code so you really understand what's going on here. I've got a file on my Raspberry Pi. In my case, it's a text file. I'm using a relatively small one, it's like 20k in size, but you can go way up if you want. I'm doing a demo here so I want it to work in a relatively reasonable amount of time. I'm going to chunk that file up; I'm gonna split that file up into 8,000-byte chunks. Why 8,000? Well, it's just a number that we've come up with internally as a very safe payload size for these file transfer situations. You can certainly experiment and go way, way, way, way, way up, or even shrink it down if you have to. I just chose 8,000 for the heck of it for this demo. My first step is going to be to Base 64 encode this binary file. I find this to be very simple, even though it does increase the size of the file itself a little bit. It's just easy for me to manipulate strings and split them up and concatenate them again on the server if it's Base 64 encoded.

Next thing needed to determine is the number of chunks we need to send. I need to know how many different payloads I'm going to send to our server, but Notehub is going to kind of help route this data for us, so the first step is to grab the length of the file. We know how long the file is, and we're going to divide that by the chunk size, and we're going to round that up. Now I know it's going to be X number of chunks are going to be sent to the server. We grab a GUID, I want to be able to uniquely identify all those chunks on the server just in case we have multiple different sources coming with a bunch of different file chunks, we need to uniquely identify those as the chunks that I'm sending. Then we get to some of the fun stuff here. On the Raspberry Pi, I'm going to initialize the Notecard, and I'm going to communicate with it over I2C. I'm going to connect Notecard to Notehub.

As I'll show you in a second, I've got a new project set up in Notehub that is going to facilitate this communication of a posted file chunk from my device to my server. You'll also notice that I'm using the fluent API provided by the Note Python library, so I'm not actually hand coding JSON here. I'm using the hub.set method from the Note Python library. You don't have to do it this way. You can, as you'll see right here, you can manually write out your JSON if you want to as well. Either way works perfectly fine. Let's pop over to my browser here quickly so you can see Notehub. This again, this is just a free project I've created in Notehub to facilitate my file transfers. In my settings, you'll see I've got this product UID; this is just a string-based identifier. It's a unique identifier to identify this project. I can, again, specify that product UID which I stored in my keys on the keys.py file over here and associate the Notecard with that project. Okay, we'll come back to Notehub in a second.

My next step after my Notecard has been initialized is to kind of wake it up to tell it, “Hey, I'm here, I'm going to need you to do something soon.” Let's do a sync with Notehub to make sure that we have an active cellular connection. My next step here is to validate that the Notecard is actually connected to Notehub before proceeding. When I'm using what we call these web APIs, when I'm using those, we need to have an active connection to Notehub for files to be transferred successfully, which seems obvious. I want to make sure; I need to double check and guarantee that I do have an active connection, and that's just what happens in this while loop. Okay, so I'm submitting this hub.status API request, and if we get a connected parameter back in the JSON response hub.status, we know that we're connected. Let me scroll down a bit. Next up, I’m just creating a list, an empty list, with some errored chunks.

The reason I'm doing this is in case there are any errors in transmission of a file chunk—I don't want those errors to disappear. I still need those files to be sent at some point, so we will populate that list in case any errors do happen. I've actually never had an error happen in a file chunk being sent, but we'll see; first time for anything. Then I have this send chunk method. This is going to send an individual file chunk, using, again, a web.post Notecard API. These are all documented on the Blues Wireless developer site at dev.blues.io. I'm going to pass this to a specific route in Notehub, and we'll get to that in a second. In that route, I’m going to actually append to the URL provided in the route, the string, so this is going to identify the actual method my .NET, my C# web API method. I'm going to pin the GUID, the unique identifier, the Note number, so which chunk am I sending, the index—other way around—Note number is the total number of Notes and the index is the actual chunk I'm sending.

The payload is just a section of that Base 64 encoded file. I'm not going to let my brain try and translate what this is doing for you, but it's describing an 8,000-byte section of the file that we're going to post, okay. Then we have a simple for loop, that's going to go through all of the file chunks that have to be sent and send them one at a time. If there's any errors returned in any of the responses, we simply add them to that error list and run through the process again until we're resolved without any errors. All right, so now back to Notehub quick to look at these routes. My first route, this is again—outgoing to my server—I simply set up a route as a proxy. It's a proxy for a device web request, rather, the only other important piece of information here, well, two of them, there's a route alias, Post File Route, that translates right here to that URL. Here's the URL I'm sending it to. On my Windows Server, I'm appending all this information. Now we get to look at our C# code. Now, the reason I'm using C# is just because I'm comfortable with C# and .NET, but I also did it because this is a server agnostic process. You can write a Java API, a Python API, a JavaScript API, whatever you want to do. It's not important for me to go through all the individual lines of code here on the C# side, but I do want you to have a decent understanding of the process of what’s going on here. Recall back—too many windows open here—recall back to this post file method we’re hitting. Well, that corresponds right here, so this action name on a web API I have set up, I’m gonna go through the steps here at a pretty high level. Step one: it just says read that binary data from the post, convert it to Base 64, and save the local file. You're probably like, Rob, this was already a Base 64 encoded file, why are you converting it back from binary? That's because Notehub actually pre-optimizes and sends it back in binary format.

Again, I kind of like to keep everything in Base 64, just because it’s easier for me to concatenate everything back together again. What I’m doing is I’m grabbing the byte array that was sent, was kind of forwarded along from Notehub, converting that back to Base 64, or encoding it back to Base 64. Then I'm just writing that file out to the local directory and then making sure to supply a Note index. Which file is it, and what's the GUID of the file so we can then later assemble it? After that file is written, then I'm going to manually check the file system to make sure, or check to see, if all the file chunks are there. It's a simple loop—probably could have done this a little more elegantly—but we're just looping through to make sure we have all of the Notes, or sorry, all of the file chunks that we're expecting. If they were, just reassemble the file. I'm doing that with a string builder, which is in C#, a very memory-efficient way of concatenating strings. We are reading the Base 64 strings, and we are decoding it back into binary, and then writing that file back out. Okay, so fairly simple.

Again, on the Python side, I'm encoding a file, splitting it up, sending those chunks one by one. On the server, I'm grabbing those chunks one by one, and I'm reassembling the file. That's really all that's going on here. I probably talked way too long about that simple process, but let's see this in action. I have here, here's my Windows VM, and I've got a Files directory here that's totally empty, so nothing up my sleeves here. I've also got a VNC connection into my Raspberry Pi, and you'll see that 1-outgoing py script as well. Let's go ahead and open up a terminal window here. Let's get this running. Let's go to documents, apps, and I think it's file transfer. Yes, and we're going to run python3 1-outgoing.py. Before I do that, notice that I have my sample.txt file here. Let's open that up so we can see what's in there.

It's actually just, it's 20k, so it's 20,000 bytes of gobbledygook. Let's just do this here. I guess I don't have to substitute this in here. I'm just gonna say “Blues Wireless Notecard” and we're going to save that. Now we can actually see on the server—just to show you that this is actually working—so run this, and let's see what happens. We are connected. I'm outputting some variables from the Notecard. We're actively connected to our Notehub with this Notecard on my Pi. Now we're posting the first payload, and while this is happening, let's head over to our VM, and sure enough, there's our first one. You can see it's eight kilobytes in size, which makes sense. Since it's a 20k document, we should see, what, three or four files, depending on the Base 64. This is the increased size of the Base 64 encoding. This’ll just take a few seconds here. Again, this is working live over cellular and everything.

When it's all said and done, I have this text document here. If I open it up, sure enough “Blues Wireless Notecard.” There it is, pretty simple. We've already, in those steps, we've transferred a file from our Raspberry Pi up to the server. Now let's redo this process and send it the other way. I'm going to do that. By doing that, I'm going to go ahead and I'm going to rename this. We'll call that sample.txt. I'm going to get rid of these files just to clean up my space a little bit here. Let’s head to VS codes, so we can look at the code quick. In my 3-outgoing.cs, this method on my server, this is going to be relative to the server. It's gonna be a file that's outgoing from the server to my Pi. Okay, so we have a variety of constants here, so again, I've got a chunk size of 8000. Here's a path to my local directory. I've specified a Notehub product UID, which I've hidden here. I've also specified a Notecard device UID. I want to make sure I'm sending it to the right device, and you can get that from your Notehub UI. Then we have a Notehub session token, so this is an API auth token. You can figure out how to grab one of those values, again, in our developer docs. I've got a send file method. What this method does is it simply zips up the file I want to send and chunks it up, splits it up again. Why am I zipping it? Well, I could have done this on the Python side as well. I chose not to. I just chose to do this on the server side because it was easy to do. Definitely an optional step, so I'm zipping up sample.txt. I'm converting that zip archive to a Base 64 encoded string, and I'm saving that to a new text file. Again, this is just like in Python, determining the number of file chunks I need to split it up into. Okay?

Then in step two, well, it's really more like step three or four, I'm sending an inbound Note to the Notecard. What I'm doing here is I'm not actually physically sending a file from Notehub to the Notecard. There's no like Pub/Sub agreement or handshake or anything like that.

What I need to do is on my server side, I need to tell the Notecard that there's a file that it needs to grab, and you do that with this concept of inbound Notes or inbound messages. What I'm doing here is I am using the Notehub API to post a JSON payload. Again, looks kind of odd here, because it's in C#,  there's some odd formatting I have to do with my strings here, but I'm submitting a note.add request. Okay, so I'm adding a new Note, adding an event. I'm creating a Note file called file-update.qi, and qi stands for inbound queue. This is inbound relative to the Notecard, so this is what my Notecard is going to use to know that there's a file to grab. This is the file to grab and how many chunks there are to grab. Okay, that's really all we're doing in this method. The first step, then, is to create this inbound Note. I'm preventing myself from going on in this code, because I want to head over to my browser now. You can use a browser, you can use postman or whatever kind of method you want to, or whatever method you want to do to actually execute this API call. Let me head to my browser, and I'm going to hit this send file method, which I just realized you can’t see. Let's get that in the window here. I'm gonna hit that, and it's just gonna return it to hundreds, so we know something happened. Well, let's check in Notehub here to see what might have happened. We can go to our events tab. Oh, what do you know, and then we got a file update.qi. This is the Note, or the event, that I just sent.

Speaker: Rob Lauer  27:14

Let's look in the body, we can see oh, we've got a file here called Sample Base 64, and we’ve got three chunks. Let's head over to the Windows VM, and we can see, sure enough, what have I done. I've taken the sample.txt file, split it up into three chunks, or I actually zipped it first, split it up into three chunks, and you can see the total size there is about 18k, so I saved a little bit by zipping it. Then we created this Base 64 encoded version of that, so this is the file that I want to actually send. Now my Pi doesn't actually, it's not actively looking at Notehub to see if there is a file it needs to download. We need to tell it to do this, and that is where our next script comes into play. Before I actually move on to this, I want to finish up on the server side by showing off another method here, which is just get file chunk. This is the method that the Raspberry Pi is going to hit to retrieve a chunk from the server. That's all it is. It's really just saying, which chunk do you need, and hey, send it back. There's also another method here, which actually goes through how I chunk out the files, how I split the files up, but not really germane to this conversation. Back to our Python scripts and back on the Raspberry Pi. Again, this is the incoming relative to the Raspberry Pi. We are looking for an inbound Note. We're looking for a reason to request a file from the server.

Again, what we're doing is we're initializing the Notecard and connecting the Notecard to that Notehub project. Same thing we did before, and we're simply going to get some updated file information using the note.get API, and we know that the file name is called… what. The file is called file-update.qi. When I say file here, I'm referring to a Note file or a Note or an event, however you want to frame it in Notehub. Just to remind you that comes into play right here. This is that Note file I was referring to. Again, it's called file-update.qi. We are going to skip over some extra methods here to the web get chunk method here, which uses the web.get API. Again, we are getting a file from a remote server. The route is a different route in Notehub called Download File chunk route, which is going to access that get file chunk method I showed you in C#. Again, back in Notehub, here's my second route. Again, it's just a proxy, and it's going to hit this URL, and here's the alias for it. That's all I've set up in Notehub.

Then we have this get file from remote method, which is going to just access these chunks, or request these chunks one at a time. Once we have all the files returned, we can merge them back together and can decode it back from a Base 64 encoded file into a zip archive. We're going to extract the zip archive into this directory. Okay? I'm glossing over some of this, but it's really just the reverse of the process that I explained the first time around. Okay, so let's try this out. Now on my Pi, we're going to execute this 4-incoming script. Where is my—here's my Pi—let's go to X's Python 3, 4- incoming and we'll see what happens. We should see everything happening right up here in our window. We're creating a connection to Notecard. Sure enough, we've got an inbound Note, right, we've got this source file, sample Base 64, and requesting all the chunks, and it has done that quickly. With that done, let's take a look at what happened here. I've got my files directory. I've got the zip file here and an output and here's my sample.txt. Let's open it up: It says Blues Wireless Notecard, yay, everybody's happy. I know I went through a lot of that kind of quickly but really, I just wanted to kind of convey even though there's a lot of steps involved, it's not too difficult of a concept to understand when we are taking a file, taking a physical file on my Raspberry Pi, chunking it up, sending it to the server, and then alternating that process or flipping it on its on its head and sending a file back. All very doable. Cool. That's it for me now. Zach, why don't you take it away to show off some remote control with your awesome robot.

Speaker: Zach Fields - Senior DevX Engineer - Blues Wireless 32:19

Thank you, Rob. All right. Hi, guys. My name is Zach Fields. I’m a—what’s that say—Senior DevX Engineer here at Blues Wireless. I do a little bit of everything. Today, I'm here to talk to you about remote-control applications or basically high latency signaling. So let's talk about remote control. I think if I could impart something on you, it would be to not think of it as the noun but instead as the verb. The remote control, or like your TV remote, or a remote-control car, those are instantaneous low latency super twitch fast response times. The sense of remote control we're talking about here is more of controlling an activity, process, or machine from a distance. Something that can be a lot slower. There are several instances of this, and hopefully today, I can persuade you that that's actually the more common use case than a TV remote, but we'll see if I get that done or not. So, what good is high latency? All right, so let's touch on this a little bit more. Some of the things that you're gonna see, like smart homes, like a thermostat, a garage door, you're already waiting for multiple seconds for these things to kick on, if not minutes, so another three seconds of a high latency signal isn't really going to impact or take away from the effect. In the automotive industry, there's things like remote start, remote entry, or you can just completely disable the vehicle.

Think of like OnStar applications, or there's also infrastructure like the floodgates on dams, or rail switches, wind turbines, or even aiming solar arrays. None of this needs to happen instantly. It can certainly be absolutely as effective with a three- or five-second delay. All right, so to bring this into Notecard realm now, let's talk about how the Notecard operates. There are the two main ways: there’s periodic, which is the standard or more normal mode, or continuous. The Notecard was originally built around the periodic model, because the idea was it was battery powered, so it needed to be very conservative of bandwidth and just power. Mostly just power. This is, when you have a sensor that, something you want to wake up, check every 6 to 12 hours, report it back, and go back to sleep and conserve that battery. Then there's continuous mode. This works way better when you want to bring that down to kind of being always on, so continuous mode maintains a constant connection to the cell tower. It doesn't drop, it doesn't just drop and reestablish connection, it just tries to maintain a constant connection. That way, it's always ready to send or receive messages. Specifically here, we're going to be talking about remote control and receiving messages. That's why it's particularly important that this is constantly connected. Now, that's not to say that periodic can't receive messages, it can, but they happen at a predefined interval, so it won't be, if it's something that's urgent, then that won't work.

As I said before, the periodic model is built around battery power, and so continuous to have that always on, always ready, that's going to require being connected to mains power. You'll want to have a wall wart and power to the Notecard at all times, typically in most applications. Okay, so enough of that. Let's get on to the demo. I've told you that we can achieve high latency but not too bad times, so let's test out on something like remote control robotics, and what better robot than the NES R.O.B. What I've done is I built a web page that sends a message from the webpage to the Notehub data center, which then goes on to the cell towers there, and then to R.O.B., and then you'll see it streamed live on Twitch. Let's have a look and see how that goes. Let me bring up the web page. Here we are. Anybody can go play with this. You can go play right now. It's nesrob.live. This has been up for, we're getting close to a year now. This is my favorite example of what I've created. If we come over here, we can click on the Nintendo control, I'm going to push… uhh, let’s close his hands. I’ll push this button to close. It's awaiting the Notehub, and then we're gonna see. Okay, it failed; but it didn't fail, because I can hear it running in my room, so my web page failed. Let's go ahead and try that again and see if the webpage can do a little bit better job for me. All right, so let's open his hands. Let's open the damn floodgates. All right, click it and says… there you go. Now you got to see a rundown all the steps. It's operating right now. You can't see it because of the Twitch stream delay, but it already happened. There you go. You just got to watch it go through. This is kind of a fun demo; it kind of shows how you can control things and that the delay is not a delay that you can't tolerate, it's just not instantaneous. That sums up remote-controlled applications to help you get some ideas with the Notecard. All right. From there, I’ll pass it on to my colleague TJ, and he will tell you about firmware updates using the Notecard. All right, onto you, TJ.

Speaker: TJ VanToll - Principal Developer Advocate - Blues Wireless  39:04

Cool, thanks, Zach. Yeah, I'm TJ. I work as a developer advocate here at Blues, and today I want to talk to you about firmware updates. Now, firmware updates aren't uncommon in the IoT world, but they are kind of uncommon in a cellular context, mostly because cellular isn't exactly known for having extremely high bandwidth. Rob showed us earlier today that file transfers are possible over cellular, and we at Blues provide some pretty cool ways of allowing you to do firmware updates over cellular as well. So Blues. We make the Notecard, and the Notecard has firmware, and we provide some means to allow you to update that firmware remotely.

Why this is cool is if you have these Notecards, as I said remote, let's say you have this Notecard out in the field, or maybe more importantly, you have dozens of these devices spread out. Maybe you have entire fleets of these Notecards spread out across the country or across the entire world. Being able to update the firmware on these devices without having to physically travel out to them and connect to them manually can save you a lot of time and a lot of money as well. Personally, I think it's just kind of cool, also, so why don't we take a minute and look at how that all works. We’ll do so by switching over, here we go, to a demo.

All right, what you're seeing is dev.blues.io, which is our documentation hub for all things Blues. If you weren't aware, one cool feature of our documentation is you can connect directly to a Notecard and Notecarrier over USB and communicate with it, which is what this pane is for over here. I have a Notecard connected to my machine already, and what I'm going to do is just issue a quick card.version request. I'm doing that because it's going to show me what firmware version my Notecard is currently running, which in this case is version 1.5.5. Now, also on our development hub, we have a list of firmware releases that we've pushed out for the Notecard, and you'll see that there actually is a new version—version 1.5.6 that's available—and it has a handful of new features. Now, let's suppose I really need one of these features for one project that I already have deployed. Maybe I could really use this ability to randomly generate a Note ID. The specifics of the features don't matter if the idea here for this webinar is let's just suppose that one of these is really important that we need to use for whatever reason.

To get that feature, I'm going to need to update the firmware on my device. For the Notecard, I can do that in Notehub, which is our cloud backend for managing all things Notecard, and which you can access at notehub.io. If I go into one of my projects, and I'll go to my list of devices, and you'll see that I have one Notecard associated with this project. One thing I can do directly on this devices list is switch to the Notecard firmware tab, which is gonna allow me to see the firmware version of each card on this project, which in this case, you'll see that I have this 1.5.5 version. Now what's cool about this UI is that it allows you to see the firmware of not just one device, which I have for this simple project, but potentially multiple devices. If you had a really complicated project, or even fleets of devices, if you have something that was really widely distributed and used, and you have the ability to perform updates to this firmware. I can do that by checking this and clicking this Update button.

In my case, I'm just going to update a single device just to keep things simple for a demo, but I could potentially update these multiple devices or fleet of devices at the same time or split them into logical groups, or whatever made sense for whatever it is I happen to be building and deploying. Like I said, I'm going to keep things simple for the demo. We'll go ahead and update; you'll see that version 1.5.6 shows up as available, so I will go ahead and apply this to that current device. Now making that change in the Notehub UI queues up the update, but the update doesn't actually take effect until I perform a sync on the Notecard, and that's because our Notecards are power conscious by default, so they're not going to be constantly checking and pinging Notehub to see if there are any updates or any changes that need to happen until you actually perform a sync. If we pretend this Notecard that I have hooked up to my laptop here is actually out in the field remotely, maybe it's gathering some sensor data or whatnot, I probably have some code on that device that's going to sync data to Notehub periodically, maybe it's going to be sending you weather readings every hour or maybe every day, depending on exactly what the device is doing. We'll go ahead and simulate that by, again, going back to our handy little browser testing tool here and just manually running a hub.sync command, which is going to perform that same functionality. When I do, if I head back to Notehub and head over to my events list, you'll see that it detected the firmware update, that it needs to happen, and went ahead and started to download that firmware to the device.

Now I do want to make it clear that this firmware update process, the download and actually applying the update, does take a decent amount of time because remember, this is data that's travelling over narrowband cellular, which doesn't exactly allow for a ton of bandwidth. I'm gonna go ahead and use a little bit of demo magic to fast forward us to the end of the process. All right, so it's been about 20 minutes, and if I head back over into Notehub and look at my events, you'll see that I successfully downloaded 100% of the firmware. If I go back to my connected device over here and issue another card.version request, you'll see that I did successfully update to version 1.5.6. Now, if you remember, one of the reasons I wanted to do this update is I wanted to get access to this new feature that shipped in 1.5.6., so what I'll do next is paste in a little bit of code. Again, the specifics here don't really matter, but the new feature is this ability to pass in a question mark for a Note to generate this random identifier. You can see that it is indeed able to generate it, which means that it is working as intended. There you have it, firmware updates over cellular, who knew?

Personally, I think it's kind of cool that you can do these sorts of updates remotely. Again, especially if you have a whole collection or fleet of these devices in an area you can’t easily access, it really can be not only cool, but a big time and money saver as well. Before I let you go today, I do want to point out a few quick things. First of all, although we do recommend updating Notecard firmware through Notehub, as I showed today, you can also update the firmware manually over USB as well. If you're interested in that, we have documentation on dev.blues.io; you'll find it in the Notecard firmware updates section. Second, although I focused on updating Notecard firmware today, we do also offer the ability to update host firmware for ESP-32 microcontrollers, as well. It follows a fairly similar process, and if you're interested in that, you'll want to check out again dev.blues.io and look in the Notehub section and search for host firmware update requests. That's it, which I believe means we're at the end of our uncommon cellular use case list. With that, I'm going to turn things back over to Rob to wrap up.

Speaker: Rob Lauer  46:56

Awesome, thanks, guys. Before we turn it over to questions, I did want to mention that a few weeks ago, we released our first Feather-compatible microcontroller. Pretty exciting stuff. The Swan is making some waves as the most extensible Feather-compatible microcontroller available. When it's paired with the Swan carrier board you see here, you actually have access to 55 ports and IO. It's based on the STM 32 L4+ running at 120 megahertz, two MBs of flash, 640 K of RAM. As you see here, it supports Arduino, C, C++ and circuit Python. Swan is an awesome option for edge computing scenarios, even for Tiny ML, so those low power machine learning solutions. If you're at all curious about Swan, head over to blues.io here for more info. Now with that, please visit us at dev.blues.io for all sorts of technical resources from Quickstarts to data sheets. Grab your own developer kit at shop.blues.io. Join our community. I really welcome folks to set up an account in our forum at discuss.blues.io. One more thing that may interest the ML crowd: A little while back, we put on a demo/workshop with the folks at Edge Impulse on remotely updating your ML model files using the Notecard. You can find this presentation at the URL here: bit.ly/blues-ota-ml. This webinar covers some of the same tasks that I went through earlier in this presentation for file transfer, but with some really cool strategies for also gathering data remotely and then updating an ML file with that data, all using cellular and the Edge Impulse APIs. All right, with that, give us just a moment here so we can get everyone back on the line so we can answer some of your questions.