In less than 2 years, a group of strangers has managed to deploy 700,000+ Helium Hotspots worldwide. We’ve got the worlds largest contiguous wireless network built. So, uh, what do we do with it?
I got into Helium because I thought it could be useful to track paragliders back in September of 2020. Like many people, I got way into deploying Helium Hotspots, sometimes going slightly overboard in my enthusiasm to get the absolute best placements. Late 2020 through mid 2021 was an exceptionally joyous and engaging time running around deploying Hotspots in the high backcountry of San Diego.
So, with that 15 month side trip into getting radical with deployed Hotspots about finished up, I’m now returning to the beginning: Using the Helium Network.
I’ve spent a fair amount of time on (and off) trails here in San Diego.
Between my former hobby of ultramarathon running, my current hobby of paragliding (the entire aircraft fits in that backpack), and all that time deploying Helium miners, I’ve probably got more hours on the trail than I’ve eaten burrito breakfasts, and I’ve eaten a lot of burritos.
One thing I’ve noticed is that there aren’t a bunch of park rangers on those trails. Sure, you’ll see ’em occasionally, but it made me wonder: How do they know what’s going on out here? There are only so many rangers, and there’s an awful lot of trail miles in San Diego. Do they use drones? Cameras? How do they keep track of what’s going on?
It may seem like San Diego is a pretty benign place to hike, but we have our share of rescues, mostly centered around heat injuries (people getting overheated, dehydrated, etc). Typically with heat injuries, especially on remote trails, you don’t know that anything’s happened until the person has been missing for a while.
That got me thinking of how I could use Helium to help out. I mean, we’ve built the coverage, we might as well use it. I started poking around on the internet to see what sensors are out there and stumbled on “people counters”. These are small devices that can use an infrared beam between two units, or LIDAR (which stands for LIght Detection And Ranging). Here’s what one looks like:
I thought it might be useful for rangers to know is how many people had gone up the trail vs come back down. I also figured people counters would be useful to know which trails get the most use, so they can deploy assets effectively. Now, I’m not a land management dude, so those were just my initial ideas.
I ran them by a ranger I’d met on the trail, and he was enthusiastic about it. I started talking about a “people counter project” with my Helium homies. I thought maybe I’d just buy one or two devices on my own and deploy ’em just for fun. I talked to a local land owner where I’ve got a Hotspot deployed, and it turned out they had a trespassing problem, so I had at least one “use case”, to count the number of people who trespassing.
Prior to the deployment of people counters, the only thing we’re sure of there is that people ARE trespassing. We don’t know how many, or when, or how often. At the end of that particular trail is a plant called the Lakeside Ceanothus, and it’s only found a few places in the world.
Knowing the amount of trespass will help determine whether or not that landowner needs to figure out a way to stop it, or if it’s not enough to worry about.
As I talked about the project with friends in the general Helium community, Joey Hiller, now Technical Director at the Helium Foundation, suggested I apply for a grant to be able to buy a bunch of people counters, write software to interpret and display the data, and deploy them as part of a project to show anyone how to use Helium.
We went back and forth about what a project that the Helium Foundation would support could look like, I connected with a few other folks at HF and with their help I ended up writing this grant, which was approved.
As you’ll see, part of that grant is helping YOU figure out how to use this magnificent network we’ve built. Let’s start with what’s called the “architecture” of IoT.
In general, the closer you get to technology the more specialized the language becomes and in general, the harder it is to understand without knowing some basic vocabulary. Conceptually the whole thing is straightforward; you deploy some kind of sensor in the field that produces data you can use. If you’re going to get into the business of actually using the network, you’ll need to deepen your understanding beyond the conceptual.
Hang on to your fucking hats here, these next few paragraphs are both complicated and at the crux of understanding this thing in order for you to use it. You may need to read them a few times. This took me days (maybe weeks?) to figure out, so if you only have to read it twice to understand it, consider that a gift of time from me to you.
Let’s start at the beginning of the system, with the thing in the field. You or I might call it a sensor, but technically a sensor is only the actual thing sensing the data input. In this case, it’s a LIDAR sensor. That sensor is connected to a tiny computer, which has a radio module on it. Together, the sensor, the tiny computer, and the radio are called an end-node or device.
Using LoRa, (the Long Range radio protocol) that device transmits a string of data called a payload. This transmission is called an uplink. The payload is received by a gateway, which is what we call a Helium Hotspot. A downlink, in contrast, would be a transmission going from the gateway to the device, usually to reconfigure it (“Send a transmission every 10 minutes, not every minute”, or “Let’s dial down that LIDAR sensitivity a little so we’re counting just people, not moving branches.” Of course, you can’t speak English to a machine. In this case, you have to translate those commands from our human language to decimal and then to hexadecimal.
There are different types of payloads. Sometimes you’ll be using Application payloads, which are ones that configure the data on the uplink, and sometimes they’re Configuration payloads, which ride the downlink and tell the device how to re-configure itself (like the “1 minute to 10 minute” example above).
Riding the downlink, by the way, is completely non-technical. It’s just how I think of it. 🙂
The gateway is connected to the internet by some form of backhaul, which can be anything from cellular to satellite to WiFi or an ethernet cable. The backhaul carries the payload to an LNS, or LoRaWAN Network Server. That LNS can be called “the console”, or in the case of Helium, capitalized and made fancy, Console. On the LNS, the payload is run through a decoder and then sent to an integration.
The decoder takes the string of data from the device and, well, decodes it. The integration takes that decoded data and displays it somewhere, usually on a website where we humans can glance at it and say, “Oh, it looks like 3 people walked right past that NO TRESPASSING sign today.”
As you can see, while it’s conceptually straightforward, actually doing it ain’t particularly simple. At each step of the way a level of technical ability is required to understand what’s going on. It might be hardware expertise required to build or connect a sensor to a module. It could be software expertise, understanding that the payload string is written in hexadecimal and might need to be translated.
To complicate matters further, every manufacturer, including Parametric (the maker of the people counters I’m using) has their own decoder, which might not match up to a Helium specific integration. Those decoders are updated over time, and they can be written in different formats, for example Cayenne LPP, ELSYS, or Extended Payload.
Now, as I said, that took me days to figure out. It DOES make sense, it’s just complicated. I ended up bookmarking the following resources as I went through setting up these People Counters with the help of both Travis Teague at Nova and Nick Hough at Lake Street Software. These are Parametric (the Swiss company that makes these devices) specific, but it should give you a good idea of what you might need in order to understand your own projects.
- Device User Manual for the PCR2-ODS
- Configuration Payload Format (correct version, which as of the time of this writing is v6)
- Application Payload Format
- Device Manager (this allows you to connect to the device via USB instead of wirelessly)
- Command Line Interface (if you want to get seriously geeky)
- Document Library for Parametric (not all useful instructions were in the PCR2 docs)
- Parametric Decoder Examples
- Conversion Tool, Decimal to Hexadecimal and Base64
- Google Sheet to keep track of payloads, work in progress.
Ok, so that was MY list of useful resources. Unless you’re also using the PCR2-ODS from Parametric, you’ll have to build your own, but with that as a guideline you’ll be way ahead of where I was when I started.
In the next post I’ll walk through the process going from buying and importing them to the first test setups. For now, that’s probably enough information. 🙂