Send GPS Data to Your Own Server: TAIP & Wialon IPS Guide

🎯 Who this article is for: integrators and developers who run their own backend and want the GPS tracker to report directly to their server — no mandatory platform in between.

Many of the technical inquiries we receive start the same way: "we already have our own platform, we just need hardware that talks to it." That is exactly what Rinho devices are built for: the tracker measures and transmits (its onboard event rules decide when and what to report); business alerts, rules and reports live on your server. This guide covers the full path to send GPS data to your own server: choosing between Rinho TAIP and Wialon IPS, pointing the device at your host and port, standing up a receiver, parsing real frames, and hardening it for production.

Step 1: pick the protocol — TAIP or Wialon IPS

Every Rinho tracker — Zero IoT, Smart IoT and Spider IoT — speaks two open output protocols:

	Rinho TAIP	Wialon IPS
Best for	Receiving data on your own server	Connecting to a platform that already speaks IPS
Type	ASCII, Trimble TAIP base with Rinho extensions	Open protocol published by Gurtam (v1.1)
Transport	UDP and TCP, identical framing	TCP/UDP
Telemetry	Full extended set: temperatures, backup battery, hour meter, iButton driver ID, CAN bus (OBD-II / J1939)	As defined by the IPS standard
Docs & tooling	30-page integration guide (PDF) + open-source sample server	Supported by Wialon, Navixy, Traccar and others

The rule of thumb: if you are building your own ingestion, use Rinho TAIP — it is the fully documented native protocol, and the rest of this guide walks through it. If you are connecting to an existing third-party platform, use Wialon IPS (available across the lineup since firmware v1.09.19): see the Wialon IPS announcement for supported platforms and connection details.

Step 2: point the device at your host and port

Destination host, port and transport (UDP or TCP) are per-device settings; the fastest way to set them is the web configurator. TAIP listeners typically run on port 4031 (primary) and 4034 (secondary), but ports are fully configurable. Two things worth knowing before you deploy:

• The device identifies itself with an ID= field in every message — typically the IMEI.
• Once online, it sends a keep-alive every 60 seconds (configurable), so your server always knows which devices are alive.

The hardware model does not change the integration: Zero, Smart and Spider are identical at the protocol level, and any model can generate any report type — the report type is configured per device, not determined by the hardware.

Step 3: stand up the receiver

Your transport choice defines the receiver's job:

• UDP: connectionless. Keep a NAT table mapping each device ID to the source IP:port of its last packet, send commands back to that address through the same socket, and expire entries not seen for an extended period (e.g. 24 hours).
• TCP: the device opens a persistent connection to your server. Since TCP is a stream, buffer incoming bytes and extract complete >...< frames — a segment can carry several messages, or a message split across segments.

In both cases, a single datagram or segment may contain multiple frames: always scan for every >...< in the received data.

You don't have to start from zero. The open-source rinho-udp-server (Node.js, MIT license) listens on a configurable UDP port, parses standard position reports, sends ACKs, tracks active devices, queues commands with retries and stores to MySQL. It is a learning/testing sample — not production-ready as-is — but it shows every moving part. This is its XOR checksum routine, verbatim:

exports.calculateChecksum = function (cmd) {
    var checksum = 0;
    for (var i = 0; i < cmd.length; i++) {
        checksum = checksum ^ cmd.charCodeAt(i);
    }
    var hexsum = Number(checksum).toString(16).toUpperCase();
    if (hexsum.length < 2) {
        hexsum = ("00" + hexsum).slice(-2);
    }
    return hexsum;
}

The checksum is the XOR of every byte from > up to and including *, formatted as two uppercase hex digits. Frames with a bad checksum are silently discarded — never ACKed.

Step 4: parse the frames

Every TAIP message follows the same structure:

>BODY[;#MSGNUM];ID=DEVICEID;*CHECKSUM<

Here is a sample standard position report (type RCQ):

>RCQ28060426153025-3462000-05838000045180A2031280000001103051005121115;#002A;ID=860012345678901;*4E<

After the 3-character prefix (R + report type), the base is always 66 fixed-position characters. Key fields from this frame:

Field	Raw	Decoded	Rule
Date/time (UTC)	060426153025	2026-04-06 15:30:25	device GPS clock
Latitude	-3462000	-34.62000°	÷ 100000
Longitude	-05838000	-58.38000°	÷ 100000
Speed	045	45 km/h	km/h, not knots
Course	180	180°	direct
Inputs	A2	ignition ON (bit 7) + IN05 + IN01	hex bitmask
Main voltage	128	12.8 V	÷ 10
Odometer	00000011	17 m	hex → meters
Satellites / PDOP	10 / 05	10 satellites, PDOP 5	decimal

RCQ is one of 14 report types that share this 66-char base; suffixes add temperatures (RCR/RCV), backup battery voltage (RBQ), backup battery + engine hour meter (RHQ), iButton driver ID (RCT), driver sessions (RCU), and CAN bus data as OBD-II PIDs (REQ) or J1939 SPNs (RER). Custom sensor values (BLE temperature, fuel, etc.) travel in an AP= or PA= segment (both prefixes are equivalent; firmware version determines which is used) with typed name:type:value parameters — note that some legacy scripts emit untyped name:value pairs. Two conversions that bite real integrations: the temperature age field is hexadecimal (0x00–0xFF seconds) while PDOP is decimal, and the hour meter converts hex → seconds of engine runtime. The full field maps are in the protocol integration guide (PDF).

Step 5: production — ACK, keep-alive and reliability

Reliability is built on message numbering plus ACK. Your server must acknowledge every message carrying a #MSGNUM below 0x8000, echoing the exact msgNum and device ID:

Device → server:  >RCQ28060426153025-3462000-05838...;#002A;ID=860012345678901;*4E<
Server → device:  >ACK;#002A;ID=860012345678901;*38<

• ACK only after persisting. If your database write fails, do not ACK — the device retransmits (7-second timeout, up to 4 retries per message, up to 9 messages in flight in parallel). This is what guarantees no data loss.
• Never ACK keep-alives. >KA;ID=860012345678901;*10< arrives every 60 seconds; just refresh your NAT table (UDP) or connection state (TCP) and stay silent.
• msgNum ≥ 0x8000 is a response, not a new report. A command you send as #0042 comes back confirmed as #8042 (bit 15 set). Match it to the pending command — do not ACK it.
• Secure the perimeter. The protocol is plaintext with ID-based identification only, so restrict who can reach your ingestion port (VPN, IP whitelisting, firewall) and validate device IDs against your own device registry.

Commands use the same framing in the other direction — from your backend you can query firmware (>QVR;#0042;ID=860012345678901;*51<), read the IMEI and serial number, or push configuration.

Resources

Rinho Telematics:

• Rinho Protocol Integration Guide (PDF) — 30 pages: framing, checksum, all 14 report types, ACK mechanism, commands and sample messages.
• Web configurator — set destination host/port and device options from the browser.
• Technical documentation — firmware and configuration reference.
• Wialon IPS announcement — if you are connecting to an existing platform instead.

External resources:

• rinho-udp-server on GitHub — open-source Node.js reference receiver (MIT).

In short

• Rinho trackers report directly to your host:port over UDP or TCP — Rinho TAIP for your own backend, Wialon IPS for platforms that already speak it. No intermediate platform required.
• The protocol is ASCII and fully documented: a 66-character position base, extended telemetry suffixes, and ACK with retransmission (7 s timeout, 4 retries) so transient failures don't silently drop data.
• Between the PDF guide and the sample UDP server, you can be parsing live frames from a real device the same day.

Building your solution on your own backend? That is the exact profile we designed for: open protocol, documented hardware, factory-direct support. Start at our For Integrators page, or contact us and we'll help you get your first frames arriving at your server.