Rapidly Prototyping Environmental Monitoring IoT Devices - On Demand Webinar

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

Alright hi, everybody. Hopefully you can see my screen. Good morning, good afternoon, good evening to everyone. I think we are ready to get rolling here. So, welcome to this webinar today on rapidly prototyping environmental monitoring IoT devices. And there is yes, admittedly a lot going on in that title, but we are planning on touching on all these concepts that we’ll talk about throughout our time together today.

So, starting really with this idea of rapid prototyping in the IoT. And what that really means when developing IoT prototypes and how connectivity you know, the ‘I’ of the IoT should be brought into the equation much earlier maybe than we normally do. Now, thanks to our friends at LimnoTech and Clean Earth Rovers, we're going to hear how they are developing their environmental monitoring devices, using a lot of these rapid prototyping ideals.

Now, first, a few brief logistics for the webinar today. We will be answering your questions at the end, but you don't have to wait until then to ask. We're all here to answer any questions that may come up during the webinar. So, go ahead and enter them in the Q&A window as they pop into your head. We are also recording this and we'll send out a link to the recording in the next day or so. And where would that recording be? Well on YouTube, of course. Here's my official plug to check out all of our video content. And of course, subscribe to the Blues Wireless channel.

So, what are we actually going to be talking about today? Well, we're going to start with IoT connectivity options; the different choices, and which ones maybe make the most sense as we develop our prototype. We're also going to take a closer look at Blues Wireless and how we're helping to solve wireless IoT. Even better, as mentioned, we're going to get to hear directly from our friends at Clean Earth Rovers and LimnoTech to get an inside look at the really the business and engineering of their IoT environmental monitoring solutions.

First, I want to do some introductions, starting with myself. My name is Rob Lauer, I'm Director of Developer Relations here at Blues Wireless. Joining me today is TJ VanToll, who is the Principal Developer Advocate here at Blues. I'm also super happy to have Michael Arens here from Clean Earth Rovers. Michael is Co-Founder and CEO, along with Michael from Clean Earth Rovers is Co-Founder and CTO Jonathan Rosales. And finally, Ed Verhamme is here from LimnoTech to talk about their spin on environmental monitoring with the IoT. So, we've got some great content coming up for you today.

Now, when we got together to discuss this webinar, we kind of landed on this message of rapid prototyping. Now, as a novice IoT engineer myself, I know that when I've prototyped some projects, and put them up on Hackster, like the place I traditionally get most easily wrapped around the axle, if you will, is with connectivity. And of course, connectivity to me really is the IoT. And it's, unfortunately too often an afterthought.

Speaker: Rob Lauer 03:00

And I guess, I argue that connectivity should be at the forefront of what we are considering before we even start our prototypes, as it can pay off massive dividends to avoid retrofitting and refactoring down the road. So, my personal take on rapid prototyping starts with optimizing the ‘I’ in the IoT, right, establishing connectivity in the earliest stages.

But today, we have choices – maybe too many choices – when it comes to connectivity, right? We can find ourselves paralyzed by having too many options with no clear path forward. So, let's look at some specific deployment related considerations and see how some typical connectivity options can play into our decision.

It starts with communication range, right? How close to a gateway does the device have to be? Are there indoor or outdoor line of sight considerations?

Power efficiency. Is the hardware connected to a consistent and reliable power source? Or is it off-grid? Is it connected to solar or battery? How long does the device have to live on battery? What about availability? Is it okay if my device shuts down completely in the event of a local power failure? Or should it continue to record or even send data while on a backup power source?

And data throughput of course, like how much data am I pulling/ pushing? How frequently? Does my solution require low latency between the device, the cloud and beyond? Is it okay if the data arrives to the cloud at hourly or daily intervals?

Finally, end user experience. How is my solution going to be deployed in the field? Is it a consumer installable product that requires setup by a non-technical user? Or is it okay if the wireless setup requires an installer or someone familiar with network configs?

It's all to me a bit overwhelming because there is no silver bullet. There is no one size fits all when it comes to connectivity. Each has its own set of pros and cons between Cellular, LoRaWAN, and Wi-Fi. There are myriad options and potential pitfalls, right? Physical enclosures, geographic locations, device portability, all the kind of stuff.

While Wi-Fi is great in some high bandwidth scenarios, it can also fail miserably in low-power scenarios. Likewise, cellular can be amazing for its reach, but historically has been really difficult to program. So, I wanted to look a little more closely at a few of the more popular wireless options. So, Wi-Fi, of course, has come a long way in terms of speed, reliability, there's even some new protocols coming out the 802.11ah standard is focused on low power consumption, which will be great for IoT. However, we're still away from that being kind of more mainstream.

So, when does Wi-Fi become a good choice? Like, obviously, if your solution requires high bandwidth, or low latency; streaming video is a great example. If there is ample Wi-Fi coverage without the need for switching access points, it's great as well.

However, as mentioned, sometimes if you have a deployment that is handled by non-technical users that Wi-Fi config can be tedious, home routers can be unreliable. If you are connected to unmanaged networks, and you're sending sensitive data that can get really tricky when it comes to privacy and security concerns. And as mentioned, sometimes, depending of course on the Wi-Fi module you're using, the power consumption can be a little high. And also, of course, a local Wi-Fi router can't function without power. So, if you lose local power, you generally lose your network connection as well.

What about cellular? Well, specifically with cellular, I want to focus on LTE-M and NB-IoT, as those are the two that are most commonly used with IoT solutions. At a high level, LTE-M is generally the faster of the two and it's compatible with existing LTE infrastructure. Whereas NB-IoT has a wider theoretical range, but is not quite as popular globally, but still does exist in quite a few places.

So, when does cellular make sense? Well, when uptime is essential, right? Cellular networks are ubiquitous around the world. Generally, very reliable, seamless global coverage, more or less, right?

Data Security. If you're doing it the right way, if you're working with cellular providers, and using custom APNs, the data doesn't even need to travel on the public Internet; it can go directly from the carrier to the cloud provider.

Low-power and no-power scenarios. Cellular add-ons, again, when done correctly, can consume very little power. And the nice thing is cellular networks are still available, generally speaking, should local power go out.

However, if the solution requires high bandwidth or low latency, again, like streaming video or pushing images – again, when I talk about cellular, I'm talking about narrowband cellular – not a great choice. Or again, the latency I mentioned. But the other thing I was going to mention is voice over LTE. That's not going to work if you're on an NB-IoT network.

Finally, I wanted to talk about LoRaWAN. So, if you're not familiar, LoRa (not LoRaWAN), stands for long range radio. It's an open standard networking layer that's really gaining popularity in the EU. LoRa really aims to solve the traditional IoT dilemma of balancing low power with long range communication requirements. So, LoRa is the physical layer and LoRaWAN is the network layer.

Now in ideal conditions, LoRa devices can communicate with LoRaWAN gateways from 5-15 kilometers away, which is pretty amazing. In practice, physical obstacles like trees and buildings, etc, can really disrupt data transmission. So LoRa requires a really great network of physical gateways to be effective.

So, when does LoRa work? Well, Transport Layer Security is baked in, so it uses AES CCM encryption by default, which is fantastic. Like NB-IoT or LTE-M, if you're trying to hit that sweet spot of low power and wide range deployments, it works well. Low power again.

And when does it [LoRa] not work? Well, if you need a uniform global solution, meaning if you're going to deploy something across the globe, the problem with LoRa is that operates on different frequency bands in different regions. Likewise, if you are deploying outside the EU, the deployment of these LoRaWAN gateways is more scattered. Again, like with narrowband cellular, even when higher medium bandwidths are required LoRaWAN kind of fails because data is sent in very small chunks at a time, and even country specific regulations limit how often data can be sent upstream or downstream.

Now I just covered these three and I'm not here to spread any fear, uncertainty, doubt about any of the three I'm just trying to give like an honest, my honest opinion of kind of where we're at and how there is no magical silver bullet here. But I think we can take deep breath because I think we know all will be okay.

Speaker: Rob Lauer  09:47

And this is where Blues Wireless enters the story to hopefully help solve some of these problems. So, at Blues we are hyper focused on making wireless IoT really more accessible and easier to use. We're trying to authentically solve some of the previous issues I mentioned around cellular. Now full disclosure, we do have a Wi-Fi solution as well, and a LoRa based product coming soon.

So again, I mentioned these because I'm not here to say that cellular with Blues is that silver bullet, right? You have to take into account your own solution’s requirements, and choose accordingly. That being said, to me, Blues is becoming the easy button if you will, of wireless IoT; helping people to reach that prototype stage faster than ever before. We're really getting there by providing hardware and services that back up this message of making wireless IoT easier for developers, and more affordable for all.

If that is our core mission, how do we really make that happen? Well, our focus is very much on securing data from the moment it's acquired by a sensor all the way through to landing on your cloud application. All of our solutions are low power out of the box, to the tune of eight microamps when idle. We are also a very, very developer-focused company. So, our dev experience is a top priority. And I think you'll see that play out in TJ's demo.

Quickly zooming in on our hardware, the Notecard is the core of what we provide. It is a low-power System-on-Module, measuring 30x35 millimeters there. It does have that M.2 edge connector at the bottom for embedding in your project. And as mentioned, there are both cellular and Wi-Fi variants of the Notecard. The cellular one does include GPS as well. Cellular one comes prepaid with 500 megabytes of global data, 10 years of global service, you can top them up with more data if you need them.

The API, so the way you interact with the Notecard, is all JSON. So, gone are the days of those archaic AT commands to manage your cellular modem. And we also have SDKs available for a variety of popular languages. And there are Notecard varieties that we’re globally, again using those two protocols I mentioned earlier and Cat-1 as well.

So that's what Notecard brings to the table. But just as importantly though, you should know what you don't need when you're using the Notecard. You don't need your own SIM or mobile plan. The Notecard comes with an embedded SIM. Likewise, to work with the cellular radio as mentioned, you're not issuing AT commands. You're not rolling your own security. Everything comes with an integrated, SD-safe, secure element baked in.

For firmware updates, you can update Notecard and host microcontroller firmware over the air. And while there's always some type of power management you're going to have to do, all the components on the Notecard were chosen because they are low power by default, as are all the default configs in the firmware. And securely sending data to your Cloud Endpoint is baked in and quite simple.

So again, developer experience, super important for us, which again, is why everything is JSON in and JSON out with a Notecard API. As a quick example, if you want to get your Notecards, GPS location, you simply call card.location, and it will return your location with some additional metadata. The rest of API is very similar to this.

And finally, just to help visualize where the Notecard and Notehub (which is our cloud service), sit in your IoT solution, I want to walk you through a quick diagram here. So, you bring your microcontroller, your single board computer, your sensors, you use your language, whatever you want to use, we don't dictate any of those things.

You're going to compose packets of data in JSON format that we call Notes. Now these Notes are then queued, they're stored on the Notecard. And at a cadence you specify, they are securely synced with our Cloud Service Notehub. Now Notehub does not exist to store your data, it exists to securely route your data on to your cloud app of choice. So that could be AWS, Azure, Google Cloud, or an IoT provider like a Losant, or Ubidots or Datacake. Communication also, I should mention with the Notecard, is a two-way street. You can reverse this process for inbound communications as well.

Speaker: Rob Lauer 14:04

Now with that kind of blitz of a high-level summary of connectivity options, and Blues Wireless, I want to pass the mic over to TJ VanToll, who is going to give a brief tech demo. Then we're going to hear from Michael, Jonathan, Ed on their journeys with environmental monitoring. So, TJ, I will stop sharing and pass it over to you.

Speaker: TJ VanToll - Principal Developer Advocate - Blues Wireless 

Yeah, thanks, Rob. So, I'll take it over just because I want to quickly give you a look at what the hardware actually looks like outside of a slide just because I think it's important for seeing how these things work. And then also as Ed, Jonathan, and Michael will talk about their projects, just so you have a little bit of context for what the hardware looks like and how it works.

First of all, this is the Notecard. These are the cellular and Wi-Fi variants of it. This is a System-on-Module. It's about 30x35 millimeters, which hopefully you can get a rough sense of how big that is compared to my hands. These are designed to be embeddable into pretty much any IoT project through these M.2 edge connectors on the side.

And to make that process easy, because again, we want to help you get up and running quickly, we also make a series of Notecarriers. And I'll bring one over; here this is the Notecarrier A. The Notecarriers are designed to easily accept a Notecard and allow you to do things like for example, the Notecarrier A has onboard cellular and GPS antennas. It has JST connectors over here for putting in LiPo batteries. There are quick connectors if you want to start working with quick peripherals quite easily. So that is the A.

We also make the Notecarrier AF, which is a similar concept with a lot of the same features. The one difference with the AF is it has this Feather-compatible header sockets on the side. So, if you have a Feather-based MCU that you want to use alongside the Notecard, it makes it really easy to slot that in, start communicating with the Notecard, put this out in the field and start working with your project right away.

And the last one I'll show is I’ve got a Notecarrier Pi here as well, which is a Pi HAT that sits on top of a Raspberry Pi. So, if you're a fan of the Raspberry Pi, you can get a Notecarrier Pi slotted on top, put in a Notecard and get started working with cellular on the Pi as well.

Now, the last thing I'll show is on the side of these Notecarriers. All of them have a micro-USB slot as well. And what I'm going to do with that is actually switch my camera back so you can see me again and show my screen, make sure I pick the right number, there we go. And I'm going to take my Notecarrier A with Notecard and plug it into my laptop through that USB slot that I just showed.

So, if you are new to Blues, the first thing that we recommend you do is head to dev.blues.io to our Quickstart tutorial that we have for the Notecard. One cool thing that you can do through our site is actually connect to your Notecard directly in Chromium based web browsers. We use something called the web serial API to communicate, and through this USB connection, I can actually start sending requests directly to my Notecard. So, I'd recommend going through this on your own time, if you do have a Notecard. I'm going to give you like the CliffsNotes, the short version of it here today.

The first request that you'll want to send in the tutorial here is a card.version request which I'll just go ahead and send real quick so you can see what this looks like. It's just going to give me some basic firmware information about the Notecard that I'm using. But I will point out a few things.

First of all, Rob showed this in his slides, but I think it's kind of cool, the API for the Notecard is JSON. So, I'm sending JSON; in this case, it's sending a request, card.version. And the output, the response I get back, is also JSON-based as well. So, I could get this in my host, do whatever it is I needed to do depending on the type of request.

All of the requests for the Notecard work this way, you can send them in the browser like I'm doing when you're learning how the Notecard works, when you're doing some quick testing. But all of these commands can also be sent through a CLI that we offer for Windows, for Mac OS, and for Linux. And more importantly, they can all be sent through SDKs that we offer for platforms like Arduino, C, C++, Python, CircuitPython, Go Tiny Go.

When you're ready to build your production applications, you build them around sending these requests to the Notecard and building whatever interesting project that you have in mind. Chances are those projects revolve around data. So, the next thing I want to show is how you can take some data that you're collecting locally, through some sensor or whatever, and start pushing that up to the cloud. And to do that, you'll need to set up the Notecard’s cloud backend, Notehub.

As Rob said, Notehub is sort of a thin cloud layer that the Notecard knows how to speak to out of the box. The first time you go in, you will need to create an account and also create a project, which is just a logical place to group your devices and the data that you're working with. I already set one up here today to save us a little bit of time. And what I've got to do is grab this identifier, because the next command I'm going to have to run if I scroll down a little bit is this hub.set command. And I just need to paste in, – if I can use my keyboard correctly, there we go – what we call our product UID (this identifier that comes here). And then I also need to initialize the sync.

We designed the Notecard to be low-power friendly by default. And one of the things that means is, we try to avoid doing sort of power intensive operations. One of those would be communicating, sort of turning on, a cellular modem and sending data across a network. By default, we try to defer those operations to an interval that you can configure. But you can also just trigger it if you need data to go for a demo, or when you need that sync to happen you can sort of explicitly tell the Notecard to do it through a hub.sync request. And once you do, what I should be able to do is go back to my backend, refresh here, and I now have a project that knows about my device, knows about my location, and whatnot.

Once you've made this connection, at this point, you're now ready to start collecting data and pumping that up to the cloud through the Notecard. As a next step, I'll go down here and run the note.add request; note.add is just a really simple way of adding (more or less) an arbitrary JSON object.

In this case, this is hard-coded data. But this is basically simulating having some sort of temperature and humidity sensor hooked up, pushing that up to the cloud. Once again, data is not going to be sent immediately. I have to run a hub.sync to sort of kick off that request, get that data up to the cloud.

Once it does, it'll appear in this events list. It is over cellular, so there is going to be some latency; we might have to wait a second for that to come through. You can also run a hub sync status to get status information. So, in this case, it's connecting, so we'll give it a second for that data to come through. And in general, I'm not going to go too much further down into this tutorial.

Again, this is something that if you are new to Blues, if this is the first time you're seeing and hearing this, I would recommend going through this, checking this out, the rest of the tutorial will walk you through how to take data from the Notehub side of things. So, we've been sending data from the Notecard up to Notehub, which our data should be there at this point. And there it is.

So, this was going from my physical Notecard sitting here on my desktop to Notehub. But you can send data, you can send commands, variables, down in the opposite direction as well. So, if you need to remotely change a host that you've got out in the field somewhere, you can do that through either the Notehub UI, or there's an API that runs around everything around here that you can automate as well, if you need to do some remote configuration as well. That's like the really quick version.

The last thing I'll point out is to learn more, this Guides and Tutorials section has a lot of different stuff that you can check out. From collecting more real world sensor data, to routing your data out of Notehub into your cloud provider of choice, setting up a Notecard as an asset tracker, there's a lot that you can do. The very last thing I want to show before I turn it over to these guys to hear about some of their projects, is a more complete version of this sensor tutorial, just so you can get just at least a glimpse at what more of a real world solution with the Notecard looks like.

You'll note that I'm sending the same sort of request that I was sending in my browser, but in this case, I'm using one of our SDKs. So, this is Arduino. This is using the Arduino SDK to set a hub.set. But the syntax for the request is identical, I'm hub.setting, I'm again setting a product. If I scroll down a little bit, I'm getting a temperature and humidity reading, and then I'm doing the same note.add request that I did earlier to actually push that data up. And this is our Arduino, but this could be a Python script running on a Raspberry Pi, this could be a CircuitPython running on some sort of feather based MCU.

One of the things that's important to us with a Notecard is trying to make our stuff work on whatever hardware, whatever setup you have, that's why we offer a wide variety of different tools and SDKs. But I think that’s sort of like the whirlwind tour. Again, dev.blues.io is where you want to check out if you want to learn any more of this. But at this point, I'm going to turn things over to Michael so we can hear about some real projects built with this sort of stuff, because I think that's going to be a lot more interesting. Michael, you want to take it from here?

Speaker: Michael Arens - Co-Founder and CEO - Clean Earth Rovers 24:04

Sure. And thank you, Rob and TJ, for bringing everything up and going through the background and explanation. I mean, we're here because we support Blues and everything that you guys are working on, and they're great solutions.

So, with that, I guess I'll jump in quickly, and give some background context to what Clean Earth Rovers is and then some of the solutions that we're working on that we're using Blues for connectivity with. Then I'll toss it over to Jonathan, who can give some more granular details on why we chose Blues, and how it's been working for us so far.

To get started, Clean Earth Rovers is an early-stage startup that Jonathan and I have been working on basically since the pandemic, and then with a few other founders all the way back to 2019s. So, it's something it's been a long time in the making, and rapid prototyping for us took place in the bulk of 2021. Our technology went through a number of different iterations and cycles. And even so much so that near the end or the Fall of 2021, we decided to add in this data piece to our value proposition. And that's where Blues really started to come into play with our technology.

So, with that, I'll share some more about what it is that we're working on. Clean Earth Rovers is focused on solving marine debris in our coastal waterways. Every year 11 million tons of plastics and manmade pollutants enter our oceans. And out of that, we estimate that 6.6 million stays within coastlines.

That has a heavy impact on the efficiencies of coastal businesses such as marinas, harbors and yacht clubs around the entire US and the world. So, they're constantly dealing with this and trying to keep their customers happy at the same time. Meanwhile, we also see, both in salt and fresh bodies of water all over the US, is just a massive amount of nutrient pollution that causes pollution events, like marine die-offs, like you see in this picture, that also continue to affect local tourism, economies and local businesses.

When we really started to work on Clean Earth Rovers, we took a step back, and, as I mentioned, tried to really figure out who the parties are that deal with the problem the most, who has these pain points when it comes to manmade debris and pollution being in the water. And what we found was, marinas are actually skimming by hand, for upwards of two hours a day, with more than one person.

That's costing them quite a bit on an annual basis, as well as some of these other chemical pollutants that are in the water is costing them upwards of $5,000 per report with the Coast Guard. A lot of the municipalities in coastal areas actually have reached out to marinas to see if they are engaging in any water quality campaign where they're actually collecting the data.

What we realized when we started to hear this from marina customers, was that there's some sort of dichotomy between these private small businesses and the actual local governments themselves that are dealing and overseeing these waterways. So, with that, we started to talk to different homeowner associations and municipalities that were connect connected to water. And what we found is that many of them are collecting water samples, but the common practice, at the moment, is to be collecting samples by hand. And if they are collecting samples using remote monitoring instruments, in many cases, it's costing them upwards of $40,000 per buoy.

If they're not collecting this water data, or having some sense of awareness of what's going on, they run the risk of facing a pollution event like a harmful algal bloom. And annually, it's costing US coastlines and tourism economies over $4 billion. They also run the risk of endangering citizens and whatnot in the area by hospitalization and death. So, that's when we started to tie all this together, and we said, Okay, well, we want to make a Roomba for coastal waters.

We've created an autonomous debris skimming device that can collect the manmade pollutants and the pollutants that you can see off of the surface of the water, and streamline that entire process for businesses. We also created a separate monitoring device. And these monitoring devices are attached to all of our debris skimmers, but they can be standalone monitoring devices as well. Then all of the data that's coming from each of these technologies is being aggregated into one user interface.

Here is actually our first rover, in the water at a marina in Cincinnati. This is our awesome Engineer, Rob, who's taking it off the trailer. And so, some of the ways that this works is it's a completely electric vehicle that can collect up to 150 pounds of trash. And it's fully autonomous. So, through waypoint navigation, and this is a huge key for us when it comes to telemetry and connectivity, is being able to access these devices in really remote areas where some marinas are located, and being able to tell it through our cloud platform where it needs to go.

It also uses a series of reusable and disposable bags for maintenance with the customer, and provides the same data services that our data pod uses. This is also a solar powered and electric product, where it monitors up to six key metrics for water quality at the surface level. And what we hope to do is that as we continue to expand our deployments with both pods and rovers, that we actually build heat maps of data that are so dense, we can provide predictive analytics to coastal regions around the US about when pollution events will actually happen. And then they're all IoT enabled.

So, with that being said, I will let Jonathan jump into it to tell you a little bit more about how these solutions kind of come together with Blues Wireless, and give you more of a granular dive into the technology.

Speaker: Jonathan Rosales - Co-Founder and CTO - Clean Earth Rovers 24:04

Thanks, Michael. Hey, everyone. So yeah, I'm just diving a bit deeper. I think, the main benefits for us when we were prototyping and doing all this technology scouting, I originally started with a couple different cellular modules. In our application, since we're talking about outdoor IoT devices, cellular was the right option. We looked a little bit into LoRaWAN, but honestly, that still requires gateways that you need to have nearby, and so on. So, cellular was the right choice at that moment.

As I was testing, honestly, the big pluses that I found in Blues, and why I leaned towards using the Notecard, was first the low power consumption in our particular application. We want to have this device itself being self-powered, and just have enough energy through solar technologies. As we know, solar is not as efficient as we want it. We’re talking about like a 20%, roughly, in the best scenario. So that actually makes a big constraint on your application. And that's why being able to power like, if you've done electrical work, 8-microamps of consumption when it's idling, that's amazing. It's something that you would definitely want. And so that was the first tractive point there.

Then obviously, the Notecard, the Notecarriers, are really well designed in my personal opinion. And they incorporate other aspects that we wanted in our devices, such as the GPS, and the cellular connectivity, and the battery. And it has a power administration system embedded into it. So that's just a lot of electrical stuff and electronics that makes it really attractive as a development board. And even as in solution to just integrating, but the cherry on top was the Notecard itself.

So, the platform, being able to just make it so easy to interact with our cloud and our cloud databases, that was really nice. And, for those of you who have not used Notehub yet, I recommend looking when you set up your routes, it also offers JSON data expression editor.

In our case, as Rob mentioned before with cellular, your bandwidth and the amount of data that you can send, it's really limited. So, the more data you want to send, you run into more constraints. Being able to summarize that data like you yourself, like you're developing it, you'll be able to know exactly what you're sending. So, you can minimize like, just enclose that as much as possible. And then in Notehub, you can add all the fancy stuff that you want, you can add it and aggregate and do all the different options that you have there. And that will not take bandwidth data or anything from your device itself.

That's just another post-processing option, and then like you can do that in Notehub itself and send the post-process data to your cloud for instance. That's just another feature that's part of it. And then the price is really attractive compared to other solutions. There are some other solutions that you'll find, but honestly, you're getting a lot of benefits out of this.

So, it's definitely a really, really good option to use for your connectivity. And honestly, for other applications we don't have in our company yet. But I get the notifications of like the Wi-Fi carriers, and the Wi-Fi cards and all that. So, they're really good. And plus, we have (I know TJ mentioned before) the development portal and all the guides like Quickstart guides and tutorials. That's what I've used in our case, I have coding background and so on. JSON data and JSON itself, it's really easy to learn if you have some coding background. And if you don't, you fall on the tutorials, it’s nothing too complex. So, yeah, those are the main components for me why we chose this.

Speaker: Michael Arens

I think as well, just to build off of that, Jonathan, you mentioned some of the alternatives that we looked at, like LoRaWAN, and whatnot. Recognizing from a commercialization standpoint and trying to get widespread data access out there, the amount of gateways that would need to be installed and things like that, those extra added costs are not attractive for a small business that's trying to scale fast.

So, Blues has really cut out a lot of, I would say, the fat in the process and helped us to provide the level of data that we're looking to provide, but also the affordability that we're looking to provide and kind of help disrupt this space.

Speaker: Jonathan Rosales:

And with that said, I think we'll pass it on to Ed.

Speaker: Ed Verhamme - Principal, Senior Engineer - Limnotech 38:06

Great, thanks, guys. Let me share my screen here. So, I'm going to do kind of a similar topic here. So, I think you know, both of our groups are talking about it, monitoring water. I think I'm approaching it a little bit more from a consulting standpoint, and that we see a lot of people's problems. We're paid to do some custom, one-off things.

It's apparent with the technology that we have available, once we figure out something once you know, the ability to make 5 or 10 of those, it’s a lot cheaper, it's a lot easier. So, I've been really interested in this sort of scale down to a larger quantity. And I always want to try and ground what we're doing in societal relevance and societal problems.

So, here's a really great graphic that was created after the Toledo water crisis in 2014. There's, you know, the algae that almost ate Toledo. There was a harmful toxic algal bloom that contaminated the city's water supply. And, you know, the connection of water into people's everyday lives – I just saw Jonathan taking a drink, he's drinking water, that water came from a lake, river, stream and what's happening in those systems and it's really immense.

The scale of these environmental phenomena and how they impact water so, you know, in literally the week after the Toledo water crisis, we took research sensors – expensive, but we knew we could put one station right next to the water intake. So, we sort of grabbed research instruments, patched them together, like we would in a custom buoy and stuck it out there. And that buoy’s been out there for seven years straight now, monitoring Lake Erie.

We know the phenomenon is much larger than just within hundreds of feet of the water intake, this is a huge scale phenomenon. This is Lake Erie here. And since the Toledo water crisis, we've instrumented Lake Erie with hundreds and hundreds of sensors. Now, not all of these are real time, some of these are bottom-deployed. Actually, fish trackers – we’re tracking thousands of fish moving around Lake Erie – it turns out the fishery is more valuable than the water treatment plant industry.

It surprised me, since that crisis, how much we've focused on technology as a solution, given how big the phenomenon is. When I start to unpack, like, all of the components here, if you imagine on the left of this diagram is the lake, river, stream, groundwater. And as I just say, like a science technologist or engineering for water technology, you're going to have to make a bunch of decisions, you're going to have to figure out, what sensor is measuring that phenomenon? And then now you're into a whole electrical mechanical supply chain here of how does that data get read, averaged, coded over to a data logger, which can do some coding work? And how do you get that to the internet? How do you throw that data packet into the air and magically pick it up in the internet? And then how do you get it in front of the users?

All the way right is going to be a person, or it could be a machine learning algorithm, that's doing additional work on it or something. So, I tried to focus on the relevant pieces here for the sort of the Blues IO technology. And you'll notice, that wasn't a mistake, they extended the red box into that data logger box here. When you get into the microprocessor world, it's messy. It can be a lot of work, it's a lot of skill that is, you know, I chose environmental engineering because I didn't have to do any programming, or know anything about circuits. And so, you know, when you guys use the word developer, I hardly say I'm a developer, but now I can certainly pick up this stuff and use it.

That's kind of where we approach these problems. And as we step through these decisions, there's going to be cost, scalability, manufacturability. I'm most interested in batch production. Can we go from one to five? And can we start to test our ability to monitor that phenomenon and prove a value worth case before we're making 1000 of them or something?

The telemetry piece, as we heard, it's super important. It's a rapidly changing landscape with different companies, networks coming online almost every year. And it's been really challenging as a use case developer, which one to pick; how to determine, you know, do I want to tie myself to this technology or that technology? I've kind of come to the conclusion of, none of them are perfect.

And I want the ability to change which one I can use, as I move from prototyping to full-scale buildout, depending on what the ultimate large-scale buildout is. So, you know how do we go from the 50 that we built to demo something and understand and if someone wants to go to a full-blown buildout? You'll really have to seriously look at that telemetry piece again, but we just have so many options. So, LoRa is great, cellular is great. It just depends what you're trying to do with it.

You know, I showed that really expensive buoy. We can really get – if you pick one parameter, let's say it's turbidity and you want to measure that everywhere – now, what's the cheapest way to get a turbidity measurement back to the internet? You're going to cheapen everything along the hallway, cheap MCU, cheap radios. And cheap is a bad word, I’d just start saying efficient. You know, what's the most efficient way to do that? And you can use the word value. They certainly end up being cheap, but it's not because they're low quality.

Just one demonstration – and we literally did this last week where we got a phone call – someone said, hey, there's an oil spill. How do we measure the stream for oil and water? And I said, well, we can grab a Notecard, we can just slide it into the Notecarrier B, which gives us a little bit of power management and control, and a little bit different pin-out for us from that edge connector.

We also had printed what people call an interposer board. So, it's just moving some pins around. We've been using an Arduino environmental data logger for a while, which is super flexible for us, that has already it's a XP pin-out for our communications module, Wi-Fi, Bluetooth. There's a whole series of these that go back to the early 2000s with just the drop-in module for telemetry.

So, we just needed an interposer board to go from the Notecarrier to this XP format, and plug it in, and boom, we have an oil and water sensor that's sending data to the internet. And this is within two hours in our back shop.

So, it's not that we got everything from scratch here, we have some code that we can work with. But it goes through that whole supply chain of instruments. I talked about grabbing the sensor, we take the data logger, here's the telemetry method, and here's where that data goes.

So again, I think that the ability for someone to make a phone call and say, hey, I want to do this; then you just go into your recipe book, and use the easiest part in the middle. That takes a bunch of the uncertainty away with the custom coding and how you're going to configure it to use the AT commands. And yeah, I know, TJ already walked through this a little bit, but I just wanted to say, yeah, I’m not a programmer, or even what I classify as a developer. The hardware wiring is just TX/RX power ground, the only thing we're going to grab off of all these other pins, you know, we ignore everything else. The thing manages sleep really well, and power. So, once we do our thing, it just goes to sleep and waits until our next command programming.

Again, I would not know how to construct this sentence, but if someone shows this to me, I'm going to hone in and say, this is where my two measurements would go: temperature 35.5, and humidity 56.23. I can always copy someone else's work. I think, you know, it's not like college where you can't look over someone's shoulder on the test here. So, I think copy and paste, I use it all the time and it's super easy to just jump into coding. And then you just use that same command.

And then TJ, you showed part of this as well, but again, there's a lot of magic that happens. You can go in and see all these things of where data is going and why it's going. We have other people here that helped me with some of the cloud stuff. Again, when someone does it once, it's easy to copy. But at the scientist level that just wants to pick something up, change a few little commands in the program, and then be able to utilize this whole data pipeline, that has been really helpful for us. We don't have to involve the programmers in the development of environmental sensors. So, we can kind of just selectively help them prop up a few little things on the far right here if we are doing something fancy.

You know, this has led us to not be shy about doing new prototypes. We sort of focus on the things that are harder for us, which includes the enclosures and what sensors to pick, and how much those cost. And it's really a question of scale. Do we want to go from 5 to 10 to 100? And once we start getting into the hundreds range, you're really down to the dollars or pennies, and you're thinking about well, rather than buy Blues Notecarrier B, maybe I'm going to just onboard all of those components into my own circuit board. It's a really trade off with a microprocessor and sort of a PCB designer on what components go where.

So that's just a real quick overview of you know, we're focused on environmental solutions if we can use this innovative tech to take it, and this has been a persistent problem for 10 years. I can certainly hone in, and I've gone into the modules and manual hosts of cellular modems, and upgraded onboard firmware, and I said I'm never going to do it again. There's only been more options that prove that that's true, and same goes for using LoRaWAN.

So, I think once you get to this simple, you're really just trying to part, what's the data you want to send to the internet? And if that's LoRaWAN, great. And there's a little module that you can just drop in and throw your two little measurements to the internet, you don't have to worry about the overhead and all the custom connection to the telemetry system. That's a lot of handshakes and a lot of overhead that scientists just don't have to deal with.

Speaker: Rob Lauer  50:22

That's awesome. Thanks Ed. I want to say two things. One is that we really did not pay these guys to say any of these great things about Blues so, I appreciate that. Totally unprompted, I promise you. And the second thing is that a copy and paste development, there's no shame to be had in that at all, that's how I made my living.

Speaker: TJ VanToll

And also, that art from the Toledo algae invasion was pretty amazing. I had not seen that before, either.

Speaker: Rob Lauer

Before we get to the Q&A, I did want to take a moment to promote the Blues Wireless Hackster page. We did get one question about more specific use case examples, or guides. And I just want to refer you all here. There are quite a few, like some of these are kind of silly, but some of them at least have a very practical core to them.

We've addressed some use cases like machine learning, asset tracking, remote monitoring, there's a couple environmental monitoring, high level use case examples in here as well. So just head there and check that out, there's a lot of good stuff on that page. And, again, like thank you all very much for attending.

A few final notes before we jump into the Q&A. If you are curious about getting started with a Notecard, and experimenting with wireless IoT, we are offering 15% off any of our dev kits at this URL. The discount will show up in the checkout, by the way. That confuses people. Also, be sure to check out what Clean Earth Rovers and LimnoTech are up to at these URLs.

And with that, I wanted to jump into some of the questions here. And feel free to ask your questions, if you didn't get a chance to already. I do always strive to end these before the top of the hour. So, we'll see what we can do here in a few minutes.

One question that, and this is a really good one, this comes up quite often, like people, I think get kind of thrown off by Notehub, right? This idea that, well, Blues is throwing yet another cloud service in the middle of things. It's another point of potential failure, and it kind of freaks people out. So, somebody asked a question about, can I just send data directly from my device to my cloud or to some endpoint that I created? And the answer is yes and no.

The ‘yes’, answer is that we do offer what we call like a mini version of Notehub. It's a free and open-source version of Notehub, that you can stand up on your own. It's very limited in functionality, but it does let you stand up your own kind of service. The reason I say no is that, by default, the Notecard doesn't live on the public internet, right?

When you turn it on, it knows where to connect in terms of connecting to Notehub, and it does that through private VPN tunnels. So, it never lives on the public Internet. So, it needs a cloud-based proxy, like Notehub.

And as Jonathan mentioned as well, there is a lot of value that we provide in Notehub. So, I understand why people get kind of freaked out. But understand that there's a ton of value we provide in Notehub in terms of security, and with routing data, and working with fleet management and firmware updates, and all that kind of good stuff. So that's my pitch. Let's see, just looking through some other questions here.

Speaker: Ed Verhamme

Yeah, Rob, real quick on that answer. I certainly wouldn't recommend hard coding these sorts of endpoints where your data goes first, because it's just a super challenge once you program these cheap devices and throw them out in the field. If your endpoint changes, you’ve got to reprogram everything. So, I've certainly had an issue with that. And so, again, I think it's just super nice to have that, you know, the first cloud half, you guys control, and you'll always have that ability, and we're just picking up from there. So again, just sort of pile on to that advantage.

Speaker: Rob Lauer

Somebody asked a question about are there any like ready to deploy units? And again, the answer is yes and no, depending on how you really define ready to deploy. We do offer a variety of dev kits that I mentioned, like you can get 15% off there, not to sell you on that again. But we do provide those kits that kind of come with a Notecarrier, a Notecard, and optionally a microcontroller as well. But we don't provide units that like come with an enclosure and provide more of like a turnkey solution.

Ideally, we are kind of selling these as a stepping stone in your prototyping phase. A lot of folks will use a lot of our Notecard + Notecarrier combos during the prototyping phase as they scale up to maybe, you know, 10s or hundreds of units. But then when they scale beyond that, they're generally spinning their own boards and using and embedding the Notecard directly on their boards and such. So, just throwing out some disclaimers there.

One question that always comes up, I don't see it here. And I'm surprised it wasn't asked is about what we mean by global coverage. And I should say that, by global we mean, pretty global. I think it's like 137+ countries that are supported by the main narrowband Notecard, the NBGL model, that we offer. And it's all in our data sheets at dev.blues.io, if you want to look up specific country support.

I should mention too, that we do offer five different models of the Notecard. Two of them are narrowband, one is narrowband global, one is narrowband in the US. And the other ones are the wideband models. So, there's a WBEX that connects to wideband networks in EMEA. And the other is WBNA, which is wideband in North America. And then the final one is the Wi-Fi Notecard. So, there are options really for everybody, depending on your use case.

And let's see, there was a question, as I mentioned, there's a question about a specific use case. And I would refer you to our extra page to get any more like use case specific tutorials. Otherwise, I think we touched on all these during the webinar itself. So, anybody else have any last comments or questions or anything before we wrap it up?

Speaker: TJ VanToll

I’d just say that if you have any Blues-specific questions, if you go to the Blues forum, there's a link on the website. It's discuss.blues.io, that's what I'd recommend. If you post your question in there, we watch it pretty closely so we should be able to help you out. And I also wanted to thank these guys again for hoping in today. This was really awesome, working on some really cool stuff.

Speaker: Ed Verhamme

I just wanted to plug Twitter. I certainly enjoy seeing a lot of these projects and being able to ask questions on Twitter as well.

Speaker: Rob Lauer

Excellent. Well, thank you all very much for attending. And yeah, we'll see you around.