Skip to main content

Basic troubleshooting of Ruptela tracking devices

How to diagnose common tracking device issues: physical checks, SMS diagnostics, no data, no GNSS fix, delays, high data use, logs.

About this guide

This guide helps support teams, installers and technical staff identify and resolve the most common issues with Ruptela tracking devices during deployment and operation: how to verify basic device functionality, read LED indicators, check power and connectivity, inspect the equipment for physical damage, run remote diagnostics via SMS, analyse the records received by the server and collect logs.

Scope:

  • The guide is server-agnostic. It applies whether the device sends data to Ruptela's platform or to your own / a third-party server. Wherever server-side settings are mentioned (IP, port, protocol, object creation, record analysis), use the values and tools of the server your device is configured for.

  • Tachograph-related troubleshooting is not covered here.

  • For advanced procedures, see the knowledge base at my.ruptela.com and the documentation at doc.ruptela.com.

Before you start

Collect the following information first. It speeds up diagnosis and is required if the case is escalated:

  • IMEI of the device (label on the device, or SMS command imei).

  • Device model and firmware (FW) version.

  • Configuration file currently loaded on the device (or at least the connection, APN and SMS settings).

  • SIM card: provider, whether it is active, data plan / available traffic, and APN.

  • Server details: which server the device should send data to (IP or domain, port, TCP/UDP protocol).

  • Symptom and timeline: what exactly is wrong (no data, delayed data, wrong location, high traffic, etc.), since when, and whether it affects one device or many.

  • Installation details: vehicle type, power supply voltage (12 V / 24 V), where the device and antennas are mounted.

Also note any recent changes around the time the problem started: configuration or firmware updates, device replacement or reinstallation, work on the vehicle's electrical system, or physical manipulation of the device. Many issues start right after such a change.

Tip: if many devices are affected at the same time, the cause is more likely to be on the server, SIM provider or network side than in the devices themselves.

Step 1. Physical checks

Many issues are caused by the installation itself. Before any remote diagnostics, make sure that:

  1. Power supply is correct and stable. The device must be wired to the vehicle power supply that meets its datasheet requirements (see Tracking Devices Home). Power supply voltage should be above 10 V for most devices. The cellular module does not work when the device is powered via USB only.

  2. GNSS antenna has a clear sky view. The internal antenna (label side "this side towards sky") or the external antenna must face upward, be tilted no more than 45°, be installed as close to the windshield as possible, and have no metal objects or wiring between it and the sky.

  3. External antenna and cables are intact and firmly connected (if an external GNSS/GSM antenna is used).

  4. SIM card is inserted, active and has available data. For M2M SIM cards, confirm the status with the SIM provider.

  5. The device is firmly fixed. A loosely mounted device may generate false movement events (relevant if the movement sensor is used for ignition detection).

  6. No sources of interference are nearby, such as FM modulators, plug-in voltage converters or toll / road-tax devices. Ordinary phones, tablets and chargers usually do not cause problems.

LED indicators

The device LEDs show the state of the GNSS, cellular (GSM) and peripheral modules. Compare the LED pattern with the LED description in the user manual of your specific device model. This quickly shows whether the device has power, is registered to the network and has a GNSS fix.

Inspection for physical damage

If the device does not power on, behaves erratically (e.g. the modem keeps dropping even on a stable external power supply) or the issue started after work on the vehicle, inspect the equipment for physical damage. Check:

  • Housing: cracks, deformation, melted or discoloured plastic, burn marks, missing or damaged seals and covers.

  • Moisture and corrosion: signs of water ingress, condensation, oxidation or corrosion on connectors, SIM holder or inside the housing. Make sure the device's IP rating suits the installation place (e.g. trailers, engine bay or other exposed locations). Humidity is a common cause of failed power circuits and burnt sensor wires.

  • Connectors: bent, pushed-in or corroded pins, loose or cracked connector housing, harness not fully seated.

  • Wiring harness: chafed, pinched, cut or burnt wires, melted insulation, poor crimps or twisted connections. Pay special attention to power, ground (GND) and sensor wires; a burnt or detached ground wire points to a wiring or grounding fault.

  • Fuse: the fuse in the power line is present, of the correct rating and not blown.

  • Antennas: external GNSS / GSM antenna cables are not kinked, crushed or cut and their connectors are tight and undamaged.

  • SIM card: SIM holder is intact and the SIM contacts are clean and undamaged.

  • Accessories and sensors: connected sensors and their cables show no damage (a faulty accessory can affect the device's power supply or inputs).

Bench test: remove the device and connect it to a known-good external power supply (e.g. 12 V) with a known-good SIM card. If it does not power on, or the fault is reproduced on the bench, the device is most likely faulty. If it works correctly on the bench, the cause is in the vehicle installation (power, ground, wiring, interference).

Document everything: take clear photos or a short video of the device label (IMEI), the housing, connectors, harness and any damage found, and note how and where the device was installed. This is required if the device is sent for repair or replacement (see "Escalating to Ruptela support").

Note: do not open the device housing unless instructed by Ruptela support, as this may affect the warranty.

Step 2. Remote diagnostics via SMS

SMS commands let you check the device state without physical access. Send the commands below in this order. If an SMS password is set in the configuration, put it before the command (e.g. password gsminfo). If you are not sure whether a password is set, try both with and without it. The full command list is available in the SMS command list.

  • getapn – APN and server connection settings (IP, port, protocol)

  • gsminfo – cellular network, signal level, GPRS status, server timeouts

  • coords – current GNSS state, time, satellites, HDOP

  • imei – device IMEI

2.1 getapn – APN and connection settings

Response example: APN: internet.example.com User: PSW: IP1: 203.0.113.10 Port1: 7001 IP2: 198.51.100.20 Port2: 21043 TCP/UDP: 1

TCP/UDP: 0 = TCP, 1 = UDP.

APN: must match the SIM card in use, otherwise the device cannot connect to mobile data. APNs of Ruptela-supplied SIM cards:

  • Teliasonera: ruptela.ts.m2m

  • Vodafone: m2m.ruptela.com

  • Tele2: ruptela.tele2.com

  • Telenor: ruptela.cxn

If you use your own SIM cards, confirm the correct APN with the SIM provider.

Note: the APN in the reply may look wrong if the configuration (especially a factory one) uses the Auto APN function to work with many SIM providers. Only the first APN from the list appears in the reply.

Server IP / port / protocol: must match the server the device should send data to. The port must correspond to the selected protocol (TCP or UDP), as servers usually listen on different ports for each. Get the correct values from the server / platform provider.

Note: if two servers are configured but the "Two servers" option is disabled, IP2 works as a backup. The device may switch to the second server when the first one is unavailable. To return to the first server, restart the device with the SMS command reset.

2.2 gsminfo – cellular and GPRS status

Response example: ST:2018.11.23 09:27:21; OP 64901,lvl 23,LAC 123, CID: 12022, GSM; M:I 8815, R 8814, SP: 0; GPRS 0:O 2, C 0, E 8803; LK:O 5, E 7, TMO 1; RS: 14; P 1

Key fields:

  • ST – start time (GMT) of the last reset / power-on. If it starts with 1970, the device has had no GNSS fix since restart and its clock is not synchronised. In this state the device does not generate records.

  • lvl – GSM signal level. A low level can cause data delays. If the device is in an area with known good coverage but the level is still low, suspect the installation place or a physical problem.

  • GPRS – 0 = not attached, 1 = attached. With GPRS 0 the device cannot send data. Check the APN and the Temporary blacklist setting (see Step 3).

  • TMO – number of server response timeouts since the last restart (the device did not receive an acknowledgement from the server). A large and growing number points to a server-side problem: check that the server is reachable, the port is open and the server acknowledges the device's packets. Restart the device and check again whether the number keeps increasing.

2.3 coords – GNSS status

Response example: 2018-11-29 22:33, lat. 0.0000000, long. 0.0000000, alt. 0.0, sat. 0, dir. 0.00, hdop 0, state 2

  • Time – current GMT time. If it starts with 1970, there has been no GNSS fix since restart and no records are generated. Check the antenna's sky view.

  • sat. – satellites in use. At least 4 are needed for coordinates, 5 or more for accurate positioning.

  • hdop – positioning dilution. The lower the better; values close to 1 are most accurate.

  • state – 1 = off, 2 = on, no fix, 3 = on, fix acquired, 4 = not responding, 5 = sleep, 6 = disabled. State 3 confirms a valid fix.

If the reply is "GPS is not available", the device has no valid time from either GNSS or the network. See "No GNSS fix" in Step 3.

2.4 imei – device identifier

Response example: IMEI: 862462036839800

Use it to double-check that the object on the server is created with the correct IMEI. The IMEI is the key identifier on the server side; if it is entered incorrectly, the server will not accept data from the device.

2.5 The device does not reply to SMS

Possible reasons:

  1. The device is disconnected from power, so the cellular module is off.

  2. The SIM card is not active.

  3. The SMS was sent with a wrong SMS password. Check the password in the configuration.

  4. The SMS was sent from a number not in the valid numbers list of the configuration.

  5. The SIM is an M2M type (e.g. Vodafone M2M numbers starting with 2040…) that only accepts SMS from the operator's platform or an SMS gateway, not from a regular phone.

  6. The device is in an area without GSM coverage. Check in the server's record history where and how often the GSM signal level drops to 0.

Step 3. Common issues

3.1 Device is not sending data (object offline)

  1. Do the physical checks from Step 1, especially power and SIM status.

  2. Send getapn, gsminfo, coords and imei (Step 2).

  3. Depending on the result:

    • No SMS reply → see 2.5.

    • Wrong APN, IP, port or protocol in getapn → correct the configuration.

    • ST / time starts with 1970 or coords state is not 3 → no GNSS fix, see 3.2.

    • GPRS 0 in gsminfo → see "GPRS status is 0" below.

    • TMO keeps increasing → the device reaches the network but the server does not acknowledge its data. Check server availability, firewall / port, and that the object exists on the server with the correct IMEI.

    • Everything looks correct → check that the object on the server is created with the correct IMEI and the correct device type / protocol, then collect a log (Step 5) and contact support.

Additional checks:

  • Power was switched off on purpose. Before deeper diagnostics, confirm that the vehicle was not parked with the battery disconnected or the power cut by a main switch.

  • Data collection or data sending is disabled in the configuration. This often happens after a new installation or when replacing another tracker, when a configuration without data collection / sending was loaded. The device answers SMS but generates no records. Check the configuration, or enable both via SMS: password setcfg 1121 1, 1127 1 (1121 = data collection, 1127 = data sending). Also check that the configuration includes the basic IOs (power supply voltage, battery voltage, etc.).

  • Test the connection to the server directly with SMS password connect <server IP>,<port>,<TCP|UDP>, using the values of your server.

  • Swap test the SIM card: put the SIM into a known-good device, and a known-good SIM into this device. If the problem follows the SIM, contact the SIM provider; if it stays with the device, continue with the device checks.

  • SIM with a locked APN: if the APN cannot be changed via SMS, set it in the configuration file and upload the configuration to the device.

  • Hard reset: disconnect the device from both the power supply and the internal battery for about 10 minutes, then reconnect and check the status again.

  • Firmware: make sure the device runs a stable, up-to-date firmware version (downloads). If the problem started right after a firmware update (especially a test version), roll back to the previous stable version and check whether the problem disappears.

GPRS status is 0

The device replies to SMS but does not send data, and gsminfo shows GPRS 0. The usual cause is that the device registered to a network operator that does not provide mobile data for that SIM card (unsupported operator or a local operator / SIM provider issue).

  1. Check that the APN is correct (2.1).

  2. Check whether Temporary blacklist is enabled by sending password getcfg 144:

    • ID:144;value:900 (or any non-zero value) → enabled, go to step 4.

    • ID:144;value:0 → disabled, go to step 3.

    • The reply is only returned if "Enable configuration over SMS" is enabled in the configuration; otherwise the device replies "You do not have permission to read the settings".

  3. Enable Temporary blacklist with password setcfg 144 900 (4th and 5th generation devices) or by uploading a DIFF / configuration file with this parameter changed. The device will then blacklist an operator without data service for 900 seconds and look for another one.

  4. If only one operator is available for that SIM card, contact the SIM card provider's support.

3.2 No GNSS fix / coordinates not updating / location jumps

Symptoms: coords returns "GPS is not available", 0 satellites, state other than 3, time starting with 1970, the location on the map is frozen or jumps, or the route is inaccurate. SMS replies can still work normally, because the SIM and cellular module are independent of the GNSS module.

Common causes: antenna without sky view, damaged or disconnected external antenna / cable, interference from other devices in the vehicle, or a damaged GNSS module.

  1. Installation: check the antenna position as described in Step 1. Consider an external GNSS antenna if the internal antenna cannot be placed well.

  2. History: check satellite count and HDOP in the records received by the server for several days, including the day of the problem (Step 4). If the satellite count drops to 0 while the vehicle is moving (ignition on, RPM > 0, higher supply voltage), suspect a damaged / disconnected antenna or interference.

  3. Interference: remove or move away devices such as FM modulators, plug-in voltage converters and toll devices, and check again. If that does not help, inspect the wiring and antenna connections in the vehicle, and if needed move the tracker and antenna further away from interference sources.

  4. Configuration: make sure GPS, GLONASS and Galileo are all enabled to increase satellite availability. Enable Navigation filtering (stationary and active) to discard inaccurate coordinates.

  5. "Send data without GPS fix": if this option is enabled, the device can send records with invalid GNSS values (e.g. coordinates 214.7483648). Disable it if you do not want such records.

  6. Deep reset: disconnect the power supply, disconnect the internal battery, then reconnect the battery and the power supply.

  7. If the issue persists, collect a log (Step 5) and contact support.

3.3 Data delay

  1. Check the GSM signal level in the records for the period when the delay occurred (Step 4). Signal level 0 means the device had no network and stored records in memory until the connection was restored.

  2. Check GPRS status and the network operators used. If some operators do not provide reliable data service, blacklist them.

  3. Check TMO in gsminfo – frequent server timeouts also cause delays.

3.4 High data consumption

High data usage can lead to SIM blocking by the carrier or overcharging. Start by exporting all records for the last few days from your server and counting how many records each input trigger (event IO ID) generated. If the device sends data to TrustTrack, use the coordinate analysis report. The most frequent trigger usually points to the cause.

Possible causes:

  • Data collection coefficients too low (check all profiles if profile switching is enabled): distance < 500 m, time with engine < 60 s, radial < 45°, time without engine < 600 s. Input triggers 7, 8 and 9 represent data collection coefficients.

  • Data sending settings: Constant link (connection kept always open), Heartbeat (handshake every X seconds) or TCP keep-alive (periodic packets even without data) enabled.

  • IO events: an IO with Event on: Change that changes often (e.g. movement sensor) creates a record on every change, regardless of priority. An IO with hysteresis where the Delta is set close to normal operating values, the Level is low or the Average is below 1000 ms (e.g. power supply voltage with Delta = 12600, Level = 1, Average = 10 ms) generates many records on normal voltage fluctuation. A digital input that is short-circuiting can generate records every second. Custom ignition based on power supply voltage with a range that fluctuates during normal operation, or based on the movement sensor on a poorly fixed device, causes frequent false ignition on/off events.

  • CAN interface: a CAN mode that sends data your server does not process still consumes traffic. For example, TrustTrack does not support DTC, so the J1939 + DTC mode used with TrustTrack consumes data without any benefit. Use a mode that matches what the server uses, e.g. FMS mode.

  • DMP connection frequency (5th generation devices) set to every 5 minutes or less. Increase it, e.g. to twice a day or once a week. The value is set in seconds (days × 24 × 60 × 60, so 7 days = 604800) via SMS setcfg 23101 604800 or by uploading a DIFF / configuration file with only this parameter changed.

Step 4. Analysing the records received by the server

The records the device has already sent are one of the best diagnostic sources. Use the raw data / record history view or export of your server and look at the following parameters for the period of the problem. IO IDs and their meaning are listed in the FM IO list.

  • Power supply voltage – must be above 10 V for most devices (ECO4 S models can run from 6 V). A drop to ~0 V means the device was disconnected from power and switched to the internal battery.

  • Internal battery voltage – a fully charged battery is 4 V or above; below 3.7 V it is discharged.

  • GSM signal level – 0 = no network, data could not be sent (explains data delays). For remote firmware / configuration updates it should be above 10.

  • GPRS status – 0 = not attached to mobile data, 1 = attached. The device may still answer SMS with GPRS 0.

  • Operator – shows which network operators the device used; helps spot operators that do not provide reliable data.

  • Satellites – at least 4 are needed for coordinates. With fewer, the device sends the last known good coordinates.

  • HDOP – accuracy of the position; the closer to 1, the better.

  • Input trigger – the event (IO ID) that generated each record. The most frequent trigger explains high data consumption.

Typical findings:

  • Object offline and no SMS reply: power supply voltage drops to 0 and the device runs on battery → check the power connection and whether the vehicle battery was disconnected. If the power connection is fine, the device may need repair (contact Ruptela support / your supplier for RMA).

  • Data delay: GSM signal level 0 or GPRS 0 during the delayed period.

  • Wrong or jumping location: low satellite count and high HDOP. Check the antenna and installation (3.2).

  • High data consumption: one input trigger generating most records, e.g. a digital input creating records every second (3.4).

Note: depending on the server, IO values may be shown in raw hexadecimal format. Convert them to decimal before interpreting, e.g. power supply voltage 3944 (hex) = 14660 mV = 14.66 V, not 3.9 V.

Step 5. Log collection

When the steps above do not reveal the cause, collect a device log and pass it to support. A log can be collected:

  • locally via USB with a terminal tool (ask Ruptela support which tool to use for your device model), or

  • remotely with the SMS command getlog (see getlog / stoplog). Ask Ruptela support for the log server parameters and provide the device IMEI.

Note: remote logging stops if the connection changes (e.g. after econnect or reset SMS, or general network issues). If the device cannot connect to the network, a remote log is not possible; collect a USB log, ideally while the device is still installed in the vehicle.

Escalating to Ruptela support

If the issue is not resolved, contact Ruptela support and include:

  • IMEI, device model and FW version;

  • the configuration file (or its relevant parts);

  • SIM provider and APN;

  • server type and connection settings (IP / domain, port, protocol);

  • a description of the problem, when it started and how many devices are affected;

  • the replies to getapn, gsminfo, coords and imei;

  • an export of the records received by the server for the problem period (if available);

  • the device log (Step 5), plus photos of the installation if a physical issue is suspected.

If a hardware fault is suspected (RMA)

When the device does not power on, has visible physical damage or the fault is reproduced on the bench, provide additionally:

  • photos or video of the device and the damage (see "Inspection for physical damage");

  • the result of the bench test with a known-good power supply and SIM card;

  • when the failure happened (right after installation or during normal operation) and any environmental factors (moisture, heat, vibration, electrical work on the vehicle);

  • the correct IMEI of every device. Double-check the IMEI against the device label, as a single wrong digit delays the process.

Support will confirm whether the device goes to the RMA (repair / replacement) procedure and send the RMA form to fill in.

Related Articles
Did this answer your question?