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. 

Wi-Fi Only       
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       
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.

Fallback Margin:

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.

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

Sometimes we may see nesting about an office window - as the device is able to just barely get a GNSS fix in the window, from a few satellites - which can be innacurate at times

"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.