End of month. Finance drops the bill on your desk. Your fleet's SIM card data charges are over budget. Again.

The vendor's sales rep calls with a helpful suggestion: 'Your devices are reporting too frequently. We'd recommend upgrading each unit from the standard 30MB plan to a 50MB pooled data plan. We'll give you a volume discount on the per-unit rate.'

You figure the fleet runs 10-second reporting intervals, so heavier data usage makes sense. You sign off. Add a few thousand dollars a year to your communications overhead.

Here's the reality: a GPS tracker that's only transmitting coordinates — no video, no audio — running a default configuration of 20-second intervals while moving and a single heartbeat ping every 5 minutes while stationary, should comfortably run on 30MB per month. When the vehicle stops, the heartbeat packet just refreshes the timestamp and maintains the last known position. The data consumption is negligible.

The 30MB standard plan exists because that's genuinely what a well-engineered device needs. If you're blowing past it, the problem isn't your reporting frequency. The problem is what your device is actually sending.

WHY YOUR DEVICE IS USING MORE DATA THAN IT SHOULD

The answer is almost always one of two things: the wrong protocol for the application, or an inefficient data format. Usually both.

The protocol problem: TCP vs. UDP

Most cheap devices default to TCP for everything. TCP is reliable — it guarantees packet delivery, handles retransmission, keeps a persistent connection open between the device and the platform. For certain applications, that's exactly what you need.

For GPS position reporting, it's often overkill — and expensive.

Here's what actually happens when a TCP device sends a location update: before transmitting your 50-byte coordinate payload, the device runs a three-way handshake (SYN, SYN-ACK, ACK).

The server sends back acknowledgment packets. If the network hiccups — which it does, constantly, on mobile networks — TCP's retransmission mechanism kicks in and sends everything again. You wanted to transmit 50 bytes of position data. The underlying network exchange consumed 300 bytes of protocol overhead to do it.

That's like hiring an armored truck to deliver a postcard.

The right answer depends on the device type. UDP drops the persistent connection after transmitting — the link closes, the overhead disappears, location updates are fast and lightweight. The tradeoff is lower interference resistance: in areas with signal degradation, packets can get lost. For wireless battery-powered devices where power and data efficiency matter most, UDP is usually the right choice. For hardwired devices — vehicles where a persistent, always-on connection makes sense — TCP with a properly configured heartbeat (every 5 minutes, switching to active reporting immediately on movement detection) is the correct approach.

The problem isn't TCP. The problem is vendors who default everything to TCP regardless of device type and let the customer pay for the overhead.

The data format problem: HEX vs. JSON

Most GPS firmware today is written by engineers with a web development background. They default to JSON or ASCII encoding because it's readable and easy to debug.

In IoT, it's a data budget disaster.

Expressing longitude 114.05786 in ASCII takes 9 bytes. Wrap it in proper JSON with field names — {'longitude':'114.05786'} — and you're at 25+ bytes just for one coordinate. Add latitude, timestamp, speed, heading, satellite count, voltage, and device status, and a single position report balloons to several hundred bytes before you've added any protocol overhead.

The HEX alternative: multiply 114.05786 by 10⁵, convert to an integer, encode in binary — 4 bytes. A complete position packet with all the same fields compresses to a fraction of the JSON equivalent. Across thousands of devices reporting multiple times per minute, this difference compounds fast.

THE STRUCTURAL INCENTIVE PROBLEM

The data inefficiency in most GPS hardware isn't accidental. It's the product of two sets of incentives that happen to align against you.

Hardware manufacturers optimize for development speed, not data efficiency. The standard approach — MQTT or HTTP over TCP, JSON payload — connects to customer platforms with minimal custom development. It works, it's fast to implement, and the data costs land on the customer, not the manufacturer. Most GPS hardware today is built on chipset platforms from manufacturers in Shenzhen — MTK, Allwinner, SK, and custom silicon designs. The underlying chipsets are capable of efficient, protocol-optimized communication. The firmware running on them often isn't, because efficient firmware takes longer to write.

SIM card vendors profit from high data consumption. Devices that run bloated protocols push customers onto 30MB, 50MB, or pooled data plans with significant per-unit margins. The vendor has no incentive to tell you that a better-engineered device would stay well within a 30MB plan.

The answer isn't to accept this structure. It's to procure devices where the communication protocol is treated as a product specification, not an afterthought.

WHAT PROTOCOL-LEVEL ENGINEERING ACTUALLY LOOKS LIKE

This is where device customization matters — and where the difference between off-the-shelf hardware and purpose-built solutions shows up on your monthly bill.

Protocol selection matched to the application. Different deployments have different requirements. Domestic fleet operations in markets running national transport standards use JT/T 808 as the primary protocol — a purpose-built standard for vehicle telematics data that's far more efficient than generic IoT protocols. International deployments typically run GT06, the dominant global GPS tracker protocol. Custom enterprise integrations requiring ERP connectivity, proprietary platform integration, or end-to-end data pipeline deployment use protocol stacks built to specification.

The point is that 'GPS tracker protocol' is not a single answer. It's a decision that should be made based on the operating environment, the platform being connected to, and the reporting requirements of the deployment.

HEX binary encoding at the firmware layer. The same longitude expressed in HEX binary occupies 4 bytes instead of 25. A complete position packet — timestamp, coordinates, speed, heading, satellite count, voltage, device status — compresses significantly compared to its JSON equivalent. At scale, this is the difference between a 30MB monthly plan and a 50MB one.

Intelligent reporting logic — only transmit when it matters. A fixed 10-second reporting interval is a blunt instrument. A truck cruising in a straight line for 10 kilometers generates 100 position points that all say approximately the same thing. Firmware with cornering algorithm logic transmits based on directional change rate and dynamic distance calculation: minimal points on straight segments, dense reporting through turns and complex maneuvers. The route trace is indistinguishable in quality. The data volume drops by up to 60%.

Sleep and wake behavior that doesn't waste data. While stationary, a properly configured device sends a single heartbeat packet every 5 minutes — just enough to maintain the last known position and confirm the device is online. The moment the accelerometer detects movement, the device wakes immediately and resumes active reporting. Idle vehicles consume negligible data. The monthly plan budget goes toward vehicles that are actually moving.

THE QUESTIONS TO ASK BEFORE YOU SIGN ANOTHER SIM CONTRACT

If you're evaluating GPS hardware or reviewing your current fleet configuration, these are the specifications worth pressing on:

What is the default reporting configuration, and is it adjustable? The answer should be: active reporting at a configurable interval (10 or 20 seconds while moving), heartbeat ping every 5 minutes while stationary. Parameters should be configurable both via platform and via SMS command to the device — useful for field adjustments without physical access.

What communication protocol does the device use, and does it match the application? Wireless devices should support UDP for data efficiency. Hardwired devices running TCP should have properly configured heartbeat intervals, not continuous active connection. Ask about APN configuration and whether protocol parameters are accessible.

What data format does the device use for position payloads? HEX binary encoding is the right answer for data-efficient deployments. If the answer is JSON, ask for the byte count of a standard position packet and run the math yourself.

Does the firmware include cornering algorithm or direction-change-based reporting logic? Fixed-interval reporting without this logic means paying for redundant data points on every straight segment your vehicles travel.

What monthly data plan does the manufacturer recommend, and why? A well-engineered device on default configuration should stay comfortably within a 30MB monthly plan for a standard commercial vehicle operation. If the recommendation starts at 50MB, ask what's consuming the extra data.

FIND OUT WHAT YOUR FLEET IS ACTUALLY USING

Most fleet operators don't know their per-device monthly data consumption broken down by reporting mode. They see a total bill and accept the vendor's explanation.

The right starting point is a device-level data audit — what each unit is transmitting, at what frequency, in what format. That audit usually makes the source of excess consumption obvious.

If you want to understand the configuration options for your specific deployment — vehicle type, reporting requirements, target monthly data budget — we can walk through the numbers.

→ [Talk to a Veyloc engineer about your fleet configuration] → [Download the GPS Data Consumption Reference Guide (PDF)]