Concepts and workflow rather than a reference manual — what actually happens between a tracker in a vehicle and a position on your screen, and what to ask before you buy hardware.
Four stages, each of which can fail in its own characteristic way.
| Provide | Why it matters |
|---|---|
| Exact model and variant | Series names hide real hardware differences between variants |
| Firmware version | IO behaviour and supported commands change between firmware builds |
| Protocol documentation, if you have it | Turns integration into implementation rather than reverse engineering |
| One physical sample | Tells us what the firmware sends, which on clones differs from the spec |
| The data points you need to report on | Decides whether the unit is capable at all, before you order in volume |
| Current server address, if migrating | Lets us plan re-pointing and keep the old endpoint live during cutover |
Platforms implement protocols, not model numbers. A device that speaks a protocol the platform already decodes generally works on the day it ships, and a device that does not needs engineering work regardless of how similar it looks to something supported. That is why our device guides are organised by manufacturer protocol family rather than as a model list.
The exception, and it matters commercially, is IO mapping. Two units can share framing and still disagree about what input 3 means — one reports ignition, another a door sensor. That mapping is per model, and it is the single most common cause of a deployment that technically works while reporting nonsense.
With manufacturer documentation and a sample, a well-specified protocol is typically days of work. Without documentation it becomes reverse engineering from captured traffic, which takes longer and should be quoted separately rather than absorbed silently. What you should insist on from any vendor is a concrete answer — who does it, how long, what it costs — rather than "we will look into it".
Every manufacturer in our guides supports changing the destination server remotely, by SMS command or over-the-air configuration. That means a migration does not require visiting vehicles, which is what makes moving platforms affordable at all. We batch by fleet, keep your previous endpoint live through the window, and chase stragglers individually rather than declaring the job done at 95%. The full migration procedure is on the hosting page.
Send a model list and we will confirm against a live listener before you commit. Request a compatibility check or message us on WhatsApp.
With manufacturer protocol documentation and a physical sample, typically days rather than weeks for a well-specified protocol. Without documentation it becomes reverse engineering from captured traffic, which is slower and should be quoted separately. Ask for a timeline commitment rather than an assurance.
Both, and we ask for both. Documentation tells us the intended protocol; a physical unit tells us what the firmware actually sends, which on cloned hardware is frequently not the same thing. One sample prevents discovering a mismatch after a bulk order.
Yes. Re-pointing changes the destination server address and port in the tracker configuration, usually by SMS command or over-the-air. The SIM, APN and mobile plan are unaffected unless your current provider supplies the SIM under a bundled contract.
They arrive when the link returns, and are written against their original timestamps rather than the time of receipt. A tunnel or a dead-coverage route therefore leaves no gap in trip history — provided the platform acknowledges buffered records correctly, which is a common failure point on other systems.
Yes. We provide a staging listener so you can point one device at it and confirm the decode, the IO mapping and the reports before any commercial commitment. Ask for it on the first call rather than after signing.
Send the model, firmware version and manufacturer documentation if you have it. We will test against a live listener and give you a straight answer.
Request API Access →