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.
Recently at least one prominent company announced plans to work on geolocation with this same team, something Semtech announced last summer:
“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:
- One-way only. LoRaWAN only communicates in one direction: from the endpoint to the gateway, and not vice-versa. This means there’s no practical way to ask the device a question like “where are you?” and get an answer. There’s also no way to know if the message sent by a endpoint was received by the access point or gateway.
- Not real-time. You can program a LoRaWAN device to “beacon” every 30 minutes or so, but similar to #1 above, you can’t do a real-time query like “where is my lost dog?” Combine this with the high failure rate of messages sent via LoRaWAN, and you could wait hours to locate a mobile device.
- No real-time indoor location, either. Because LoRaWAN has no peer-to-peer capability and is not real-time, you can forget about locating a mobile endpoint indoors in real-time. So if that laptop with sensitive customer data goes missing in your building, good luck finding it via LoRaWAN. (More on this here.)
- Limited location support. LoRaWAN precludes the use of a Received Signal Strength Indicator (RSSI) which on radios like LoRa is a far more accurate approach to determining location via trilateration/triangulation. In addition, the accuracy of time-based location approaches (like TDOA) correlate positively with available bandwidth and signal-to-noise ratio (SNR) — both of which are quite low on LoRa. In other words, their default GPS-less approach is not very accurate.
- Huge latency. Even if you program your LoRaWAN endpoint to create an alert based on some event (e.g. temperature deviation), the minimum latency between initiating the alert and sending the alert is more than two minutes. If you are attempting to locate something important — like an Alzheimer’s patient or the family dog — that two minute lag might just be less than acceptable.
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.