I’ve written before about Low Power Wide Area Networks (LPWAN’s) and the pros and cons of cellular-based LPWAN’s as well as the same for those non-cellular technologies operating in unlicensed radio spectrum.
One technology we at Haystack like is Semtech’s LoRa LPWAN radio. Long range, low power, and reasonable-ish pricing. Some freeware they helped create called LoRaWAN, however, is not good. We get a steady stream of LoRaWAN refugees who, eager to build a long-range device with multi-year battery life, believed the various misleading statements about its two-way communications capabilities (sorry, not happening), security (really bad), ability to update firmware (you can’t, practically speaking), and a few others. As I’ve said before, serious developers don’t use LoRaWAN and sooner or later, the good ones figure out the truth of LoRaWAN and bail.
But it gets worse.
“LoRa technology has a GPS-free geolocation functionality (LoRa geolocation) that enables a wide range of applications required to determine location as part of the platform.”
Literally speaking, there’s nothing incorrect in the above statement: a LoRa radio can indeed support GPS-free location. In their announcement, they recommend using a time-based approach called Time Difference of Arrival in order to determine the location of a mobile device relative to two or more base stations. Is this the best approach among non-GPS location methodologies? No. But it’s true you don’t need a GPS receiver to acquire and location coordinates … you just use the synchronized clocks on the devices in your LoRa network to make (hopefully) a pretty good guess. (Simply put, if Gateway A is located one mile from an endpoint and Gateway B is located two miles from the same endpoint, it will take longer for the message from the endpoint to reach Gateway B. Then use geometry.)
But where this is all misleading is not in the claims about the Semtech radio itself — which we like and work with every day — but in the networking software stack that sits above the radio. Unwitting LoRa developers find themselves led to use the LoRaWAN freeware that is often marketed alongside LoRa, which is the geolocation equivalent of recommending solitaire as the killer app for a supercomputer.
I’ve written on the pitfalls of LoRaWAN before, but to summarize, here are the basics you need to know before trying LoRaWAN for geolocation on battery powered LoRa IoT devices:
So just to illustrate how absurd the LoRaWAN “geolocation” approach is, a LoRaWAN-based solution might hypothetically work where: a) your mobile endpoint is standing still, ideally for a few hours, b) you don’t need to know its location coordinates in real-time, c) you are OK waiting until the next beacon 30 minutes from now, d) you don’t need very accurate location coordinates, and e) you don’t want to locate anything indoors.
Other than that, it’s great for geolocation.
But this gets to the heart of the issue of developing for the mobile IoT, which I’ve written about here and here: solving for the battery powered LPWAN (e.g. combining long range and multi-year battery life) is not enough when the LPWAN is being deployed on a mobile device. The case of geolocation via LoRaWAN is a perfect example of a LPWAN networking stack that was (expediently) developed without — among a long list of oversights — contemplating the “killer” app for LPWAN devices: mobile, battery powered devices. I’m convinced LoRaWAN was a demo built over a weekend over beer, bad Chinese takeout, and too much Toblerone that some product manager decided to commercialize without informing engineering.
LoRa is a good radio technology. But if you want to do location — indoors or outdoors — over LoRa, don’t use LoRaWAN. Here’s a much better way.
You can reach me via @patdash7 or via email at pat @ haystacktechnologies dot com.
Create your free account to unlock your custom reading experience.