NB - The Yabby Edge Cellular is due to be released in Q4 2021. Speak to your sales representative for further information.
The Yabby Edge Cellular determines its location differently to traditional GPS devices. In order to get a position, the following occurs:
- The device scans for GNSS and Wi-Fi signals. This is satellite data (time delay and sat number) - along with nearby Wi-Fi access points
This article covers the settings for these scans.
- This data is sent to the server - our Location Engine, which uses a variety of services to 'solve' the position from this information. The Location Engine looks at the data and returns a position based on
- GNSS Scan Data
- Wi-Fi Scan Data
- Cell Tower ID and Timing information.
Further settings can be applied server side by our support team on the location engine, to determine which lookup services are used, and which fixes are filtered out (based on accuracy estimate).
On a traditional GPS device, this 'solving' would be done on the module. However this is computationally more expensive, and takes more time. This means the batteries have to power the module longer, using more energy. Handling it on the server saves power.
GNSS relies on the devices being able to detect signals sent from satellites orbiting the earth. As such, it does not work well (or at all) indoors, undercover, in basements, or around tall buildings. Our GPS devices perform better than most! But there are still places where picking up a satellite signal is simply not viable. When out in the open, GNSS is a great option!
Wi-Fi scanning on the other hand detects nearby access points, and the RSSI (relative signal strength) seen. The device does not need to connect to the WiFi network it is like when you can view a list of nearby Wi-Fi networks on your phone. Using the signal strength values the server can get an idea of how far it is from a bunch of access points, and try and triangulate a location. So this method of geolocation is great for when we're indoors and GPS won't work. However, it is a bit less accurate, and also won't work if we can't see any Wi-Fi signals (i.e. out of town in a rural area)
30-100m for both GNSS and Wi-Fi, however, GNSS will typically be more accurate more of the time. (i.e most fixes are near the 30m mark). This is important to consider. Often we may choose to 'fail' a fix if it is not accurate enough for our needs. This is a bit easier to do on our traditional GPS devices, as the module reports a position accuracy estimate, and we can ignore the fix if it's too inaccurate. For the Edge, the server must do this.
The current default parameters are shown below.
In general, they can be left on defaults. Do not adjust unless you know what you are doing.
They are made available to support more complex or unusual requirements. Or if certain environmental fixes mean we are seeing inconsistent results. The already exceptional battery life of the device can be improved slightly with parameter tweaks, but this is typically a marginal improvement.
The default parameters are for "WiFi with GNSS Fallback"
- Scan for Wi-Fi signals
- If more than 10 Access points are found, Do NOT Scan for GNSS. Simply send the WiFi data to the server, where a Wi-Fi lookup will be performed on the Location Engine.
- The logic behind that is if we see 10 Wi-Fi access points, we are very likely indoors, where GNSS Signals will be weak/inaccurate and lead to bad fixes. So best to use Wi-Fi in this scenario.
- If the Wi-Fi scan returns less than 10 access points, do a GNSS scan as well, then send the results of both to the server.
- The Location Engine will then perform the lookup based on the settings configured
- On any scan, send data from a maximum of 10 Wi-Fi Access points, and 15 Satellites to the server
- Sending more doesn't net a large accuracy gain, and only increases data usage
- Filter out non-unique MAC addresses.
Selects which technology to use when performing scans. Either:
- Wi-Fi and GNSS (default)
- GNSS only
- Wi-Fi only
- GNSS with Wi-Fi fallback
- Wi-FI with GNSS fallback
When doing a scan, it takes about 2 seconds for the device to boot up. Then:
- Typically 4-8 seconds for a GNSS scan
- Typically 1-6 seconds for a Wi-Fi scan
So disabling one method saves this time with the device on (saves a bit of power). Note the upload energy cost will be much higher anyway. Additionally we may want to disable certain scan types for other reasons discussed below.
Wi-Fi and GNSS
The device will scan for both signals, and send both data sets up to the server. It might not pick up any satellites or Wi-Fi networks in the scan, but both are attempted. Then, once the Location Engine has the data it will compute a fix based on the information available. i.e. even if we have some satellite data, this doesn't always guarantee a GNSS location, so we might fall back to Wi-Fi or even Cell tower location.
This is only is useful if the device is not going to be outdoors at all. It will improve battery life as we don't need to do the GNSS scan.
GNSS only is useful if the device is not going to be indoors, or if Wi-Fi positions are causing issues on, or near bodies of water or open plains.
The fallback mechanisms are useful to save on power. We can preference the location method we are more likely to get a fix with. But since the device does not truly know if the server will resolve a position with the data it has collected, it decreases performance.
This only applies to the fallback modes mentioned above. This many more than the minimum number of satellites or APs must be found or the fallback technology is used.
- To be able to resolve a position on the server, the minumum number of Wi-Fi APs is 2, and the minimum number of GNSS satellites is 5 of only one constellation (GPS/Beidou), or 6 of a combination of both constellations.
- If the device finds more than the minimum, but less than the margin, it will log both the “primary” data and fallback data.
- E.G Wi-Fi with GNSS fallback, with a fallback margin of 3. The device finds 4 access points, which is less than the 5 required, so it does a GNSS scan as well. It logs the 4 Wi-FI access points it found along with the GNSS data is collected.
The idea of the fallback margin is as follows - we can set a number of Satellites/APs, that if we were to resolve a location with this method alone, it would give us our desired accuracy. E.g. if we have done a GNSS scan, and already found 10 satellites, there is not really a need to do a Wi-Fi scan - the satellite data will give us an accurate fix anyway (the Location Engine probably won't even use Wi-Fi data if we sent it, just the GNSS)
We can set a maximum number of APs/Satellites to be logged. Typically once we exceed 8 APs or 15 Satellites, adding further doesn't improve position accuracy significantly - it's really just increasing our data usage.
Maximum Number of Access Points:
If the number of APs found exceeds this number then the device only logs this amount, selecting the APs with the strongest signal strength and that are more likely to resolve a position.
Maximum Number of Satellites:
This is the maximum number of satellites to scan for.
Filter Non Unique MACs
Wi-Fi MAC addresses can be globally unique or locally administered. If they are globally unique they are more likely to resolve a position. It is generally recommended to leave this enabled.
Filter Young APs
A “young” AP is one that has not been on for long. This suggests that it is likely a mobile AP and is not useful for positioning. However, it can also be due to a a fixed AP only being recently installed, a recent power outage, etc. By default this is off, but if mobile APs are common in the device’s data this should be disabled.
Set Up Examples
In general, defaults will be fine. But sometimes tweaks are required for certain circumstances, to prevent strange (but explainable) behaviour.
This example is from our early testing:
For whatever reason, when we were at point (1), the GNSS location failed. So the device and server resolved a Wi-Fi position at (2). Which is fairly inaccurate.
In our application, a degree of innacuracy might be OK - it could be better than no position at all (if we went into a basement). But instead we may prefer to simply 'fail' this fix and not update the location to a potentially incorrect one. Hopefully a subsequent fix would put us in a better spot. Or at least the trip history would look correct, and we reduce the risk of setting off false geofence alerts.
We would make the following parameter change