Improving Chirpstack for Helium

The most impor­tant per­son read­ing this may be non-tech­ni­cal. While tech­ni­cal exper­tise is crit­i­cal to accom­plish the goals set out below, much of the ini­tial work done will be “imag­i­na­tion work”, try­ing to fig­ure out how we as a com­mu­ni­ty want to work with, in, and around a new form of access into Helium.

Let’s start with lay­ing out how the sys­tem works, from the sen­sor send­ing out a pack­et all the way until you see that infor­ma­tion dis­played on a screen.

The sen­sor emits a pack­et, the pack­et is received by a Heli­um Hotspot (also known as a “gate­way”), that Hotspot sends it to the Heli­um Pack­et Router. The Heli­um Pack­et Router fig­ures out which LNS to route the pack­et to and sends it there. At the LNS the pack­et is received and decod­ed, then sent out to an Inte­gra­tion, usu­al­ly to be dis­played in a dash­board or some­times as an alert or noti­fi­ca­tion. Whew!

Now, cur­rent­ly that “LoRaWAN Net­work Serv­er” can be either the Heli­um Foun­da­tion Con­sole, or, as in the image, a Chirp­stack Con­sole. Either one is con­sid­ered an LNS.

This flow is dif­fer­ent than a “nor­mal” LoRaWAN net­work because of the addi­tion of the Heli­um Pack­et Router. Now, the HPR is required for this whole thing to work; it coor­di­nates the 400,000 Hotspots across the world. No oth­er LoRaWAN out there has any­thing close to this amount of Hotspots, so they don’t have this problem.

In fact, a typ­i­cal LoRaWAN deploy­ment might have just 2 or 3 Hotspots (they’d call ’em Gate­ways) and would look like this:

So the big dif­fer­ence is REALLY big: 2 or 3 (or maybe 2–3 dozen) Hotspot/Gateways ver­sus 400,000! That’s why at Heli­um we need the HPR.

Ok, so here’s the rub (well, one of a few rubs). Chirp­stack was­n’t built for a net­work like Heli­um. The way it dis­plays infor­ma­tion to the LNS own­er is based on the idea that an LNS will maybe 3 dozen gateways.

By the way, if you want to see and use an actu­al Chirp­stack instance on Heli­um, please check out the Meteo­Sci­en­tif­ic Chirp­stack Con­sole, which I’m run­ning to help nor­mal peo­ple use this fan­cy tech­nol­o­gy. It’s free to sign up for an account, and you get a cou­ple hun­dred DC when you do, which is enough to add your first sen­sor to the net­work and see how it works for yourself.

When you first sign into the Chirp­stack Con­sole, this is what you see:

That’s fan­tas­tic if you only have a hand­ful of gate­ways and you’re real­ly focused on Device Data Rate, but…that ain’t us, which means that out of the 4 dis­plays (Device, Gate­ways, Data Rate Usage, and Gate­way Map) we only see 2, and real­ly, only 1 of those is use­ful to most of us.

So, what should we do?

Since Chirp­stack is open source (you can read all about it here and check out their Github account here), I think we build a bet­ter option. This is either a com­mer­cial oppor­tu­ni­ty (you design a dash­board and sell access to it) or some­thing that the Heli­um Foun­da­tion would be delight­ed to see a grant appli­ca­tion for.

As a gen­er­al thing to start with, I’d like to see some­thing like this, where the LNS own­er gets to see data about the fleet of Hotspots & Devices they’re running.

Now, that prob­a­bly won’t be what it ends up with, and I’d love to hear what YOU would want to see! It might be cool to see most recent device onboard­ed, or a per device DC burn win­dow, or an alert for any device that goes out of some pre-set parameters.

What­ev­er it is, I’m look­ing for­ward to see­ing who is going to build what. It is entire­ly pos­si­ble I’ll have one built for the Meteo­Sci­en­tif­ic Con­sole just to see how it works, so con­sid­er me in the run­ning for help­ing improve this. Now, this’ll work best if we all put our shoul­ders to the wheel togeth­er, so if there is any­thing I can do to help you along the way, please reach out, I’d love to col­lab on this and improve the sys­tem for everyone.

Rock on!