Retranslating GPS data to external systems
We pass the coordinates and sensor data of your vehicles from Wialon into customers' logistics platforms, industry and government systems, BI tools and other monitoring platforms. We select the protocol, configure the retranslator and keep an eye on delivery; gaps left after a long outage at the receiving end are recovered by agreement.
- 08:00 Stream active, packets being accepted
- 10:42 Tractor unit 10-TR-305 off the air on the M-2, points held in memory
- 11:15 Points arrived late, timed by the tracker
- 14:20 Receiving server not responding — writing to their IT team
- 14:55 Port opened, stream restored
A stream of data for the selected vehicles runs into the recipient's system, and the recipient has confirmed in writing that the vehicles are being recognised correctly. You are left with a record sheet for the connection: what is sent, where, over which protocol and from which date, plus what to do if it fails.
When the data is needed by someone other than you
More and more often GPS data is asked for by somebody other than the fleet owner. A cargo owner wants to see your vehicles inside their own transport system. A haulage tender sets a condition: coordinates must be passed to the customer's system in real time. A holding company's head office runs its own monitoring platform and asks the subsidiary to feed a stream into it.
There is no need to fit a second tracker to every vehicle for that. Retranslation of GPS data works at server level: the tracker sends its data to Wialon exactly as before, and Wialon forwards a copy of the relevant messages in real time to the external system's address over an agreed protocol.
We take on the whole chain: the technical agreement with the receiving side, the configuration of the retranslator, the check that data arrives and is interpreted correctly, and the ongoing watch in case something breaks at either end.
How the work goes, step by step
The recipient's requirements
With the other side's IT team we settle the protocol, address, port and the vehicle identifier they expect.
Which vehicles are sent
Often not the whole fleet, only the vehicles on a particular contract. The recipient sees nothing else.
A stream from 1–2 vehicles
We wait for confirmation that the points arrived and the vehicles were recognised correctly.
The full list and the record sheet
We add the remaining vehicles and record what is sent, where and from which date.
Watching delivery
We check whether the retranslator is running, review its log and notify the agreed contacts under the support procedure.
Connecting a haulier to a customer's system
An illustrative example: 12 tractor units carrying loads out of the port at Alat, with the cargo owner requiring a stream into their own logistics platform.
- The customer's letter and the vehicle list start
You forward us the client's requirement — from there we deal with their IT team directly.
- Wialon IPS protocol, identifier is the registration number agreed
Registration number rather than IMEI, so that the vehicle does not vanish at the recipient's end when a tracker is replaced.
- Test stream from two vehicles test
We agree a reference packet: the time format, the parameter names, the coordinates.
- The recipient has not yet confirmed reception waiting
The longest wait is usually for the other side's answer, not for the configuration itself.
- All 12 vehicles visible at the customer's end accepted
The recipient confirmed in writing, and the go-live date went into the connection record sheet.
How retranslation from Wialon works
A retranslator in Wialon is a separate object with connection settings: the address and port of the receiving server, the protocol, and the list of vehicles whose data is to be forwarded. As soon as a new message from a tracker reaches Wialon, a copy goes out to the recipient.
The identifier matters. The receiving system has to work out which vehicle the data came from. Usually the tracker's IMEI is used for this, but a separate identifier can be set for retranslation: the registration number, say, or the vehicle's internal code in the customer's system. That is convenient when the tracker on a vehicle is replaced but the vehicle has to stay the same in somebody else's system.
What can be sent:
- coordinates, speed, heading, altitude and time;
- the state of the ignition and of the digital inputs;
- sensor values: fuel level, temperature, axle load;
- alert events, where the protocol supports them.
What is available depends on the protocol. Coordinates go through everywhere, but arbitrary sensor parameters do not.
Retranslation protocols: which to choose
Wialon IPS — an open text protocol
Wialon IPS was developed by Gurtam and is openly documented, so a great many third-party monitoring systems and logistics platforms support it. Data goes over TCP in text form, and a packet is easy to read and to debug.
This is our default choice when the receiving side is writing its own receiver: the developer only needs the specification, and we provide a test stream from one or two vehicles for debugging.
Besides coordinates, the protocol allows additional parameters to be sent as name and value pairs, so sensor readings reach the recipient too.
Where data most often goes
Cargo owners' logistics platforms
Large shippers and 3PL operators insist on seeing the haulier's vehicles in their own system, so they can follow the delivery and work out arrival times. For the haulier it is the condition for getting into the pool of contractors.
The parent company's systems
A holding with several legal entities gathers all its transport into one platform. The subsidiaries carry on working in their own accounts while the centre receives a combined stream.
Industry and government systems
Where transmitting data is a condition of a contract, a licence or a tender. We always take the specification from the operator of the receiving system.
Other monitoring platforms
The subcontractor works in one system and the main contractor in another. Retranslation avoids fitting a second tracker to the subcontractor's machines.
BI and in-house development
Where a company has its own dispatch software, data warehouse or dashboards, the stream of coordinates becomes their source. Here we often combine a retranslator with the API.
Insurers and leasing companies
Passing location and driving style data for insured or leased vehicles, by arrangement with the owner.
How the setup goes: from the customer's letter to a stable stream
It usually starts with a letter from your client: to work with us you must send GPS data into our system. From there the order of work is as follows.
- Technical agreement. We get in touch with the receiving side's IT team and establish the protocol, the server address and port, which vehicle identifier they expect, and whether sensors are needed.
- The vehicle list. Together with you we decide which vehicles to send. Often it is not the whole fleet, only those working on a particular contract.
- Test stream. We start retranslation for one or two vehicles and wait for the recipient to confirm that the points arrived and the vehicles were recognised correctly.
- Full go-live. We add the remaining vehicles and record the settings in a document: what is sent, where and from what date.
A typical setup fits into a few working days. The longest wait is usually for the other side's IT team to answer, not for the configuration itself.
If the aim is not to send data but to move to Wialon from another platform entirely, there is a separate service for that — data migration between platforms. Other ways of exchanging data with external software are gathered in the integrations section, and the typical requirements of logistics operators are covered on the page for 3PL and 4PL.
Why data fails to arrive, and how we catch it
Retranslation is a link between two servers, and it can break at either end. So once it is running we do not forget about it — we keep watch on delivery.
The receiving server is unreachable
A move to a new address, a change of port, a closed firewall. Wialon retranslates to the address given, and if nobody there is listening the data is lost as far as the recipient is concerned. We can see whether the retranslator is running, review its log and agree with the recipient how message receipt is monitored; when a failure is detected we notify the agreed contacts under the support procedure.
A vehicle has disappeared at the recipient's end
Most often after a tracker has been replaced: the new one has a new IMEI while the recipient is expecting the old one. The answer is a separate identifier for retranslation, one that does not change when equipment is swapped.
Data arriving late
If a vehicle was out of coverage, the tracker sends its stored points later, and they reach the recipient later too. It matters that the customer's system handles such older points by their timestamp rather than by the moment of receipt.
Gaps after a long outage
After an outage we check the retranslator log in Wialon and the interval actually received by the other system. Queued messages are not sent on by themselves: if the missing data is still available, we start a separate retransmission of the agreed past period in Wialon and reconcile the result with the recipient. Their system must handle late and duplicate points correctly.
The connection record sheet: what we set down for each recipient
Recipient and protocol
The recipient system and a contact in its IT team, the protocol (Wialon IPS, Wialon Retranslator, EGTS or API), the server address and port, how authentication and channel protection are handled, the vehicles and data shared, access rights and how they are revoked. For text-based Wialon IPS over TCP we separately agree a protected transport channel or another approved transfer arrangement with the recipient.
A sample packet
We agree one reference packet from a test vehicle with the recipient: which identifier it carries, in which format the time is given (UTC or local), the coordinates, the speed, and which additional parameters travel under which names.
The list of vehicles and data
Which vehicles are sent and from what date, and which sensor parameters are switched on. Anything that did not make the list is not visible to the recipient.
Delivery monitoring
Who notices that the stream has stopped and how: the retranslator status in Wialon, a message from the recipient, a regular check on several vehicles. Who is contacted on each side when it fails.
Recovering gaps
What we do if the recipient was unreachable for a long time: for what period a resend is possible, in what form (stream or file), and whether the recipient's system accepts points after the fact.
Authority and grounds
Transmission happens only on your decision as the owner of the data. We record the grounds (a contract with a customer, a tender requirement, a holding company decision) and the period of transmission, so that nobody has to work out later why the stream is still running.
The limits of the work and how it is signed off
What we do
The technical agreement with the recipient, configuring the retranslator or the export through the API, the test stream, go-live for the list of vehicles, and delivery monitoring as part of ongoing support.
What the recipient does
Building and supporting their own receiver, opening access on their server, and handling points that arrive late. If the receiver cannot parse the protocol we help with the diagnosis, but we do not write code on their side.
When the connection counts as accepted
The recipient has confirmed that every vehicle on the list is visible, that the identifiers match their own reference list, and that the times and coordinates display correctly. After that we record the go-live date on the record sheet.
What about sending the data straight from the tracker?
Another route is sometimes suggested: configure the tracker itself to send data to two servers at once. Teltonika trackers, for instance, have a setting for a second server in duplication mode.
It can be done, but the approach has its drawbacks:
- any change of address at the recipient's end means reconfiguring every tracker rather than one entry in Wialon;
- the tracker uses more mobile data, which is noticeable on vehicles in roaming;
- the recipient has to understand the tracker's native protocol rather than one common protocol for the whole fleet;
- with a mixed fleet of Teltonika, Queclink and other models, the configuration ends up different for each.
So for most jobs we choose server-side retranslation. Duplication from the tracker we keep for cases where the recipient, for whatever reason, will only accept data straight from the equipment.
What you get
No second tracker
One installation on the vehicle, with the data distributed to the systems that need it at server level.
The customer's requirement met
Transmitting GPS data helps meet the relevant technical requirement in a tender or contract. Eligibility and selection also depend on the customer's other requirements.
Control over what is sent
You decide which vehicles and which parameters the external party sees. The rest of the data stays with you.
One place to go
If the data stops arriving at the recipient's end, we sort it out, rather than your dispatcher and somebody else's IT department.
Which method of transmission to choose
The protocol is most often dictated by the receiving side.
| Wialon IPS | Wialon Retranslator | EGTS | Through the API | |
|---|---|---|---|---|
| When we choose it | The recipient writes the receiver | Wialon on the other side too | Government and industry systems | BI and accounting systems |
| Real-time stream | Yes | Yes | Yes | On request: frequency depends on the integration |
| Sensor data | Yes, as name and value | Yes | As the operator specifies | Messages and calculated sensor values when the request is set up for them |
| Who builds the receiving end | The recipient, from the specification | Already there in Wialon | The system operator | The recipient themselves |
Questions about “Retranslating GPS data to external systems”
Request a call
A specialist will call back and match a solution to your fleet and your task.