Building a private LoRa network (2017) | Hacker News Reader

Building a private LoRa network (2017)

os.mbed.com

219 pointsTomte73 comments

We deployed a private LoRa (and also an LTE) network on the Greenland ice sheet for one of our experiments. We use LTE for data transfer and LoRAWAN for housekeeping / control (and leave it on during the winter when we have no solar power and are basically just monitoring our batteries). We are taking full advantage of our remote location and Greenland's nebulous ITU region to have them in almost the same band (using LTE band 8 and LoRa in the US ISM band).

The most annoying part was porting LoRaMAC to the samd21, since getting the timing reliable was a bit of a pain. We used the sx1272 as our radio.

We use a Chirpstack backend, which handles authentication and such and passes the unencrypted the LoRaWAN messages over mqtt, which we subscribe to, decode, and stick into a pgsql database on our server on the ice sheet. We then use log shipping replication to get a replica of the database to a server sitting in our lab where we are not bandwidth constrained for monitoring.

What range and with what kind of antennas/power level you're getting?

> and LoRa in the US ISM band

that's 900MHz right ?

So far our farthest stations are about 5 km away from our base station. The RSSI is around -111 dB, this is using ~20 dBm transmit power and 8 dBi omni antennas on both sides (plus of course a few dB of cable loss). Yes, this is in the 915 MHz band.

We tested our LTE network out to about 9 km and it worked, and LoRa should have a better link budget. The frequency is roughly the same.

How did you get started in this line of work?

I went to physics grad school and stuck with it, more or less. Building physics experiments is great if you want to do a whole bunch of things poorly :).

I made a similar guide and a walkthrough video about a year ago, where I cover setup of gateway and TTN, creating a firmware for a device locally, and a lot of other helpful steps and hardware options

https://github.com/furtiman/5lic0-lorawan-basics

https://www.youtube.com/watch?v=A3cZSTfxmb4

Hey I wrote this :-) But back in 2016 or 2017, so some of the practical stuff might be out of date.

How has LoRa adoption been since then? Any interesting applications?

Edit: it seems DASH7 is more widely deployed and apparently LTE-M is being pushed by telecom for IoT using existing 4G towers

https://en.wikipedia.org/wiki/LTE-M

We gave an update on the state of LoRaWAN solutions and applications here: https://www.youtube.com/watch?v=vrHwgRnx6KQ&t=96s

EDIT: This gives a great overview of all the available LoRaWAN devices out there: https://www.thethingsnetwork.org/device-repository/

CBRS LTE is also a thing if you have 3550-3700MHz

Year added above. Thanks!

As this operates in the "Open Spectrum" I suspect it's very geographically constrained, as the spectrum is allocated differently from country to country. I would have to check but I'm not sure there's an equivalent in the UK, for instance, which you could operate without an amateur radio license.

EDIT: Scratch that, looks like there's a frequency it can use in the UK:

"Both LoRa™ and LoRaWAN® use the 868Mhz radio frequency that is license exempt in the UK. This doesn’t mean you can use this frequency as you like. There is set a set of rules defined by EU ETSI EN300.220 (pdf) the most pertinent of which is the duty cycle that defines for how long a transmitter can transmit."

Same as the article says to use in Europe. Probably an EU rule that carried over.

I'm from The Things Industries and The Things Network team. LoRaWAN standard specifies regional parameters, that is - specific ISM spectrum bands for every region where LoRaWAN is used. All of the regional parameters are supported by The Things Network and The Things Stack, you would only need to get hardware that has the radio of the frequency you need. It is specified in here (https://www.thethingsnetwork.org/docs/lorawan/frequencies-by...) and in LoRa Alliance standard https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1...

FWIW, for building your own private network, there is no need to rely on something like TTN (hosted by someone else - isn't that a contradiction in itself?). ChirpStack (https://www.chirpstack.io/) is a very mature and easy to deploy LoRaWAN suite that's worth looking at!

Fair point. The Things Stack - the server that is hosted by TTN - can also be installed and run locally for free, with the same feature set as the TTN hosted community network.

https://www.thethingsindustries.com/docs/getting-started/ins...

https://github.com/TheThingsNetwork/lorawan-stack

Whether you believe in the crypto aspect of it or not, the Helium network provides really good public LoRaWAN connectivity in a lot of places. Much easier than building out the whole network, including gateways and the backend. The cool part is that the LoRaWAN protocol allows you to keep your data totally encrypted to your app, and still use public networks.

Do you know of a tutorial for getting a small LoRa device up on the Helium network?

You can start with the basic console documentation: https://docs.helium.com/use-the-network/console

Helium is interesting because its literally everywhere in the US and western europe, everywhere people exist that is (not super remote mountainous regions).

I'd bet 99% of people reading this comment section have great coverage.

Unfortunately, I would not build a business that relied on the Helium network because there's no way to tell if they're going to be around in a year or two. The main alternative - The Things Network - is quite popular in Europe but has less penetration in North America, unfortunately.

i actually build a device which is using both TTN and Helium exactly for that reason. https://notific.at/en

I am fascinated by LoRa, but I understand it is primarily for low bandwidth applications that are optimized for high range, low power consumption. I'd imagine LoRA would be a good alternative to SMS but would it ever be an alternative for voice or higher bandwidth applications while still maintaining long range and low power?

Nope, it's not meant for that. Think low-bandwidth, small transmissions with highly compact but valuable data (sensors, actuators, etc). Even with LoRa as-is, changing settings to optimize for bandwidth costs you real range.

What is the sweet spot in terms of bandwidth and packet size?

https://www.thethingsnetwork.org/docs/lorawan/spreading-fact...

There is none, there are only tradeoffs.

You're basically directly trading off range for speed and power usage.

Quicker chirps allow for both higher speed and lower power usage per byte transferred, but your range will be that much lower

Exactly. Not LoRa but an example of what these modules and low bandwidth can do.

Many years ago (pre-LoRa) I needed to integrate a garage door that was far out of Wifi range to my home automation system.

At the time the way to go about this was (as best as I could tell) XBee. I was able to conjure together a 900 MHz XBee module in the garage that not only had (essentially) GPIO to activate a momentary relay to simulate a button push to control the door but also utilize an XBee feature called change detection that has an eventing/push system to transmit state changes from high to low on a pin. Combined with a magnetic door contact sensor and XBee + ESP 8266 + Arduino (platform for ESP 8266, not device) + MQTT on the Home Assistant side this thing has been running rock solid for a decade. I haven't had to work on it since.

Whether I check the status of the door (via Home Assistant or the OLED display on the control unit inside) or open/close the door via the momentary switch inside (or Home Assistant) even though it's been 10 years at least once I week I remark at how amazing the entire contraption is.

This stuff is really cool and maybe it's time to move this thing to LoRa!

Probably not worth it, Zigbee is literally designed for use case like that, LoRa is designed for use cases where you'd have much wider geographical spread of sensors.

But something like solar powered sensor somewhere farther away would be a good use case.

Good to hear you concur on Zigbee/XBee but absent any other projects coming up I looking for an excuse to play with LoRA!

Speaking of costs, are the public gateways actually free to use or does one need something like a sim card to use them? What prevents people from spamming messages at rates that completely clog the network?

If we are talking about the radio spectrum: Not much - other than the threat of the regulators showing up at your doorsteps after they found you with a van. If you are talking about the backbone so to say, it's not such a big Issue. The original packet-forwarder sends "json" over UDP. If you are using a packet-forwarder by one of the network operators, some of them are using MQTT (IP/TCP) as the transport.

Some gateways let you filter by network_id, this will not stop someone from pulliting/disrupting the radio spectrum, but it will stop your gateway from relaying those packets to your network-server.

LoRa is not a panacea, and of course any technology is best to what it is intended. With its ultra low power and data constraints LoRa is not aimed at high-bandwidth applications.

The perfect application is IoT, where a lot of use cases like telemetry, agriculture, etc. require only small data packets transmitted with longer (tens of minutes / hours) intervals.

Personally I'd see some use in regional and low bandwidth sensor data, like broadcasting weather station data.

If everyone having a phone in their pocket at all times has taught me anything, it's that people hate talking to each other over the phone... :-). LoRA/Meshtastic seems like a really interesting SMS transit.

Me too. I envision a pebble like smartwatch or an eink phone with Lora.

Lora on 2.4 GHz can probably provide the higher bandwidth required for voice albeit at a lower range compared to the sub-GHz version. look up SX1280.

No radio transmission that is above 30 MHz or so is really "high range". The modulation doesn't matter. The only thing that matters for range in non-ionospheric bouncing radio transmissions is the height above surrounding terrain of both ends of the link.

SMS works because the cell phone companies pay the big bucks to their base stations up very high above surrounding terrain.

There are transient exceptions like atmospheric gradients in water vapor density creating brief tropospheric ducts which VHF radio can bounce down but these are unreliable. And tropospheric scattering propagation requires very high powers and high gain antennas at both ends so it's not really feasible for people operating under FCC part 15 or even ham radio power restrictions (ie, <1500 watts).

LoRa isn't even a good alternative for SMS. The duty cycle, at least in Europe is too low to have a real-time conversation.

By duty cycle are you referring to slow message latency and small packet size?

No, here in Europe a device on the LoRa band 868Mhz can only transmit 1% of the time by law.

Because this also applies to base stations the throughput is highly constrained.

LoRa is proprietary and patented. LoRaWAN as well. There are open patent-free alternatives.

Let's not fall into the proprietary trap again.

The problem with LoRa is that you can't (or atleast shouldn't) control the frequency from software.

Which is exactly what you want. Also the frequency band is a bit too narrow and short ranged for real earth applications.

LoRaWAN is terrible because you move into the overengineered and heavy IP stack... the other way is better: build your own "from scratch" network topology in software.

Fossilization is only good _after_ you prooved the concept.

I recently got interested in installing a TTN gateway in my home and adding some temperature sensors.

Having played with LoRa years ago my thought was that there should now be readily available and cheap sensors. But to my disappointment everything seems to be a bit pricey which really surprised me. I can get a Zigbee temp sensor for around 15 euros, but Lora sensors cost around double that. I am wondering as to why that is?

The market for Zigbee products is likely much larger so per-unit costs are lower.

Also, it seems LoRa is proprietary and patent-encumbered while Zigbee is an open spec.

Still need to pay up if you want to sell zigbee devices

https://e2e.ti.com/support/wireless-connectivity/zigbee-thre...

...which is also the reason Zigbee is more pricy than random wifi enabled gadget

Zigbee can’t be that expensive, since you can pick up IKEA TRÅDFRI Zigbee bulbs for around €6 a piece.

This is pure speculation - I have no prove. I believe is also due to the target buyer: afaik the biggest adopters are municipalities and not general consumers.

I somewhat recently blogged about my process of setting up a private LoRaWAN network as well.

https://prbs23.com/blog/posts/getting-started-with-a-private...

LoRaWAN is definitely an interesting mix of open source implementations and open specifications, and proprietary poorly documented hardware. Unfortunately I haven't had time lately to actually use my network for anything real.

Anybody played with Mikrotik KNOT LR8 kit? I like them but it's new and I want something reliable when I'm learning

I can confirm it works well, Mikrotik have good experience in LoRa gateways and have been in the market for quite some years

I just finished two-year project to build a sensor data acquisition system that was based around private LoRaWAN networks. Our custom gateway was Chirpstack running on a little linux SBC connected to a RAK LoRa module.

It took some effort to solve congestion and reliability when the network got busy.

It's patented and proprietary, please don't use it.

Alternatives: https://en.wikipedia.org/wiki/Low-power_wide-area_network#Pl...

While the LoRa radio modulation (phy) is licensed by Semtech, the MAC layer protocol - LoRaWAN is completely open and is free to be used, implemented and tinkered with. https://lora-alliance.org/

Many implementations are also open-source, like The Things Stack from The Things Network. It can also be run locally.

https://github.com/TheThingsNetwork/lorawan-stack

I'd want the entire stack to be open and free. When Layer 1 is closed and proprietary, I don't really care if I can build open source on top of it, in Layer 2.

Is this not the case with existing computers and phones? We build and run OSS on top of them.

It is, and there is a lot of effort being expended to remediate that - there's a reason why some people use pre-2011 thinkpads. I think it would be pragmatic in new endeavors to do things right and correctly from the start, so that remediation isn't needed later.

There have been many commercial and crowdsourced attempts to do so, with variable levels of success.

Do you buy or participate in those?

I care, but not enough to leave my iPhone (more specifically: the functionality, usability, and reliability it provides) behind, at this point.

There's a link upstream of fully OSS LoRa alternatives. Your question to me makes no sense: it's like asking if the developers of those alternative technologies use 5G-enabled phones, even though those also use proprietary technologies.

Maybe I should clarify: existing tech is what it is. We probably have to use it. But if we're building new tech, why would we waste time doing it incorrectly, when we have the chance to do it right?

> I care, but not enough to leave my iPhone

Then you really don't care.

Sorry, I know that sounds flippant, but hardware manufacturers have become exceptionally good at calibrating this "just enough tyranny to wear down the majority" thing. It's exactly this "not enough to leave my iPhone" attitude that they've figured out how to exploit.

Haven't we learned the lesson yet? Let's not fall into the proprietary trap again.

Was Chirp Spread Spectrum developed prior to LoRa itself out of interest? I had a little look at https://en.wikipedia.org/wiki/Chirp_spread_spectrum but couldn't really tell.

I was under the impression that other modulation schemes such as FSK etc. can also perform similarly to CSS in terms of data rate etc. and distance?

any specific recommendation? it seems like all of these alternatives have tradeoffs and LoRa really does seem to tick more boxes than the others.

I don't, sorry.

It's a few years since I researched it, and I didn't build anything.

From that list of alternatives, which of the open ones have the widest adoption/support?

Why should we not use something that is proprietary? Every transceiver IC in the world is proprietary.

Now do the same for Helium!

Reply on news.ycombinator.com