News from Canada that a LoRaWAN supplier is working to solve LoRaWAN’s inability to deliver good geolocation capabilities for its users, this time adding high power WiFi radios http://bit.ly/2Z68ZT8 to its endpoints. Quick reactions:
– Not long ago we were told that LoRaWAN does geolocation just fine on its own. Fast forward quite a few months and it’s even more obvious that this is not the case.
– Since LoRaWAN can’t do the geolocation job itself, the fix attempted here is to add a new radio. Not an actual location component like GPS, but another radio. And even adding this radio won’t get the job done. This is what I like to call the “Pig’s Picnic” http://bit.ly/2Ff113R — an attempt to contort a technology to be something it was never meant for.
– Adding WiFi to LoRaWAN to make geolocation “work” is another reminder that getting GNSS/GPS or real-time trilateration to work properly on LoRaWAN just isn’t going to happen. If LoRaWAN could support GNSS/GPS in a useable way, it would. But it can’t.
Here are five good reasons to avoid this picnic:
“This hybrid platform combines Wi-Fi and LoRaWAN to enable precise location services for low-cost devices that can be used almost anywhere.”
– Weak geolocation sensing capability. This solution — “sniffing” for SSID’s — fails utterly where there are no SSID’s despite the claim in the press release above. Endpoint wandered into a parking garage with no WiFi? Stored in a room where WiFi doesn’t reach? Wandered into a field with no WiFi access points? Sorry. And if the endpoint doesn’t “smell” an SSID at first, does it keep trying until it does? If so, for how many minutes, hours, or days does it keep trying? Since there is no ability to query a battery powered LoRaWAN endpoint this relies on a time-tested methodology called guessing. Remember, also, that WiFi is a short range technology — 300 feet or so depending on where it is deployed — which is only slightly better than the Bluetooth location problem outlined here.
– Zero situational awareness. A unidirectional endpoint — as battery powered LoRaWAN endpoints are — has no way of “knowing” its own location and can only transmit a message upon an event (e.g. movement) or at some predetermined time interval. Enabling an endpoint to be “aware” that it moved beyond a geofence zone is not a serious option http://bit.ly/2Rpe3D1 with LoRaWAN. So to even attempt a geofencing hack, the endpoint must assume a) it is lost at all times and repeatedly transmit messages while b) repeatedly invoking a WiFi radio to sniff for SSID’s, relying on the gateway to discern whether the endpoint is inside or outside the geofence. This not only needlessly burns battery life but it’s just likely to not provide the location precision, if any, that the end user desires.
– Not so good for IoT indoor location, either. One possible driver of this press release may be an attempt to improve upon the hyper-weak hyper-weak http://bit.ly/2xUiokU indoor location capabilities of LoRaWAN. Indoor deployment has all the downsides of outdoor deployment with the caveat that there are likely to be greater number of WiFi access points indoors. But a LoRaWAN endpoint that beacons its “WiFi” location every 30 minutes is unless to a hospital nurse in an emergency searching for a missing oxygen tank. Indoor location over LoRa requires a query capability for all but the most low value/non-mission critical use cases. A capability with higher resolution location, real-time, not driven by arbitrary time intervals, and a much, much lower power http://www.haystacktechnologies.com/ solution than WiFi.
– Not. Low. Power. WiFi location is more commonly added as a location option to higher-powered devices like smartphones where indoor location may be a desirable feature for advertisers and others. Smartphones, unlike LoRaWAN devices, fully bi-directional radios and end users who don’t mind recharging handsets every evening. Similar to GNSS/GPS, WiFi can burn a battery to zero in a matter of days or hours. WiFi is actually worse, just in terms of power consumption, than GPS as a location technology. For example, “cold start” GPS (i.e. not using A-GPS to achieve a “hot start”) can consume a great deal of power though its peak power consumption is 100mw while joining a WiFi network creates spikes of up to 2 watts. There is a reason you don’t read about WiFi as a serious mobile IoT protocol, especially a low power mobile IoT protocol. As you might imagine, given such spikes the use of small form factor batteries like coin cells is not going to happen with a LoRaWAN/WiFi device.
– Pay-to-Play. One of the nicer aspects of GNSS/GPS is that the signals from satellite constellations are free to developers and in most cases, so are the A-GPS feeds. WiFi location services like the one in this press release require a paid subscription to access. Worth knowing if you like to cost-optimize your bills of materials or wonder what might happen to your customers if the subscription service were to somehow fail or go away.
There is more (we didn’t even get into the requirement for a cloud lookup to do location) but for developers trying to make LoRaWAN work for geolocation just know that you’ve picked a good radio. But bolting on components that were never intended for LPWAN location is doing your customers no favors when there is a clear and better alternative. http://bit.ly/lorawan
Get the latest about Haystack by signing up for our newsletter here.