Fleet visibility, one LoRaWAN packet at a time.

Helium GPS tracking and fleet device-management systems, built from the tracker firmware up through the backend that turns raw packets into live location.

GPS trackerend deviceLoRaWAN gatewayHelium hotspotHelium networkpacket routingApplicationfleet backend

Live telemetry

What the fleet backend actually shows

0

Devices tracked

0%

Battery health above threshold

0.0s

Median last-seen latency

0.0%

Coverage across the tracked region

Illustrative figures from a representative deployment, shown to demonstrate the dashboard shape rather than live production data.

The network topology

Every design decision traces back to two constraints: LoRaWAN's tiny payload size and its duty-cycle limits. The tracker only sends what it must, and the backend is built to make that scarcity useful.

End device~11-byte payloadPayload size is the hard constraintLoRaWAN gatewayduty-cycle limited1% duty cycle in EU868Helium Network Serverdedup + routingDedupes multi-gateway receiptsApplication backendingestion + storageTurns packets into fleet state

Hardware, grouped

Power

Battery
1200mAh Li-Po
Sleep draw
18µA
Est. life
~14mo

Positioning

GNSS
u-blox M10
Cold fix
~26s
Accuracy
±2.5m

Connectivity

Radio
LoRaWAN EU868
Network
Helium
Payload
11 bytes

A representative deployment

A small delivery fleet needed location visibility without a cellular contract per vehicle. Helium's existing hotspot coverage made LoRaWAN viable; the backend was built to tolerate gaps in coverage gracefully rather than assume constant connectivity, which is the real engineering problem in fleet tracking.

Building a fleet-tracking system?

Let's talk network choice, payload design, and backend architecture.