Together, LoRa and LoRaWAN define a Low Power, Wide Area (LPWA) networking protocol designed to wirelessly connect battery operated devices to the internet in regional, national or global networks, and targets key Internet of things (IoT) requirements such as bi-directional communication, end-to-end security, mobility and localization services. The low power, low bit rate, and IoT use distinguish this type of network from a wireless WAN that is designed to connect users or businesses, and carry more data, using more power. The LoRaWAN data rate ranges from 0.3 kbit/s to 50 kbit/s per channel.
I really wish standards like WiFi simply covered more usecases like this. All it would take is a few extra modulation and coding modes in the standard.
I should be able to walk 5 miles from my house, and still have my house wifi work, but at a data rate of 0.3 kbps.
I should never have wifi 'cutting in and out' or 'on the edge of the range' - it should be a simple matter of not being fast enough if I'm too far away. If Shannon[1] allows it, the standard should allow it too.
Obviously my phone would probably choose to switch to mobile data long before that. But for some use cases, like instant messaging, 0.3 kbps is fine, and there shouldn't be a need to use a totally different standard to achieve it.
> All it would take is a few extra modulation and coding modes in the standard. [...] but at a data rate of 0.3 kbps.
It would take more than just "a few extra modulation and coding modes". At 0.3 kbps, even a single 100-byte packet would already use up one whole third of the available airtime for the channel. (On the current slowest WiFi speed of 1 Mb/s, that packet takes a fraction of a percent of the available airtime, and even that's slow enough that some newer APs disable the older 802.11b speeds by default and set the slowest speed to 6 Mb/s.) And due to how the WiFi protocol works, each AP periodically (usually every 100/1024 seconds, so around 10 times per second) broadcasts a beacon at the slowest rate it accepts (and AFAIK the beacon is nowadays larger than 100 bytes).
It would probably require at least changing how the clear channel assessment works, to allow for overlapping transmissions, but that's a fundamental part of the standard. Once you're going that far, it probably makes more sense to define a new protocol, one better tuned for that use case.
You'd probably simply have to define that beacons are still sent at 1 Mbps, but define a new 'beaconless' mode which can connect and work from a long distance away without the beacons.
Good news, everyone! There is a WiFi standard for it: 802.11ah[1]. Seems like you can even buy hardware for it[2] today. Its most likely not going to show up in your phone anytime soon, though.
It also wouldn't be trivial from the hardware side. LoRa/NB-IoT/long-range low-speed low-power protocols generally use ISM band of 915 MHz in US and 800 something MHz, with some using 400 ish MHz. That will physically require a completely separate RF path than the 2.45 GHz and 5.8 GHz which WiFi uses. (No, even "integrated wideband transceivers" like AD936x have 1) unusably bad isolation and 2) filtering requirements)
This is also disregarding that "a few extra modulation schemes" is costly to implement. Narrow band schemes (like GMSK) are incompatible with wide band protocols like LoRa or WiFi with spread spectrum/chipping or OFDM. (at least if you are interested in the same performance to price ballpark) Of course many things nowadays use digital baseband so it's in theory flexible, but the front end is still a major limiting factor, unless you use many-GHz RFADC/DAC which still suffer from wide vs narrow band problems.
Also, most long range protocols are meant for ultra low power applications like smart-ag or energy harvesting which WiFi does not support.
Considering the existing amount of congestion with WiFi, if we want to increase range further, we'd likely need more chipping codes to fit in the same frequency allocation, which will increase the noise floor for everybody, thus reducing the range... etc
You'd run the whole thing over the same 2.4G/5G 20/40/80 Mhz channels as wifi, but probably using a gold-code scheme. You'd pre-arrange what code you'll use (perhaps derived from the base station mac address so there aren't collisions even across a city). Simulations would have to be done of high bandwidth close-by unencoded and low bandwidth long distance coded users coexisting, and defining a fairish sharing scheme between them.
The whole thing could probably be implemented with only custom firmware (ie. no hardware changes). All modern GPS's do below-noise-floor reception of GPS signals entirely in software - this would be the same. You might want custom hardware to avoid the rather huge power costs of leaving the main high bandwidth receivers being turned on the whole time though!
You could use the same MIMO mechanisms to get a better channel gain and increase the total amount of data users can transfer in a given city-sized area.
Even with a very directive antenna (or its black magic alternative, beam forming) it would use up a lot of spectrum over those 5 miles to deliver that 0.3kbps, worsening the connectivity of many people all around you. You'd hate it if everyone else was also doing it near you. Battery life would suck too.
Better connect to something else nearer to you, making a fairer use of the available radio spectrum, or if you absolutely need to connect to your own equipment, switch to a protocol more suited for such needs, like LoRa or even a custom-purpose version of Wi-Fi called HaLow (aka .11ah: https://en.wikipedia.org/wiki/IEEE_802.11ah)
Very roughly, every doubling of distance reduces received power and therefore theoretical data rate by a factor of 4. At 20 yards, I can get 2 Gbps out of my wifi, so at 5 miles, I can get 8 kbps with the same transmit power and antennas. Still plenty for instant messaging.
> From what I'm gathering, Canopy can be deployed over unlicensed frequencies (2.4 and 5 Ghz), allows for hundreds of subscribers connecting to a single Access Point, can provide up bandwidth in the 5-10 Mbps range, etc.
You can't beat physics. You'll need some sort of line-of-sight over those 5 miles or at least some path that allows signals to be reflected of something. Unless you venture into frequency ranges and transmit power levels where you can bounce signals off the ionosphere (or the moon), you are pretty limited in range without a repeater.
The closest to what you describe would actually be Bluetooth, but that's also a kitchen sink standard that tried to do everything and ended up with a lot of compatibility and connectivity issues that we still live with today.
LoRa is fantastic for outdoor sensing applications. Shameless plug: I just released a low cost, 3D-printed, LoRa sensor platform: https://www.thingiverse.com/thing:6170483
I appreciate that! It took a lot of trial and error to get it to this point :)
I live on a small hobby farm, and I use these sensors to measure things around the garden. We have very hot, dry summers so keeping track of the soil moisture is super useful. And in winter, it's nice to be able to track when different parts of the property freeze.
Here's a screenshot of my Grafana dashboard, which might shed some more light on it: https://imgur.com/a/vGNnUNW
Well that’s cool! In practice, I believe there are portions of the protocol that are patented, so do some research before using this commercially.
That being said, LoRa is a really interesting protocol. Very adjustable to tune for a use case, somewhat novel modulation scheme. LoRaWAN on top of it is well designed. I implemented it from scratch once and was generally impressed with the design. Easy enough to implement and does a very good job and minimizing how long the radio (both Tx and Rx) need to be on.
"Software patentability is limited in a lot of places"
In Europe, the new Unified Patent Court (UPC) will probably rubberstamp them, using the "as such" and the "technical effect" loopholes. Without any appeal possible to the European Court of Justice.
Sorry, replied to one of the child posts. It's not a software patent, it's a radio modulation patent: https://patents.google.com/patent/US20160094269A1/en and I'm not really that confident that it would be struck down if challenged; from what I'm remembering from digging into it, it is actually a pretty novel form of modulation that has some nice properties for the specific application they're using it for.
I appreciate where your head is at, but I don't think it's very likely that a court is going to agree with you. Contrast to the canonical "One-Click Shopping" patent, this patent covers radio waves of a specific type that you'll be producing and not just an abstract business process. Just because there's a way to violate that patent by writing code for a programmable radio doesn't mean that it's a software patent.
Heck, in the middle ground between "one-click shopping" and LoRa modulation, you have things like audio and video codecs. These are primarily math-based patents, but they have had pretty broad patent protection for a long time compared to more abstract business-process/software patents. Where this might get interesting specifically for LoRa is that France is one of the rare places that doesn't seem to recognize AV codecs as patentable (and which is why VLC is distributed from France) and Semtech is based out of Grenoble!
No, for instance Chirp Spread Sprectrum (mentioned by @tonyarkles in another reply), which is what you would patent (and there are patents on it) has nothing to do with software, although it can be implemented in software using SDR.
It's a very specific form of spread spectrum that they've called Chirp Spread Spectrum and as far as I recall it is actually a pretty novel form of modulation.
The fact that spreading factors are orthogonal as well is also pretty impressive. In the ham space other than FT-8 you don't really see a whole lot of interesting modulation techniques like you do with LoRa. The fact that it works over ISM bands is pretty neat and you can do some impressive things with just a couple ~$20 AT command based radios.
> The fact that spreading factors are orthogonal as well is also pretty impressive
This has been quite standard for 20+ years. For instance 3G spreading codewords are also orthogonal. If fact, I think LoRa took a lot from mobile/cellular where all those technics have been used for a long time.
I guess it depends a lot on what you're trying to use it for. Long-range low-power radio is pretty much guaranteed to suck in a congested environment; the noise floor is going to be high unless you're using narrow-beam point-to-point antennas (with interference both from other devices using the same protocol and other devices sharing the unlicensed spectrum). I've played with it in two environments so far and it has worked fabulously well in both of them:
- Rural sensors attached to things like grain bins, where a pair of AA batteries can last multiple seasons sending periodic temperature updates and alerts if the temperature starts climbing at a faster than expected rate
- Mobile rural sensors worked quite well too. These were attached to things like tractors and had GPS receivers attached for real-time position tracking. Power wasn't nearly as much of a concern but rather taking advantage of the long-range capability while staying inside the unlicensed ISM band and respecting FCC/ISED power limits.
- Low-density urban where the neighbourhoods are made up primarily of single-family homes and not multi-storey condos or apartments. It worked well but honestly something like Zigbee would have likely been a more appropriate technology since it would have allowed for even lower power in the end devices.
Are there legal and plug and play LoRaWAN devices to setup a shell connection? I'm looking for simple alternatives to internet as a last resort server remote access within 10km urban area, eg between offices, to avoid physically moving to an appliance in case something breaks internet connectivity.
I've run a shell over Meshtastic between Lilygo t-beam devices using Semtech SX1262 chips. It kinda works but is sloooooooooooow in proportion to your spreading factor and error correction choices. Internet alternative is overselling it; telemetry and short text messages are ideal, with things like shell access or low-resolution images pushing the boundaries of what is practically doable.
e: rereading I see you're specifying LoRaWAN: that's a protocol on top of the LoRa phy layer stuff, analogous to Meshtastic or Helium, not what's being implemented in this github repo
I have a T-Beam too and it is a fascinating toy, but I'm still searching a good use for it. Currently I employ it as fancy temperature sensor, but it is way overqualified for that job. I'm just curious, apart from disaster and emergency situations, what use cases do you see for a device like the T-Beam?
Backpacking in groups, like the sibling comment said - probably pretty pointless for a quick day hike, but quite nice if you're on a weeklong expedition where folks want to make little side jaunts without dragging the whole group along. I think one thing people don't appreciate is the realtime nature of radios - if someone in my group is off doing stuff, I need to actually pay attention to my radio to make sure I don't miss them trying to reach me. With Meshtastic, I just need to check my phone once in a while - the message will be there.
Similar usecase for overlanding: we also use several different types of voice radio, but an arrow on a map is significantly nicer than "*psssh* crackle we're somewhe...? past the 29?4 crackle turnoff fades out". Being able to mount a fuckoffhuge omni on a vehicle also helps with functional range.
I've also done the backhaul to cellular connectivity thing. Definitely fun but replicable with an inReach.
I use a similar device with Meshtastic for hiking. It's nice to be able to track people and communicate if you're meeting up on the trail and I've found range to be good enough to be useful on a lot of trails even if it's mostly LOS. You can also look at stuff like the Meshtastic ATAK plugin to really get into the deep end of what's possible, too.
I want to experiment with linking back to my car and maybe having kind of cellular back haul to pull in weather and stuff. Cellular is practically nonexistent even at the trailheads most places I hike so the practicality probably is limited but it's fun to tinker with. You can of course buy Garmin satphones that do something similar but with Iridium (i.e., better), but that's way less fun.
While this is true in many cases, it's worth mentioning that many LoRA use cases can get away with high duty cyles no problem.
At the end of the day, the client devices don't have that much broadcast power - so if you run your own LoRA gateway and are not in a densely populated area, nobody cares if you use a lot of bandwidth.
Just don't use all of the bandwidth and keep monitoring the band. You can always throttle down your clients if someone else shows up.
Seeed and RAK make modules that are ~$20 and work over AT commands, however you still need to abide by ISM bands(or relevant band plan for the country you are in) which can limit your duty cycles.
LoRa[WAN] is too limited for this use case. MTUs range from 51 to 242 bytes, and packet loss increases with packet sizes and distance. In addition, it lacks a built-in mechanism for reliability (e.g. ACKs). In other words, lots of headaches, unless your use case is sending non-critical telemetry data up to a few hundreds times per day.
For more information I recommend this paper [1] (unfortunately behind a paywall).
This code works great on a LimeSDR Mini V2. Presumably it will work well with the ANT-SDR as well which makes me think I should get out my ADALM-PLUTO and try it there as well.
While vendors often hide their radio stack in encrypted binary blobs that you load into the "radio half" of their chips having a stack like this where you can look at the parts of the signal is really useful for debugging your own stack. Ideally this will result in opensource implementations of LoRa for things like the STM32W series chips.
Hurricanes are a problem here in Florida and communication can be though during the outage or hours after. My neighbors and I use a specific channel with cheap BaoFengs to check on each other and make sure we are all stocked, but it would be nice to have the ability to text within a group chat (not everyone understands radios, unfortunately).
How can I setup a local area network over radio? I've tried transferring data over the BaoFengs with adapters and a custom app, but it was very slow.
There are lots of tutorials on how to do this with an Arduino and a Lora shield. It just appears as a serial device to the PC. Some friends and I use this type of setup in our car for telemetry in a low budget endurance racing series. It has been pretty bulletproof.
Ettus Research USRPs (Universal Software Radio Peripheral) are popular in academia and defense, especially the B200 series. Their software and FPGA designs are open source, and the schematics for most devices are available online.
Line of sight range is huge, current record is a little over 200 km I think, but practical range is much less. TTN Mapper[1] is a map that shows you estimated approximate range of existing public nodes. The guy behind it also has a good video on Youtube about the algorithms used[2]. The Things Network[3] has has their own map. Finally there is Helium that also has a map[4, but I think you have to participate in their crypto thing to use their network.
Also used in (cubesat) satellite communication. More than 1000 km is common. See for example what has been received by this ground station today: https://tinygs.com/station/Pegasus@5256664939
We use LoRa transmitters/receivers for RC planes and they can easily go tens of kilometers. I've gone 11 km with a tiny, 5mm ceramic antenna on the receiver and 200 mW on the transmitter. It's insane.
Together, LoRa and LoRaWAN define a Low Power, Wide Area (LPWA) networking protocol designed to wirelessly connect battery operated devices to the internet in regional, national or global networks, and targets key Internet of things (IoT) requirements such as bi-directional communication, end-to-end security, mobility and localization services. The low power, low bit rate, and IoT use distinguish this type of network from a wireless WAN that is designed to connect users or businesses, and carry more data, using more power. The LoRaWAN data rate ranges from 0.3 kbit/s to 50 kbit/s per channel.
[1]: https://en.m.wikipedia.org/wiki/LoRa