Home/Blog/Engineering

GPS protocols: why two “compatible” devices do not report the same

What is inside a frame, why certifying a device is not configuring an IP, and what to ask when you are told a model is “already supported”.

“That device is already supported” means very different things depending on who says it. Sometimes it means the platform draws the dot on the map. Other times, that it understands the forty signals the device sends. The difference shows the day a customer asks for a fuel report.

What a tracking protocol actually is

A tracker does not send “I am at this latitude and longitude”. It sends a byte sequence with a structure defined by the manufacturer: header, device identifier, message type, payload, checksum and terminator. Inside the payload go position, speed, heading, input states, voltage, odometer and whatever else the manufacturer decided to include.

There is no universal standard. Every device family has its own, and between versions from the same manufacturer fields change order, size or meaning.

The families you will meet most

  • GT06 and derivatives. Originated at Concox and adopted by a huge number of Asian manufacturers. It is the most widespread and also the most fragmented: there are dozens of variants with the same name that are not the same.
  • Teltonika codec. Well documented and seriously versioned. It carries identified input/output elements, which means adding a new sensor does not break anything.
  • Queclink. Delimited text messages, easy to debug by eye, with a consistent naming convention across models.
  • Suntech, Ruptela, Galileosky, Meitrack. Each with its own binary structure and its own event catalogue.

Why certifying is not configuring an IP

Pointing a device at a server takes two minutes. Getting the platform to understand what it sends is another matter. Certifying means, at minimum:

  1. Writing the parser that turns bytes into meaningful fields.
  2. Mapping each field to the platform's data model, so that a digital input on that device is “the same digital input” as on any other.
  3. Implementing commands in the other direction: the platform has to be able to ask the device for something, not only listen.
  4. Handling the odd cases: split frames, replay of positions stored during a coverage gap, time-zone changes, counter overflows.
  5. Testing with the physical unit, because the manufacturer's documentation and the actual firmware do not always agree.
The hard work is not reading the normal frame: it is handling well the ten anomalous situations that appear once every thousand messages and that, with ten thousand devices, happen constantly.

The trap of on-device memory

When a vehicle loses coverage, a decent device stores positions and sends them all at once when signal returns. It sounds simple and it is where many integrations fail.

The problem is ordering and timestamps. If the platform treats those old positions as current, the vehicle appears to jump around the map, geofences fire late and the trip report comes out wrong. A correct integration separates event time from server arrival time and reorders before running the rules.

What to ask when told “it is already supported”

  • Which firmware version did you test, and with which regional variant?
  • Which protocol fields are mapped and which are discarded?
  • Can commands be sent to the device from the platform, or is it receive-only?
  • Do you handle stored-position replay respecting the event time?
  • Are digital inputs and outputs identified, or do they arrive as a raw number someone has to interpret?
  • Do fuel and temperature probes connected to the device arrive calibrated or raw?

The last one is the most revealing. Many integrations “support” a device in the sense that they show the dot, but deliver the sensor value uninterpreted, and then the fuel module is useless.

Why normalisation matters so much

If every protocol is handled as a special case all the way up, every report and every rule has to know about every device. The system becomes impossible to maintain: adding a model means touching forty places.

The alternative is to translate early. The parser converts the frame into a common model and from there on nothing knows which manufacturer it came from. A speeding rule behaves identically with any certified device, and adding a new model does not touch the rest of the system.

What this means for you

When you evaluate a platform, the number of certified devices says less than it seems. What matters is the depth of each integration and how fast they can add the model that just landed in your container. A catalogue of a thousand devices reading only position is worth less than one of two hundred reading the full protocol.

Did this help?

We build custom software and license ADN Vortex white label. Tell us your case and we give you a concrete answer.