The IoT doesn’t appear on award-winning TV that often, but if you liked the TV series “Breaking Bad”, you might also be watching its prequel, “Better Call Saul”. Without giving away the plot, this season a small, long-range GPS tracking device is prominently featured in multiple episodes and, well, the battery doesn’t last very long.
You can watch for yourself — I highly recommend it for both the screenwriting and the acting — but I’m glad to see the issue getting popular visibility because in the LPWAN corner of the IoT where some of us live, we have yet to have “the talk” about a huge challenge: GPS melts LPWAN battery life.
So this piece is about implementing GPS in the low power IoT. As you probably know, LPWAN’s are supposed to be low power devices which implies … no AC power connection. If you are thinking about fixed or non-mobile LPWAN endpoints, then you have no need for GPS and reading this article is probably a distraction from being productive. But if you are deploying mobile LPWAN endpoints, read on.
Asset Tracking
A major use case for LPWAN’s is what analysts boringly refer to as “asset tracking”. In my native pleb-speak this translates to “where is my stuff?” Tools, dogs, cows, bicycles, weapons, shipping containers, Alzheimer’s patients … the list of asset tracking use cases is extremely long.
I’ve touched on locating things in the IoT here and here and I’ve noticed how some LPWAN technologies make ridiculous claims about their ability to locate things outdoors. But here’s a fact: deploying GPS on a LPWAN device is hard.
GPS — LPWAN Facts
Many developers think they know how GPS works but if you have doubts and think you could use a refresher, try this. To compute its location, an IoT device needs to acquire GPS signals from at least three but ideally four out of 32 GPS satellites orbiting the earth.
32 birds, orbiting on six separate planes
But what most also don’t know is that GPS is a very slow communication channel — just 50 bps! — which means the amount of time your little mobile LPWAN device must be “on” in order to receive GPS messages (technically 37,500 bits per message, per satellite) can be multiple minutes in order to acquire the GPS coordinates being sought.
Let’s Try this with LoRaWAN
We could pick on Sigfox here, but that would be too easy so let’s further illustrate the battery impact of GPS on a LPWAN device by assuming you are using a one-way LPWAN networking stack for Semtech LoRa devices called LoRaWAN. Since it’s a one-way device, assume it emits a periodic one-way beacon with GPS coordinates every 30 minutes to track a valuable piece of construction equipment at a job site. Why use a beacon? Because with a one-way protocol like LoRaWAN there is no way to query “Where is my chainsaw?” if the chainsaw goes missing.
So assuming an acquisition time of 2 minutes for all four satellites multiplied by 48 times per day, your GPS module is already working a total of more than 1.5 hours a day. Divide the 1,000 hours of your AA battery by 1.5 hours of GPS duty per day and you might get just over one month of battery life.
But, alas, even those 42 days are only theoretical since this calculation doesn’t include a number of other battery-consuming factors:
- Flutter. If your LPWAN device has an obstructed view of a satellite (chainsaws may be locked in a shed or the passenger seat of a pickup truck) or the device is moving (highway overpasses, tall buildings, etc.) a GPS receiver can experience “flutter”, causing the receiver to work overtime to search for error-free GPS packets. If the flutter is bad enough, this can take a LONG TIME and further deplete your battery in the process.
- GPS “idling”. GPS receivers don’t do a good job of retaining satellite location information while in a low power state. If you want to keep satellite location data fresh in your mobile device’s memory so that the next time your device tries to acquire GPS info it can do it faster, you’ll need to budget a continual flow of power — approximately 0.44 milliamps on average — or risk needing to acquire GPS from a “cold start”. GPS satellite info has a shelf-life of four hours so at a minimum you will need “fresh” satellite info at that interval. The 0.44 milliamp average is a weighted average of idle power and GPS on time for a system sampling GPS every 30 minutes.
- The radio. Acquiring GPS coordinates is not enough as you’ll have to transmit them to a gateway. This is in addition to any other messaging your device might do.
- The MCU and the rest. Your mobile device needs to do everyday computing tasks managing whatever onboard sensors, radios, memory, etc. it is carrying. This burns battery life.
So it’s no wonder we haven’t seen more action with GPS and LPWAN’s. Practically speaking, for most LPWAN protocols (but not all!), GPS is like going swimming with a 35-pound kettlebell tied to your ankle.
For Outdoor LPWAN Location Start With RSSI
I’ll explain how to overcome GPS hell on a LPWAN device below, but the first step in getting around the seemingly massive obstacles starts by not using GPS at all. Instead, we recommend allowing a gateway to take received signal strength indicator (RSSI) measurements from a mobile device and in some cases trilaterating (similar to triangulation) their measurements using multiple gateways.
Example of Non-GPS trilateration over cellular
Theoretically, even some of the notoriously bad networking stacks like LoRaWAN or Sigfox can do something like this (LoRaWAN tries to market trilateration using a time-based method called Time Difference of Arrival, since the protocol can’t support RSSI, which is a superior approach for reasons I don’t have room for here.) With LoRaWAN your mobile device will a) need plenty of LoRaWAN gateways in range, b) better stand still for 30 minutes, and c) not know if your location beacon was received by the gateway. (LoRaWAN packet loss is legendary.)
Our experience with trilateration is that the accuracy of the estimated location can vary from surprisingly accurate — say, within 25 meters — or wildly off — by a mile or more— depending on the number of available gateways, terrain, RF environment, movement of the mobile device or the gateway, and more.
There’s nothing wrong with RSSI-based trilateration, in fact we recommend it as part of your outdoor (and indoor) location technology portfolio, but implemented with one-way LPWAN protocols won’t work for most of us. Haystack does this with DASH7 in a far more efficient and relevant way, as you’ll see below.
The Importance of Real-Time Location
We hear about asset tracking every day at Haystack but ultimately it’s about asset tracking in real-time. That is, answering the everyday question “Where is it?” As in, “Where is my power drill?” or “Where is my bag of electronic equipment?” or “Where is my husband?”
Some customers want to know the location of things and don’t like being told to wait
Rarely or never is the question: “I am looking for my champion Poodle, but hey no rush! Just get back to me with an approximate location sometime in the next 30 minutes or the next day and that will be just fine …” No, the question is almost invariably “I need to find my Poodle … RIGHT NOW.” And for most use cases, the end user wants to repeat the question again two minutes later. And again. And again. When you think about it, anything that is mobile that is worth enabling with a LPWAN tracking device is usually valuable enough to require asking this question and receiving an answer in real-time. Unless you don’t really love your Poodle.
So at Haystack we’ve invented a portfolio of solutions to help the LPWAN + GPS community that are uniquely achievable via the networking firmware stack Haystack invented and patented, DASH7.
The Importance of On-Demand in the IoT
I’ve written before about the importance of allowing endpoints to remain in a “listen-before-talk” mode rather than engaging in constant chattering and needless handshaking. Benefits include power savings, real-time queries, real-time location, better privacy and security options, and more. But when dealing with a feature as power-intensive as GPS, on-demand capabilities become paramount.
On-Demand RSSI Queries
As a first step in answering the “where is it right now?” question, we recommend starting with an on-demand RSSI query. Rather than invoking GPS on a mobile device, it may just be more practical to “probe” for a device’s location using a simple test of signal strength from a gateway that serves as a proxy for whether the mobile object (in the above use case, a chainsaw) is within an acceptable distance from the gateway/access point. A strong signal whose value is ≥x may give an owner peace of mind that the chainsaw is nearby.
A weaker signal whose value is ≤x might trigger either a trilateration sequence, e.g. for a device that is moving use repeated queries to the mobile device to measure changes in signal strength and for a fixed device use either a mobile gateway or multiple gateways. For those of you familiar with geofences, it’s possible to construct one using RSSI values.
On-Demand GPS
If your on-demand RSSI query shows a signal that is ≤x (i.e. meaning it is located somewhere outside your geofence) and you want more precise location coordinates, you can invoke a GPS receiver on a LPWAN device.
Assuming a 16 milliamp GPS receiver and a AA battery, invoking standard GPS on a LPWAN device is something most developers will want to do only sparingly or, if you plan to execute repeated queries, ideally when an item occasionally goes missing and not daily or even weekly. So for example, let’s say the chainsaw on a construction job site goes missing on average once every two weeks and the end user — frantic at the thought of having to tell the boss that he spent an hour looking unsuccessfully for the chainsaw again and couldn’t find it — invoked GPS five different times before recovering the chainsaw. Using DASH7 technology from Haystack, using an on-demand GPS approach is much better than the beacon approach:
It’s important to repeat that 750 days battery life modeled here is theoretical and doesn’t take into account flutter, other device duties, etc. but using an on-demand (real-time query) approach to invoking GPS is vastly better than the concept of the same device acquiring and beaconing GPS coordinates at preset intervals.
On-Demand Assisted GPS
But let’s say you are modeling GPS usage for an upcoming LPWAN project but you are concerned that the end users you have in mind might not read your documentation that says to use GPS sparingly and instead might pummel the battery with nonstop queries. Think: lost dementia patients, lost family dogs, a lost vintage Fender Stratocaster pre-performance at Lollapalooza, etc. Or that obstructions might be more common than normal and acquisition times might be longer. Even on-demand GPS (along with on-demand RSSI probing or geofencing) with Haystack might not be enough to prevent a fast dead battery.
One of the more exciting things we are implementing at Haystack is Assisted GPS or “A-GPS”. If you are interested in learning more about A-GPS go here, or if you prefer pictures, here is one:
Basically A-GPS is a way of providing information to a LPWAN device, via a gateway, to help it acquire GPS satellite coordinates much more quickly than without A-GPS. As in, shrinking acquisition and processing time from 2 minutes to 20 seconds.
A-GPS information includes information about the location of all 32 satellites orbiting the earth for a given time of day and location, time, satellite health information, etc. The total data payload is typically around 1KB. A-GPS is used extensively in cellular telephony and is one of the reasons it doesn’t take your iPhone two minutes to acquire GPS coordinates when you use Apple Maps.
But to send A-GPS information to mobile LPWAN devices requires a fully two-way networking communications protocol, preferably with with robust multicast and broadcast capabilities, like the kind you get with Haystack. For example, rather than have a group of LPWAN cow tracking devices attempt unassisted GPS location acquisition, a DASH7 gateway can simply multicast A-GPS information as it becomes available. Endpoints could request A-GPS information individually but multicast is faster and more efficient.
As is probably obvious by now, A-GPS is a no-go with LoRaWAN, Sigfox, and other one-way or similar protocols. But using the same lost chainsaw example from above shows how impressive the battery life extension with A-GPS can be using Haystack:
There are multiple providers of A-GPS information that your LPWAN gateway can access. Here’s one from u-Blox who offer their A-GPS location services free to their OEM customers.
Needless to say, we are big advocates of A-GPS for LPWAN’s for those customers looking for high precision outdoor location.
One More Thing …
AA batteries are too large for some use cases and here at Haystack we do work with coin cell batteries at the endpoint. A couple of things I wanted to at least hint at here:
- Coin cell batteries are generally not designed for long discharges. I haven’t seen any LoRaWAN + GPS devices with coin cell batteries and I doubt that I ever will.
- Deploying on-demand A-GPS on a coin cell-based LPWAN device — which has only 620 milliamp hours using a CR 2450 coin cell — still delivers remarkable battery life using Haystack/DASH7:
Maybe we’ll do another post on coin cell form factors …
Summary
- If you plan to deploy location based services with your LPWAN, your choice of networking protocol has major consequences in terms of basic feature set, performance, and the breadth of use cases you can support.
- If you plan to deploy GPS over a LPWAN, there are few downsides to deploying A-GPS and plenty of upsides.
- Obviously there is more than location to consider in a LPWAN product. For example, being able to send a command in real-time or the ability to ship over-the-air security patches or firmware upgrades is important, too. But if your LPWAN solution calls for high-reliability/high-precision outdoor (or indoor!) location, the right option is pretty obvious:
- If you are in an outdoor or indoor location jam and need someone to talk to, email me at pat at haystacktechnologies dot com or visit our website.