Software apps and online services | ||||||
 |
| |||||
GPS trackers connect to a series of satellites to determine their location, which uses quite a bit of energy. The tracker connects to three or more satellites in the Global Navigation Satellite System (GNSS) network to determine its own position. The data at the heart of a GPS signal is time – the exact time the signal left the satellite and the time it took for the signal to arrive. Since the position of each GPS satellite is known for each point in time, we can compute the distance from the tracker to each of the satellites. Combining all these distance measurements with their angles, the actual position of the tracker on Earth in latitude and longitude can be calculated with good accuracy. GPS technology was originally developed for military use in the 1960s, but became available to the public in 1983.
These days, many devices use Assisted GPS (also called A-GPS): They rely on more than just satellite signals to figure out coordinates. Cell Phone towers (which have a precisely known location) and Wi-Fi gateways (which often have a known location, if Google has collected them) also send out signals that can be used to triangulate a location - a process called Wi-Fi sniffing. For even more precise location and indoor tracking, Bluetooth can be used, accessing the location data either from special purpose Bluetooth beacons, that can be placed strategically inside a building and send out signals in regular intervals, or from the location data of smartphones – which, of course, requires the owner’s permission.
The device then either averages the data from all these sources to provide a more accurate location analysis, or simply selects the best data, usually from a Wi-Fi hotspot, to accurately locate within a few metres of its true location.
The disadvantages of GPS tracking are cost and energy consumption. The devices are typically quite expensive. In addition, the use of proprietary databases, such as Google's API for assisted GPS, adds to the cost. The relatively high power consumption requires frequent recharging or battery replacement, or permanent installation, for example in cars, heavy goods vehicles or electric bicycles that have a robust power supply.
The Use-Case for non-GPS TrackingCost and power consumption - two arguments against GPS that make it worth looking at alternatives. Regular LoRaWAN devices have access to the location of their receiving base stations, regardless of their LNS server. This is true of The Things Stack, Chirpstack, Helium and other LoRa networks.
Standard LoRaWAN temperature and humidity sensors can operate for years on a single battery. They are also inexpensive, making them ideal for use in situations where the safe return of the device is not guaranteed. This could be the delivery of perishable food, medical supplies or other equipment, where customers only need to know a rough estimate of the sensor location, or if they own a base station at the origin and destination, in which case they would get very good data on the departure, arrival and return of the goods. Or they might just want to know if workers have returned their toolboxes to the company warehouse, for example, or need to confirm the return of rented items.
Turning a simple LoRaWAN sensor without GPS into a tracking deviceIn Datacake, a simple snippet of code is inserted into the existing decoder of any LoRa device, and currently works for The Things Stack, Chirpstack, Helium and Helium hosted on IoT-Creators. It will test the code for any of these LoRa Network Servers (LNS) and extract the metadata from the receiving base stations. In this example, we return the location coordinates of the base station with the strongest and cleanest signal, and also the count of stations that have heard the signal. We deliberately don't do any multilateration, but more on that later.
function Decoder(bytes, port) {
var decoded = {};
// Do all the normal decoding for the sensor
// decoded.temperature = (bytes[0] << 8 | bytes[1]) / 100 ...
// ...
// Test for LoRa properties in Datacake normalizedPayload
try {
if (
normalizedPayload.gateways &&
Array.isArray(normalizedPayload.gateways) &&
normalizedPayload.gateways.length > 0
) {
decoded.lora_rssi = normalizedPayload.gateways[0].rssi || 0;
decoded.lora_snr = normalizedPayload.gateways[0].snr || 0;
decoded.lora_datarate = normalizedPayload.data_rate || 'not retrievable';
}
} catch (error) {
console.log('Error occurred while decoding LoRa properties: ' + error);
}
function getStrongestBaseStation(baseStations) {
var baseStationMetadata = baseStations.map(function (baseStation) {
return {
rssi: baseStation.rssi,
snr: baseStation.snr,
lat: baseStation.lat,
long: baseStation.long,
};
});
var strongestBaseStation = baseStationMetadata[0];
for (var i = 1; i < baseStationMetadata.length; i++) {
if (
baseStationMetadata[i].rssi > strongestBaseStation.rssi ||
(baseStationMetadata[i].rssi === strongestBaseStation.rssi &&
baseStationMetadata[i].snr > strongestBaseStation.snr)
) {
strongestBaseStation = baseStationMetadata[i];
}
}
return strongestBaseStation;
}
// Test for location data in Datacake rawPayload
try {
// Test for TTI
var hotspots = rawPayload.uplink_message.rx_metadata;
if (hotspots && Array.isArray(hotspots) && hotspots.length > 0) {
var strongestBaseStation = getStrongestBaseStation(hotspots);
baseStationLatitude = strongestBaseStation.lat;
baseStationLongitude = strongestBaseStation.long;
baseStationsCount = hotspots.length;
}
} catch (error) {
try {
// Test for Helium
var hotspots = rawPayload.hotspots;
if (hotspots && Array.isArray(hotspots) && hotspots.length > 0) {
var strongestBaseStation = getStrongestBaseStation(hotspots);
baseStationLatitude = strongestBaseStation.lat;
baseStationLongitude = strongestBaseStation.long;
baseStationsCount = hotspots.length;
}
} catch (error) {
try {
// Test for Chirpstack
var hotspots = rawPayload.rxInfo;
if (hotspots && Array.isArray(hotspots) && hotspots.length > 0) {
var strongestBaseStation = getStrongestBaseStation(hotspots);
baseStationLatitude = strongestBaseStation.lat;
baseStationLongitude = strongestBaseStation.long;
baseStationsCount = hotspots.length;
}
} catch (error) {
try {
// Test for Managed Helium
var messages = rawPayload.messages;
if (messages && Array.isArray(messages) && messages.length > 0) {
var via = messages[0].via;
if (via && Array.isArray(via) && via.length > 0) {
var strongestBaseStation = getStrongestBaseStation(via);
baseStationLatitude = strongestBaseStation.lat;
baseStationLongitude = strongestBaseStation.long;
baseStationsCount = via.length;
decoded.lora_datarate =
messages[0].metadata.txModulationLoraSpreadingFactor;
decoded.lora_snr = strongestBaseStation.snr;
decoded.lora_rssi = strongestBaseStation.rssi;
}
}
} catch (error) {
console.log(
'Unable to decode location. No supported LNS found: ' + error
);
baseStationLatitude = 0;
baseStationLongitude = 0;
baseStationsCount = 0;
}
}
}
}
// return location data only if it has a value not Zero
if (
baseStationLatitude !== 0 &&
baseStationLongitude !== 0 &&
baseStationsCount !== 0
) {
decoded.location =
'(' + baseStationLatitude + ',' + baseStationLongitude + ')';
decoded.locations_count = baseStationsCount;
}
// Return Datacake object
return decoded;
}Accuracy varies, but is surprisingly useful in many cases. In one of the following examples, the signal is heard by 5 base stations. The closest station is indeed the best choice, giving almost perfect accuracy, while during the test we discovered that unknowingly, we were standing right next to the building that houses the base station. However, even if we had been standing elsewhere in that neighbourhood, if you just want to know your approximate location, this is clearly more than good enough.
Inaccuracy is the biggest risk in turning a normal sensor into a tracking device. Outside capital cities, the sensor signal is rarely picked up by more than a single base station. Sometimes there are obvious reasons for low accuracy:
- The receiving base station may not be providing location information, or may return a default of (0, 0) for latitude and longitude, which is possible, if the owner of that gateway has simply omitted filling in coordinates (except in Helium, where location information is required during onboarding).
- The receiving base station may be providing inaccurate coordinates, which is possible if the owner of that base station has chosen to disguise its true location (this is also possible on Helium), or if the owner has moved and not yet updated the location.
- The receiving base station can be many kilometres away from the sensor, so the diameter of uncertainty around the sensor is quite large and the location could be very inaccurate.
- Coverage of any LoRaWAN network is far from ubiquitous outside major cities, so in many rural areas, the sensor signal may not be heard at all, resulting in no location data.
We've tested several well-established multilateration algorithms (no secret sauce used) and found that most of the time it's not worth the effort. Very rarely is the sensor seen by more than a single base station, in which case we only have that single location anyway. In the case of only two stations, multilateration makes no sense because the signal would be exactly the same on the other side of a line drawn between them. So there is no real benefit in doing a calculation.
But we also tested extensively in areas with dense hotspot coverage, mostly in city centres. Multilateration results were mixed. For instance, in our example from before, when the signal is picked up by 5 base stations, all fairly close together, the resulting location from multilateration (blue marker) is very good, but not better than just using the nearest station (red marker with blue dot). The true location (green marker) is right in front of an art supply store in Hamburg and all of the markers are fairly close together.
If the sensor is heard by many more stations, as was tested by climbing onto the roof of a 5-storey building in Hamburg, configuring the sensor to scream as loud as possible on SF12 and holding it up in the air, the result was not as good as we expected. Surprisingly, although the sensor was picked up by 24 base stations, many of them were too far away from the actual location (green marker) to be of good use. In fact, the result from using multilateration (blue marker) was skewed to the south-west, as the roof we were on had a perfect line of sight in that direction, while there were some hills and a lower density of base stations to the north-east, resulting in fewer markers in that direction. Under these circumstances, simply selecting the station with the strongest signal (red marker with a blue dot) on the list returned a far better result. In fact, there would have been another base station that was closest to the true location and that would have provided the most accurate result, but unfortunately it was neither selected as the strongest on the list, nor was it weighted correctly in multilateration, because it was probably placed in a sub-optimal position or kept indoors, resulting in lower than expected RSSI and SNR values, and also poor response time. Unfortunately, this is not an uncommon occurrence, especially with Helium.
If we had turned the sensor signal down from SF12 to SF9 or even SF7, it might have given better results.
Despite the occasional lack of accuracy, adding location lookup to regular sensors does have its advantages. For once, there is battery life. Simple temperature and humidity sensors can run for many years on a single charge, while transmitting every 5-20 minutes. In scenarios where location accuracy is not critical, the method described above is a viable option and, due to its very low cost, allows for some use cases where there is a possibility of the sensor not being returned, such as rental or delivery services. There are even cheap disposable sensors on the market in the form of sticky labels designed specifically for this purpose, although the environmental impact of this approach needs to be evaluated.
Additional Benefit of Using the Sensor for Simple Field TestingAn additional benefit of using the simple technique described above is that you can get a count of the base stations that have heard the signal. This is valuable information because our simple Dragino LHT65 can now also be used as a very basic field tester, telling us if the signal is heard at all, at what location it was heard and whether there were one or more stations that also heard the signal for redundancy, all of which is important information while testing a site for a fixed installation of a sensor.
By providing a special template called Dragino LHT65+/LHT65N+ Location Device, we have made this experiment available to the interested public on Datacake.
Comments