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.
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.
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
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."
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.
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.
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.
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.
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?
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 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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?
You're not entirely wrong, but it's a very common radio technology, which anyone is free to use (even implement from scratch, with enough skills) with very few restrictions (which don't really affect state actors).
You may as well ban screws, lenses, explosives, radio, rubber, chocolate and internal combustion engines with this line of reasoning. What will it achieve? Russia won't stop using them.
Well, some Russian car factory stopped because they couldn't get screws. Also, they couldn't make their own screws, because the screw-making machine had wear parts which they couldn't get.
Of course they won't stop using these common components altogether, but the idea is to increase the cost of waging war.
"Critical thinking is good; shallow cynicism, on the other hand, adds nothing of value to the community. It is unpleasant to read and detracts from actual work. If you have something important but negative to say, that’s fine, but say it in a respectful way."
Even if they wrote down something about forbidding military usage, there would be no way to actually enforce that if the country doesn't care about license, EULA, etc.
So all that does in effect is absolutely nothing other than political posturing.
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.