The GV, GL and GB families report over @Track. The platform handles both the ASCII and binary forms, including the acknowledgement behaviour that keeps buffered records from being lost.
Consistent firmware behaviour across the range, which makes a mixed Queclink fleet far easier to operate than a mixed-brand one.
Protocol-level facts from the manufacturer’s own documentation. Model-level behaviour varies within a series, so confirm your exact unit with us rather than assuming.
| Item | Supported | Notes |
|---|---|---|
| Protocol family | @Track ASCII and binary | Same command set in two encodings |
| Transport | TCP and UDP | UDP common on battery-powered asset units |
| Series commonly deployed | GV (vehicle), GL (portable), GB (asset), GMT | Form factor differs, protocol does not |
| Acknowledgement | Server ACK required for buffered records | Missing ACKs are the usual cause of duplicate reports |
| CAN data | Supported on selected GV models | Depends on the unit, not the protocol |
| Sensors | Digital and analogue inputs, 1-Wire | Fuel, temperature and driver ID |
| Remote configuration | SMS and over-the-air commands | Server, interval and report mask all settable |
Most platform vendors publish a list of supported model numbers. It looks reassuring and it is usually out of date, because it describes a snapshot of what somebody tested once rather than how the integration actually works. GPS platforms do not implement models; they implement protocols. Queclink devices report over @Track (ASCII and binary) across TCP and UDP, and the platform decodes that protocol — which is why a new unit in the GV, GL, GB, GMT families generally works on the day it ships rather than after a development cycle.
What genuinely varies between models is not the protocol but the hardware: which inputs physically exist, whether a CAN interface is present, whether there is a relay output, how many 1-Wire devices can be attached. That is why we ask for your exact model and firmware version rather than publishing a matrix. It takes us a day to confirm against a live server, and it is the difference between a deployment that works and one that discovers a missing input after the units are installed.
Send the model, the firmware version and what you need to report on. You will get back a straight answer on three things: whether the unit reports into the platform at all, which of your required data points it can actually produce, and whether a cheaper unit in the same range would do the same job. That last one costs us margin and saves you money, which is the point — a fleet that buys the wrong hardware blames the platform.
Queclink units already in the field can be re-pointed to a new server remotely, so a migration does not mean visiting vehicles. We audit what is connected first, import your historical data, re-point a pilot group, and cut the rest across only once the pilot reconciles cleanly against your old system. The old endpoint stays live through the window. Full detail is on the hosting and migration page.
Send your Queclink model list and we will confirm compatibility against a live server before you commit. Request a compatibility check or message us on WhatsApp — include firmware versions if you have them, and tell us what you need to report on.
The @Track protocol is implemented in both ASCII and binary form, which covers the GV series including the GV75. Model-specific behaviour — which inputs exist, whether CAN is present — varies by unit rather than by protocol, so send us your model and firmware and we will confirm against a live server.
Almost always because the server is not acknowledging buffered records correctly. Queclink devices re-send anything they believe was not received, so a missing or malformed ACK produces exactly this symptom. Our ingestion handles the acknowledgement contract properly; if you are seeing duplicates on another platform, that is the first thing to check.
TCP for wired vehicle units, where a persistent connection costs nothing and delivery is more predictable. UDP for battery-powered asset trackers, where avoiding connection setup on every report meaningfully extends battery life. The platform accepts both simultaneously, so a mixed fleet is not a problem.
Yes, and most fleets of any size eventually do. Each protocol has its own listener, and both normalise into the same position and event model, so reports, geofences and alerts work identically regardless of which brand produced the data.
A GB or GL unit reporting once every few hours is behaving correctly, not failing, so the platform does not raise the offline alerts that suit a vehicle tracker. Battery state is tracked as its own metric with alerting before a unit goes dark, which is the failure that actually matters on asset deployments.
Send us your exact models and firmware versions. We will test them against a live server and tell you what works before you commit to anything.
Check My Device →