The typical location accuracy of the Oyster Edge is:

~ 5m-80m for a GNSS location 
~10m-100m for a WiFi location - depends on how many Access Points are in range 
~250m - 1km for a Cell Tower Location - depends on how many cell towers are nearby

This is a bit less accurate than a device with on-board GNSS like the Oyster3 or Yabby3 - however the Edge range sees greater battery life - due to the low power location scanning.

Some users may notice the reduced accuracy when a device obtains a position based on Wi-Fi or Cell Data. The request is then to disable Wi-Fi and Cellular lookups and rely solely on GNSS data. We would advise against this. 

On default settings, the device will always attempt to achieve a position in the order

1. GNSS
2. WiFi
3. Cell Tower data

See Edge Device - Location Scanning and Lookup Parameters. What this means is if a device is using WiFi or Cellular data, it is unable to resolve a position via GNSS - typically due to not being able to see enough satellites. In this case, it makes sense to fall back to WiFi or Cell data in order to get aposition. This is one of the key strengths of the device and allows it to operate across indoor/outdoor environments. If we wish to disable both Wi-Fi and Cell data, perhaps another device would be optimal instead of an Edge device and we should review the device selection. 

In addition to this, disabling Wi-Fi and Cell Tower data can in fact reduce the performance of the GNSS on the device! As detailed below:

For the GNSS scan to work well it needs to do an “aided” scan. This uses the almanac file that has been downloaded to the device.

For this to work properly the devices needs:

1. A valid almanac file (up to date within 2 weeks preferably)
   1. Gets downloaded from Location Engine (LE)
2. A valid time
   1. this gets sent from LE when the device connects in
3. An estimated location, needs to typically be better than 200km, but the more accurate the better
   1. this gets sent to the device from location engine when the device connects in, using the results from the last set of data sent up from the device, so there is a lag
   2. to get the estimated location started LE needs data from the device to do a valid lookup and then needs to be able to send this back down to the device
   3. so this will take a minimum of 2 upload cycles (data gets sent on 1^st upload, updated location estimate comes back down on the next upload)

What impact does this have?

If the device can’t do an aided GNSS scan (for some reason) it will attempt to do an unaided scan, which is a lot worse in terms of sensitivity. So if the device is not in a good signal area then it will fail GNSS scans.

It can then fall back to W-iFi or cell location, but if these have been disabled on the system (possibly in device params or on LE) It is unable to ‘kickstart’ the position estimate to get aided scans going.

It is going to underperform until it gets a valid unaided GNSS scan.

Also, if a device travels a large distance (> 200km) between uploads then its position estimate is out, and it may take a couple of upload cycles to get back to being able to do aided GNSS scans.

(important to note if the in trip upload is set to a long time, then the device does not get regular position estimate updates while travelling)

If a device had its batteries removed (and worse was shipped somewhere), then it may need to take a few uploads before it can start doing aided GNSS scans again.

For the LoRaWAN version it is even slower to get all the info it needs, especially the full almanac file downloaded for the first time.