The People Counter Project: Beginnings

In less than 2 years, a group of strangers has man­aged to deploy 700,000+ Heli­um Hotspots world­wide. We’ve got the worlds largest con­tigu­ous wire­less net­work built. So, uh, what do we do with it?

I got into Heli­um because I thought it could be use­ful to track paraglid­ers back in Sep­tem­ber of 2020. Like many peo­ple, I got way into deploy­ing Heli­um Hotspots, some­times going slight­ly over­board in my enthu­si­asm to get the absolute best place­ments. Late 2020 through mid 2021 was an excep­tion­al­ly joy­ous and engag­ing time run­ning around deploy­ing Hotspots in the high back­coun­try of San Diego.

So, with that 15 month side trip into get­ting rad­i­cal with deployed Hotspots about fin­ished up, I’m now return­ing to the begin­ning: Using the Heli­um Network.

I’ve spent a fair amount of time on (and off) trails here in San Diego. 

Between my for­mer hob­by of ultra­ma­rathon run­ning, my cur­rent hob­by of paraglid­ing (the entire air­craft fits in that back­pack), and all that time deploy­ing Heli­um min­ers, I’ve prob­a­bly got more hours on the trail than I’ve eat­en bur­ri­to break­fasts, and I’ve eat­en 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 occa­sion­al­ly, but it made me won­der: 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? Cam­eras? How do they keep track of what’s going on? 

It may seem like San Diego is a pret­ty benign place to hike, but we have our share of res­cues, most­ly cen­tered around heat injuries (peo­ple get­ting over­heat­ed, dehy­drat­ed, etc). Typ­i­cal­ly with heat injuries, espe­cial­ly on remote trails, you don’t know that any­thing’s hap­pened until the per­son has been miss­ing for a while.

That got me think­ing of how I could use Heli­um to help out. I mean, we’ve built the cov­er­age, we might as well use it. I start­ed pok­ing around on the inter­net to see what sen­sors are out there and stum­bled on “peo­ple coun­ters”. These are small devices that can use an infrared beam between two units, or LIDAR (which stands for LIght Detec­tion And Ranging). Here’s what one looks like:

I thought it might be use­ful for rangers to know is how many peo­ple had gone up the trail vs come back down. I also fig­ured peo­ple coun­ters would be use­ful to know which trails get the most use, so they can deploy assets effec­tive­ly. Now, I’m not a land man­age­ment dude, so those were just my ini­tial ideas.

I ran them by a ranger I’d met on the trail, and he was enthu­si­as­tic about it. I start­ed talk­ing about a “peo­ple counter project” with my Heli­um 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 own­er where I’ve got a Hotspot deployed, and it turned out they had a tres­pass­ing prob­lem, so I had at least one “use case”, to count the num­ber of peo­ple who trespassing. 

Pri­or to the deploy­ment of peo­ple coun­ters, the only thing we’re sure of there is that peo­ple ARE tres­pass­ing. We don’t know how many, or when, or how often. At the end of that par­tic­u­lar trail is a plant called the Lake­side Cean­oth­us, and it’s only found a few places in the world. 

Know­ing the amount of tres­pass will help deter­mine whether or not that landown­er needs to fig­ure out a way to stop it, or if it’s not enough to wor­ry about. 

As I talked about the project with friends in the gen­er­al Heli­um com­mu­ni­ty, Joey Hiller, now Tech­ni­cal Direc­tor at the Heli­um Foun­da­tion, sug­gest­ed I apply for a grant to be able to buy a bunch of peo­ple coun­ters, write soft­ware to inter­pret and dis­play the data, and deploy them as part of a project to show any­one how to use Helium.

We went back and forth about what a project that the Heli­um Foun­da­tion would sup­port could look like, I con­nect­ed with a few oth­er folks at HF and with their help I end­ed up writ­ing this grant, which was approved. 

As you’ll see, part of that grant is help­ing YOU fig­ure out how to use this mag­nif­i­cent net­work we’ve built. Let’s start with what’s called the “archi­tec­ture” of IoT.

In gen­er­al, the clos­er you get to tech­nol­o­gy the more spe­cial­ized the lan­guage becomes and in gen­er­al, the hard­er it is to under­stand with­out know­ing some basic vocab­u­lary. Con­cep­tu­al­ly the whole thing is straight­for­ward; you deploy some kind of sen­sor in the field that pro­duces data you can use. If you’re going to get into the busi­ness of actu­al­ly using the net­work, you’ll need to deep­en your under­stand­ing beyond the conceptual.

Hang on to your fuck­ing hats here, these next few para­graphs are both com­pli­cat­ed and at the crux of under­stand­ing 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 fig­ure out, so if you only have to read it twice to under­stand it, con­sid­er that a gift of time from me to you. 

Let’s start at the begin­ning of the sys­tem, with the thing in the field. You or I might call it a sen­sor, but tech­ni­cal­ly a sen­sor is only the actu­al thing sens­ing the data input. In this case, it’s a LIDAR sen­sor. That sen­sor is con­nect­ed to a tiny com­put­er, which has a radio mod­ule on it. Togeth­er, the sen­sor, the tiny com­put­er, and the radio are called an end-node or device.

Using LoRa, (the Long Range radio pro­to­col) that device trans­mits a string of data called a pay­load. This trans­mis­sion is called an uplink. The pay­load is received by a gate­way, which is what we call a Heli­um Hotspot. A down­link, in con­trast, would be a trans­mis­sion going from the gate­way to the device, usu­al­ly to recon­fig­ure it (“Send a trans­mis­sion every 10 min­utes, not every minute”, or “Let’s dial down that LIDAR sen­si­tiv­i­ty a lit­tle so we’re count­ing just peo­ple, not mov­ing branch­es.” Of course, you can’t speak Eng­lish to a machine. In this case, you have to trans­late those com­mands from our human lan­guage to dec­i­mal and then to hexa­dec­i­mal.

There are dif­fer­ent types of pay­loads. Some­times you’ll be using Appli­ca­tion pay­loads, which are ones that con­fig­ure the data on the uplink, and some­times they’re Con­fig­u­ra­tion pay­loads, which ride the down­link and tell the device how to re-con­fig­ure itself (like the “1 minute to 10 minute” exam­ple above).

Rid­ing the down­link, by the way, is com­plete­ly non-tech­ni­cal. It’s just how I think of it. 🙂 

The gate­way is con­nect­ed to the inter­net by some form of back­haul, which can be any­thing from cel­lu­lar to satel­lite to WiFi or an eth­er­net cable. The back­haul car­ries the pay­load to an LNS, or LoRaWAN Net­work Serv­er. That LNS can be called “the con­sole”, or in the case of Heli­um, cap­i­tal­ized and made fan­cy, Con­sole. On the LNS, the pay­load is run through a decoder and then sent to an inte­gra­tion.

The decoder takes the string of data from the device and, well, decodes it. The inte­gra­tion takes that decod­ed data and dis­plays it some­where, usu­al­ly on a web­site where we humans can glance at it and say, “Oh, it looks like 3 peo­ple walked right past that NO TRESPASSING sign today.”

As you can see, while it’s con­cep­tu­al­ly straight­for­ward, actu­al­ly doing it ain’t par­tic­u­lar­ly sim­ple. At each step of the way a lev­el of tech­ni­cal abil­i­ty is required to under­stand what’s going on. It might be hard­ware exper­tise required to build or con­nect a sen­sor to a mod­ule. It could be soft­ware exper­tise, under­stand­ing that the pay­load string is writ­ten in hexa­dec­i­mal and might need to be trans­lat­ed.

To com­pli­cate mat­ters fur­ther, every man­u­fac­tur­er, includ­ing Para­met­ric (the mak­er of the peo­ple coun­ters I’m using) has their own decoder, which might not match up to a Heli­um spe­cif­ic inte­gra­tion. Those decoders are updat­ed over time, and they can be writ­ten in dif­fer­ent for­mats, for exam­ple Cayenne LPP, ELSYS, or Extend­ed Pay­load.

Now, as I said, that took me days to fig­ure out. It DOES make sense, it’s just com­pli­cat­ed. I end­ed up book­mark­ing the fol­low­ing resources as I went through set­ting up these Peo­ple Coun­ters with the help of both Travis Teague at Nova and Nick Hough at Lake Street Soft­ware. These are Para­met­ric (the Swiss com­pa­ny that makes these devices) spe­cif­ic, but it should give you a good idea of what you might need in order to under­stand your own projects.

• Device User Man­u­al for the PCR2-ODS
• Con­fig­u­ra­tion Pay­load For­mat (cor­rect ver­sion, which as of the time of this writ­ing is v6)
• Appli­ca­tion Pay­load Format
• Device Man­ag­er (this allows you to con­nect to the device via USB instead of wirelessly)
• Com­mand Line Inter­face (if you want to get seri­ous­ly geeky)
• Doc­u­ment Library for Para­met­ric (not all use­ful instruc­tions were in the PCR2 docs)
• Para­met­ric Decoder Examples
• Con­ver­sion Tool, Dec­i­mal to Hexa­dec­i­mal and Base64
• Google Sheet to keep track of pay­loads, work in progress.

Ok, so that was MY list of use­ful resources. Unless you’re also using the PCR2-ODS from Para­met­ric, you’ll have to build your own, but with that as a guide­line you’ll be way ahead of where I was when I started.

In the next post I’ll walk through the process going from buy­ing and import­ing them to the first test setups. For now, that’s prob­a­bly enough information. 🙂

Rock on!