Which protocols do Skywonder devices ship with?
Two protocols cover the range. Vehicle, OBD and asset trackers use GT06, the binary TCP format published by Concox and adopted across most Shenzhen-built hardware. Video devices use JT/T 808, the Chinese standard for commercial vehicle terminals. The tracker range that speaks GT06 is listed under 4G GPS trackers.
GT06 holds a persistent TCP socket open, so capacity planning starts from concurrent connections rather than request rate. For the wire format in depth, read the full GT06 protocol guide; for what the server does with the packets, see GPS tracking software.
Protocol by device class
| Device class | Protocol | Transport | Typical use |
|---|---|---|---|
| Hardwired vehicle trackers | GT06 | TCP, persistent socket | Fleet, recovery, vehicle finance |
| OBD plug-in trackers | GT06 with OBD message types | TCP, persistent socket | Rental, driver behaviour, diagnostics |
| Wireless and asset trackers | GT06 | TCP, persistent socket | Trailer, container, equipment |
| 4G dashcams | JT/T 808 | TCP | Live view, video playback, driver monitoring |
| Multi-channel AI MDVR | JT/T 808 | TCP | Bus, truck and logistics video |
GT06 4G GPS Tracker For Car No Monthly Fee
Reference GT06 unit for server testing: 4G over TCP, OTA upgrade.
C30 4G OBD GPS Tracker
OBD plug-in tracker; see the product page for the full specification.
Y8 4G GPS Tracker
Solar-powered IP67 asset tracker for long-duration field testing.

Wd10 4 Channel AI MDVR With ADAS DMS
Four-channel Linux MDVR with ADAS and DMS for JT/T 808 video work.
Get a volume quote
Tell us the models, quantity and destination country. Quotes usually come back within one business day.
GT06 in one page, and where the full reference lives
Every Skywonder tracker speaks GT06 over a plain TCP socket: a frame opens with 0x78 0x78, carries a length byte, a protocol number, the payload, a two-byte serial and a CRC-16/X-25 checksum, and closes with 0x0D 0x0A. The device logs in with its IMEI, then streams heartbeat and position packets that the server must acknowledge.
The byte-level reference is deliberately kept in one place so it stays correct: GT06 protocol explained covers the frame layout, the length-byte rule, the checksum, every protocol number, the login and acknowledgement sequence and worked packet examples. This hub links to it rather than repeating it.
What integrators most often need beyond the packet spec is listed below: which Skywonder models emit which optional packets, how to point a device at your server, and how to validate a parser against real traffic before a pilot.
GT06 at a glance (full field-level detail in the protocol post)
| Stage | What happens | What your server must do |
|---|---|---|
| Login | First packet on every connection carries the IMEI as packed BCD | Match the IMEI to a registered device and acknowledge inside the idle timeout |
| Heartbeat | Status packet every few minutes while idle: battery, voltage, signal | Acknowledge; use it for online/offline state |
| Position | GPS + LBS packet while moving; alarm variant carries SOS, low battery, geofence flags | Store, then acknowledge; trust the length byte over memorised offsets |
| Commands | Server command packet sets APN, server, interval, or triggers relay output where the model supports it | Wait for the command response packet before assuming success |
JT/T 808 for dashcams and MDVRs: what it covers
JT/T 808 is the signalling protocol Skywonder 4G dashcams and MDVRs use. Frames are delimited by 0x7E with byte stuffing, the length sits in a 16-bit header field, and the checksum is an XOR-8 rather than a CRC.
Video units also implement JT/T 1078, the audio/video extension to 808 - 808 carries registration, position, alarms and commands, 1078 carries live streaming, playback and file upload (the WD02 datasheet lists both). Confirm 1078 coverage for your model and firmware.
The difference from GT06 is origin and reach: JT/T 808 is the Chinese Ministry of Transport standard for commercial vehicle tracking and is mandatory in many domestic Chinese fleet deployments, while GT06 is the format adopted for internationally sold trackers. Confirm the message coverage for your model and firmware before you commit to a decoder.
- 0x7E framing with byte stuffing, a 16-bit length field inside the header and an XOR-8 checksum rather than a CRC.
- Position and status reporting from the terminal, with GPS and alarm data uploaded alongside the video record.
- Remote monitoring on units such as the WD10 MDVR: live video, high-definition screenshots, recording and playback.
- Alarm and event handling, including ADAS and DMS events from AI MDVR units.
- Remote upgrade: the WD10 accepts firmware upgrades over the platform as well as by SD card or U disk.
Plan storage and data before you deploy video
Video telematics fails on bandwidth and storage budgets more often than on protocol details. Work out channel count, bitrate and recording hours per shift with the dashcam storage calculator and the 4G dashcam data usage calculator before quoting.
Connecting a device to Traqcare
Traqcare is the Skywonder platform: a web app plus iOS and Android apps, white-labelled with a reseller brand and logo. The documentation at docs.traqcare.com describes live tracking, playback, alerts and geofences, reports, fuel management, device management and user roles.
API and webhooks
The published Traqcare documentation covers the web and mobile apps and does not document a public API, SDK or webhook interface. If your project needs programmatic access or a push integration, raise it on the contact form rather than assuming an endpoint exists.
Resellers can also run the same hardware on their own server or a third-party platform. The build-versus-buy comparison covers that choice in commercial terms.
- 1
Sign in
Log in to the Traqcare web app or the iOS or Android app with credentials issued by your administrator. What you can see and change follows the user role assigned to your account.
- 2
Open device management
Device management is available in both the web and the mobile apps; the documentation at docs.traqcare.com covers the current screens.
- 3
Enter the IMEI
Identify the device by its IMEI, the same identifier the tracker sends to the server in its GT06 login packet.
- 4
Select the device type or model
Pick the matching model so the platform has an accurate record of what the device is.
- 5
Name the vehicle or asset
Enter the name identifying the vehicle or asset. This is what customers see in the app.
- 6
Save the device and wait for data
Save the device, then wait for the first position report. See docs.traqcare.com for the fields the form accepts.
See the platform
A 30-minute walkthrough of the Traqcare platform and white-label apps with your fleet or reseller use case.
Connecting to Traccar, Wialon, Navixy and GPS-Trace
Skywonder devices are compatible with third-party platforms such as Traccar, Wialon, Navixy and GPS-Trace. Traccar and OpenGTS implement GT06 natively; on the other platforms, check the device list for the entry matching your model.
The work is the same three steps everywhere: select the protocol or device model, register the device by IMEI, and write the platform host and port into the device.
Writing the server address into the device
Server host and APN can be set with the GT06 server command (protocol number 0x80), and thresholds such as overspeed can also be set by SMS on models that support it. The command set differs by model and firmware, so request the sheet for your SKU with the sample order.
Two habits save a support queue later: confirm the APN with the SIM provider before blaming the tracker, and read settings back, because an accepted command is not always a command that took effect.
Per-platform integration inputs
| Platform | Select in the platform | Identify device by | Set on the device |
|---|---|---|---|
| Traccar | GT06 for trackers | IMEI | Host and port your instance listens on |
| Wialon | Matching device type from the catalogue | IMEI as unique ID | Host and port from your Wialon provider |
| Navixy | Matching device model at registration | IMEI | Host and port shown by Navixy |
| GPS-Trace | Matching device type when adding a device | IMEI as unique ID | Host and port in the add-device screen |
| Your own server | Your GT06 or JT/T 808 decoder | IMEI from the login packet | Host and port of your listener |
Open-source GT06 parsers and how to validate one
You do not have to write a decoder from scratch. Open-source servers such as Traccar and OpenGTS implement GT06 natively, and the Traccar Java decoder maintains working implementations for every common variant.
Treat any parser as a starting point: the original Concox document defined fewer than a dozen message types, and manufacturers have since added their own for OBD, dashcam, RFID and peripheral data. The only reliable acceptance test is real traffic from the exact SKU and firmware you will ship, replayed through the parser and compared against a known-good platform.
- Verify the CRC first. Generic CRC-16 calls are the most common cause of every packet being rejected with no obvious diagnosis.
- Advance the read buffer using the length byte, not a fixed frame size, or the stream desyncs after the first packet.
- Decode the IMEI as packed BCD, not ASCII, or devices never match records in your database.
- Echo the information serial in every ACK; zeros make some firmware retransmit indefinitely.
- Log unknown message types as raw bytes instead of throwing, so one variant cannot take the listener down.
Device configuration checklist before a pilot
Most failed pilots are configuration problems, not hardware problems. Work through this list on the bench before sending stock to installers.
- APN confirmed with the SIM provider, with username and password where required.
- Server host and port written and read back, matching your listener for that protocol.
- IMEI recorded against the vehicle or asset in your platform before the unit leaves the bench.
- Protocol variant confirmed with engineering for that model and firmware, including vendor status flags.
- Alarms each triggered once on the bench and seen in the platform.
- Firmware: OTA upgrade path checked where supported, with UTC stored server-side.
- Power behaviour: power-cut and low-voltage alarm handling checked on a vehicle.
- Certification scope: Skywonder manufactures to CE, FCC, PTCRB, IC, RoHS, REACH and ISO 9001 standards; confirm the scope for your SKU on the certifications page and check local regulations for your market.
Samples and a development kit for protocol work
Integration work needs hardware on the desk. Sample orders run 3 to 10 units and ship within 5 to 7 business days by express courier: enough for one tracker, one OBD unit and a camera.
In-stock models ship in 3 to 7 days, custom or high-volume runs take 15 to 25 days after deposit, and MOQ is 50 to 100 units depending on the product. The white-label programme starts at 100 units: see the reseller program, the MOQ guide and the import guide.
Hardware carries a 12-month manufacturer warranty against manufacturing defects, and pricing is quoted per model and volume. Send the model list and quantities through the contact form or WhatsApp; protocol questions go to support.
Pick the sample mix from the vertical you are integrating for: fleet management, auto finance and BHPH or logistics and cold chain.
GX3 Vehicle GPS Tracker
Hardwired 4G tracker with power-cut, overspeed and geofence alarms.
W10 4G Standby King
LTE Cat 1 asset tracker for long-interval reporting and power saving.
Wd02 AI Dashcam
AI dashcam sample for a first JT/T 808 integration.
Test before you commit
Order 3–10 sample units and evaluate them on your own platform or on Traqcare before placing a production order.
Frequently asked questions
What protocol do Skywonder GPS trackers use?+
Vehicle, OBD and asset trackers use GT06, a binary TCP protocol published by Concox and implemented by most Chinese tracker manufacturers. Dashcams and MDVRs use JT/T 808, the Chinese Ministry of Transport standard for commercial vehicle tracking. Confirm the exact variant for your model before finalising a decoder, because extensions differ by firmware.
Is GT06 supported by Traccar?+
Yes. Traccar implements GT06 natively, as does OpenGTS, so a self-hosted instance receives Skywonder trackers without a translation layer. Select GT06, register the device by IMEI, and point it at the host and port your instance listens on.
What is the difference between GT06 and JT/T 808?+
GT06 came from Concox and is the de-facto format for internationally sold Chinese trackers: frames wrapped in 0x7878 and 0x0D 0x0A with a CRC-16/X-25 checksum. JT/T 808 is a Chinese Ministry of Transport standard: 0x7E delimiters with byte stuffing, an XOR-8 checksum, and registration, authentication and media handling.
How do I point a Skywonder device at my own server?+
Server host and APN are written to the device with the GT06 server command (protocol number 0x80), and some settings can also be sent by SMS on models that support it. The command set varies by model and firmware, so request the sheet for your SKU with the sample order and read the settings back afterwards.
Is there a Traqcare API?+
The published Traqcare documentation covers the web app and the iOS and Android apps, and does not document a public API, SDK or webhook interface. If your deployment needs programmatic access or a push integration, describe the requirement on the contact form. You can also run the hardware on your own server.
Can I use an open-source GT06 parser?+
Yes, and most integrators start there. Open-source servers such as Traccar and OpenGTS implement GT06 natively, and Traccar maintains a production Java decoder. Validate any of them against captured packets from the exact model and firmware you will ship, because coverage varies by device.
What do I need to test the protocol before ordering?+
One sample unit per device class, an activated SIM with a confirmed APN, and a reachable listener on a public host and port. Samples are 3 to 10 units and ship within 5 to 7 business days. Capture real traffic, replay it through your decoder, then size the order.
Do you support firmware or protocol customisation?+
Custom firmware work is possible on higher-volume programmes, and custom or high-volume runs take 15 to 25 days after deposit. The first step is telling us which message types and fields your platform needs, so engineering can confirm what current firmware emits. Send that with your model list when requesting a quote.
Get a volume quote
Tell us the models, quantity and destination country. Quotes usually come back within one business day.