The main reasons an Oyster3 would not be connecting as scheduled are as follows:
- Flat batteries
- Cellular reception or network coverage
- Platform setup
- SIM card issues
- Device issue
This article covers how to troubleshoot issues, by checking and eliminating each of these items to isolate the root cause of the issue. If you are unsure, contact your local support team. We will generally walk you through this process.
To help speed up issue resolution, be sure to provide as much detail as possible about the device and issue, and complete as many steps below as possible.
1. Check Batteries
1.1 Check Battery Voltage
- The Oyster3 requires at minimum 3.3V to operate. However, it's not as straightforward as simply checking we've got over this level of voltage.
- If you are using LiFeS2 batteries (i.e. Energizer Ultimate Lithium) - typically they will report a voltage of somewhere between 4.4 → 4.7V when they are no longer able to power the device. Check the battery voltage level, if it is near to this range, the batteries are likely flat and require replacement.
- If you are using LTC batteries, typically these will no longer be operating correctly at around 10.5V total.
Once you have replaced the batteries, ensure that you have configured low battery alerts for early warning on all your devices- Battery Level Monitoring [Oyster3]
1.2 Check for any Under-voltage lock-out (UVLO resets)
If the device ever browns out, the device will log an Under Voltage Lockout Reset. In the Oyster3 this will be indicated in the logs as Reset =2 or Reset =6.
To check the logs in OEM - View the Device Logs, and if you see this log appear, it means the batteries are at a critically low level and must be replaced.
(By default, the start date on the view is 1 day ago - you may want to increase the range to view a month or two of logs)
2. SIM Card/Setup Issues
If this is the first time provisioning the device, or the first time we've used this particular SIM, there is a good chance the issue is to do with the SIM card and/or network configuration applied to the device.
If the device is in the field and in good coverage, then the SIM/config is likely not the culprit as this is unchanged - however the SIM could have been inadvertently disabled or a setting changed OTA.
2.1 Check correct installation
Sometimes, the SIM just hasn't been inserted the right way up, or pushed all the way into the slot. Double check the orientation and installation is as per the image shown. (Gold pads facing down, keyed corner into the slot first)
If you find the SIM is not correctly installed - install it properly and remove/reinsert batteries to reboot the device.
2.2 Check the SIM Card is active
- See A Guide to SIM Cards, ICCIDs and Reports to see how to determine the ICCID of a SIM card installed in a particular device
- The SIM card may have been deactivated mistakenly, or was never active in the first place.
- Ensure that it is a LTE-M or NB-IoT SIM card and that you have coverage from one of these networks in the region.
- If you have the device on you, try a different SIM card. This might reveal that the SIM card you are trying to use is a dud.
2.3 Check APN and Admin Parameters
- A new device will be set to Auto-APN unless your distributor has made special arrangements.
- An in-service device may have been configured with a specific APN in the past, so if you're installing a new SIM it may be trying to use an incorrect APN
- You can check the current settings in OEMServer Admin Parameters.
- If there is a currently pending Admin parameter update in the OEM Pending Updates column, that would be evidence that perhaps somebody has applied an incorrect setting, meaning the current SIM will not get online.
- You can also see if anyone has previously played with the APN by checking out the User Activity Log in OEM. For any device, click the Details link in the device grid, and view the user activity tab. You will see SetDeviceAdminParameters
2.3.1 Resolving APN/Parameter issue
- If Admin Parameters have been applied recently, and the previous set were working, the device will automatically revert to the working set after 3 days thanks to the Connectivity Settings Fallback feature. In the meantime, set the correct parameters via OEM Server for the device to pick up when it connects back in.
- If this is not the case, parameters cannot be changed OTA if the device isn't connecting in. You will need to retrieve the device and use a DMLink Cable to set the correct parameters or debug further.
2.4 Check Upload Timeouts and Registration Strategy
The Upload Parameters may have been set too aggressively, such that the device now has trouble connecting.
Restore these parameters to defaults (shown above) if they have been changed and reboot the device.
If it is in the field, you may have to wait a few days. There is a fail-safe in the device firmware, where if it is unable to connect for 3 days continuously, it will attempt to upload with a 10 minute registration timeout (regardless of parameters applied) - just in case these settings were misconfigured the device can eventually get back online.
3. No Cellular Coverage or Reception
We need to determine if the device is in coverage (i.e. there is network the SIM can get onto in the area) - and that signal is not being blocked from getting to the device (i.e. inside a metal box).
3.1 Check Coverage Maps
Check coverage maps to see if the device may be out of/on the edge of coverage. e.g. Telstra IoT Coverage Map
3.2 Check Device Logs for Evidence of Signal Issues
We can check device logs and data to see if the device not connecting appears to be a one off, or persistent issue. If we can find evidence that the device has been having trouble connecting in the past - it may just mean the unit goes in/out of coverage - and it's not connecting now just because it's out of coverage. In this case all we can do is wait until it comes back to coverage.
- Check the OEM Device Logs, set the start date range back far enough to view a few months' worth
- Abortingoneshot reg indicates the device couldn't register on the network. If you see a number of these logs it might indicate the device travels in/out of coverage and can't connect.
- Aborting oneshot data indicates the device registered, but the connection dropped or was closed during the data upload.
- Check the Device Counters and compare the number of successful to number of failed uploads
- Check Analogue 4 (CSQ - Signal Strength) This ranges from 0-31
- 0-3 - very poor (hard to connect)
- 3-10 - poor (but enough to connect)
- 10-15 - OK
- 15-20 - Good
- 20+ Excellent
- If the signal is sometimes excellent, and at other times poor, it means we may just be going in and out of coverage.
- If it never really gets above 15, it might mean where the device is installed is blocking some signal. In which case we should try an alternative device placement and retest.
4. Platform Setup
4.1 Devices not appearing in Telematics Guru
A device first appears on the map Telematics Guru when it gets it's first valid GPS fix. You can see in Assets > Manage Assets whether a device has received a GPS position, this is shown with a red GPS icon.
So this means that the reason we might not be seeing the device on the map is it's unable to get a GPS fix. Generally, we just need to take the device outside and trigger another fix - see Sending Test Data - [Oyster3] for instructions on how you can trigger another fix.
4.2 Device committing to OEM Server but not Telematics Guru (or 3rd party server)
If your device is showing in Telematics Guru as 'Never connected' (see below) but is connecting into OEM Server, the connector might not be set.
Set the Connector to the correct TG server and trigger another upload and the device will connect. (Sending Test Data - [Oyster3])
4.3 Device not appearing on 3rd Party Platform
- Check OEM Server, if the device is Connecting, but not Committing - we have an issue with the 3rd party server setup. Follow steps here Since Committed/Since Connected and Troubleshooting
5. Device Issue
If we have checked the above items, there are no further troubleshooting steps that can be taken remotely. The device needs to be retrieved from the field to be inspected. Once retrieved:
- If you have a DM-Link cable, follow the steps in the guide to pull the debug logs from your device, and send the CSV file to your local support team. This can help speed up the troubleshooting process. (if not go to next step)
- Send through the following information to your support team,
- Device serial
- Device type
- Description of the issue
They will assist further. It may need to be returned for inspection If the device is within our 2 year warranty period, they will provide and RMA reference number and address for return.