Prerequisites Before You Begin
Mictrack asset trackers communicate over an open, documented ASCII protocol via standard TCP or UDP sockets — there is no proprietary cloud dependency required. Before connecting a device to your own server, confirm you have:
- A server with a public IP address or resolvable domain name, reachable from the public internet on your chosen port
- The device's IMEI (printed on the unit label and visible in device status reports)
- A working cellular connection on the device (correct APN provisioned — see our APN configuration guide if this is not yet set up)
- The Mictrack Config Tool or SMS access to the device
Server IP/Domain and Port
Your server needs a stable address the device can reach every time it reports. A static public IP is preferred; a domain name is also supported, provided it resolves reliably. Choose an unused port on your server for the tracking listener — this does not need to be a specific reserved port, but it must be open on your firewall (see below) and not already in use by another service.
Choosing TCP or UDP
Mictrack devices support both TCP and UDP transport for the same open protocol payload:
- TCP is connection-oriented and guarantees delivery order — generally the safer default for most deployments, especially where reliable delivery matters more than minimizing packet overhead.
- UDP has lower overhead per packet, which can be preferable for very high-frequency reporting or constrained bandwidth scenarios, at the cost of no built-in delivery guarantee.
If you are unsure which to choose, TCP is the more common starting point for a private server integration.
Device ID and IMEI
Every report packet is tagged with the device's unique IMEI, which your server-side application uses to identify which physical asset a given position update belongs to. Keep a record mapping each device's IMEI to the asset it's mounted on before deployment — this is the join key your ingestion logic will rely on.
APN and Network Registration
The device must successfully register on the cellular network and establish a data session (via the correct APN) before it can reach any server at all — server connectivity issues are frequently actually APN issues. If the device isn't reporting, verify network registration and APN configuration first, before troubleshooting server-side.
Configuring the Server Address
Using the Mictrack Config Tool (USB) or the equivalent SMS command set, set the device's server IP/domain and port. Save and power-cycle the device if prompted. The device will attempt to connect on its next scheduled report or wake cycle, depending on its configured working mode.
Heartbeat and Reporting Behavior
Depending on the working mode configured (periodic, motion-triggered, or hybrid), the device opens a connection, sends its report packet, and either holds the connection briefly for acknowledgment or closes it immediately to conserve battery. Your server implementation should be prepared to accept short-lived connections rather than assuming a persistent, always-open socket per device.
Firewall and Connectivity Checklist
- Confirm the chosen port is open inbound on your server's firewall for both TCP and UDP as applicable
- If your server is behind NAT or a cloud load balancer, confirm the port is correctly forwarded to the listening service
- Test connectivity from an external network before deploying devices in the field — a firewall rule that only allows internal traffic will silently block every device
Using a Third-Party Platform Instead
If you'd rather not run your own server, Mictrack devices are natively supported in open-source Traccar (port 5030) and have configuration profiles for platforms including Wialon and Flespi — see the full list of supported third-party platforms. Our Open Protocol overview covers the underlying packet structure in more depth.
Troubleshooting Connection Issues
- No data reaching the server at all: Check APN/network registration first, then server IP/port configuration, then firewall rules — in that order.
- Data arrives intermittently: Check cellular signal strength at the deployment site and confirm the working mode's reporting interval matches your expectation.
- Server receives connections but data looks malformed: Confirm you're parsing the protocol correctly — download the official protocol specification PDF for your model rather than reverse-engineering the packet format.
For deployment-specific help, contact our engineering team — we can help validate a test configuration before full-scale rollout.
