Our range of devices are built to provide location data about assets. To do this, most devices require a GPS fix, and then to connect to the cellular network to upload the data. We never compromise on quality components - as the device performance is paramount.
- Antenna matching is performed to ensure the optimal RF performance
- Low Noise Amplifiers are fitted to devices to boost GPS signals
- GPS Aiding Data dramatically improves the performance of our GPS.
The end result is that our devices get fixes where others just won't. But there are some locations where despite this, we still can't a fix or connect to the network. For example in underground basements, or way out in the bush outside cell coverage.
How is the device going to perform?
Out of Cell Coverage
In short, the device is designed for such scenarios. When out of coverage, the device will store all records in it's memory, and upload them when it can next connect in - so no records are lost. However we won't have current data while out of coverage for alerts/reports etc.
If a device fails a GPS fix, it will still log a record, and send the last successful fix as it's position. This position also includes the timestamp - so 3rd party platforms will be able to identify an older GPS fix by the fact it has an old time.
If battery powered devices regularly fail a large number of GPS fixes and uploads, they will suffer from shorter battery life. This is because we never connect to the network, or get a GPS fix instantly. It takes some time. So we need to let the device try for a set time, before timing out. For most battery powered devices, the GPS Fix timeout is 60 seconds, and the network registration timeout is 180 seconds (3 min). This prevents the device trying to join indefinitely, and running the batteries flat.
On hard-wired devices, this is not an issue - while they are in trip they just keep the GPS and modem on and always try to get a fix/connect. We arent' going to run down the batteries, so this isn't a problem.
The GPS Fix Timeout and Network Registration timeout aim to balance getting a fix/connection, with not wasting too much energy when we can't. However it is not perfect. Consider a device attempting a GPS fix in a basement, it is never going to get one, no matter how long we try for, given it can't see any satellites. So in attempting one, we spend an entire 60 seconds of wasted effort searching for a fix. Given most other fixes in good signal can be achieved in <20 seconds, this is significant. The same goes for trying to register on the network.
If our device will spend most of its time in acceptable coverage, and only sometimes in poor coverage, then they are best left on defaults. But we may have certain applications where we expect the device to regularly be in poor signal such as:
- Tracking an asset that is stored inside a sea container when not in use. While in the container we have no GPS.
- Tracking an asset that regularly makes trips out of coverage
What we want to achieve for a device that will often not have GPS coverage (undercover, in a sea container etc) is to have the device give up trying to get a GPS fix, if early on we figure out that it is very unlikely to get one. We could simply lower the course GPS timeout, but this might mean we fail fixes in average (but no 0) signal - due to giving up a bit early.
Instead, we can make use of the Advanced GPS Settings parameters, defaults are shown.
What this allows us to do is to set limits for acquiring each satellite. For example, if we can't see even one satellite after 20 or 30 seconds, then we're probably not going to get a GPS fix within the 60 second coarse timeout. We need at least 4 satellites for a 3D fix. So each subsequent satellite timeout sets up a 'gate' - to kill the fix attempt early if we're highly unlikely to succeed, thus wasting less energy.
What this means in practice is:
- When the device needs to acquire a fix, it turns the GPS on and looks for satellites
- If after 15 seconds, it can't see 1 satellite, fail the fix, otherwise if we've got one,
- continue; and if after 20 sec (15+5) we don't have at least 2, fail the fix...
- continue this through 3,4, up to 60 seconds (coarse timeout)
To get an idea of our current fix times - we can turn on GPS debugging - see GPS Troubleshooting. These parameters will need to be tweaked depending on the use case. Luckily, if we are in good coverage and the device can connect in, if we get any GPS parameters wrong - such that the device stops being able to get fixes at all (due to being too aggressive on the timeouts), we can just restore defaults when the device next connects in.
We also have the following settings for upload timeouts. These parameters are discussed here - Cellular Battery Powered Device Upload Timeouts
The defaults are chosen so that devices can get online and upload, in a variety of conditions globally, and on a variety of SIM cards. They are not the most optimal for maximizing battery life in all circumstances. In general we can say the following about device registration (joining the network):
- For a local SIM, on the home network, on Cat-M1, with the right bandmasks applied - most of the time the device will register in under 30 seconds when in good coverage
- Roaming SIMs, and NB-IoT SIMs take far longer to scan through available network bands and get on the network, so the defaults are conservative to allow such SIM cards to get online.
So what this means is if we are on a local SIM card, but our device goes out of coverage quite often, to improve battery life we can lower the network registration timeout. This means when we are well out of coverage, we don't spend 3 minutes with the modem on, trying to connect and still fail the upload anyway. Given that the average time for an upload is 30 seconds, failed uploads drain 6x the battery as successful ones!!
- Make sure to Set the Network Profile on your device - this will speed up registration
- You should be safe in most cases to set the Network Registration Timeout to 60 seconds - USE CAUTION
Setting any network registration timeouts too low may lead to the device being unable to connect (as it will give up too early). If it is unable to connect for 3 consecutive days, it will reboot and try register with a once-off 10 minute timeout - allowing you to change the settings back (but you'll lose the device for 3 days!)