Wiki

Technical reference for system integrators and engineers.

Equipment Tracking Application

Offline-online equipment tracking Android application for in-cabin installations or manual inspections by workers.

It can work directly with the tracking devices, such as Locator Lite XT, or can proxy and synchronize the collected data points via Vehicle Anchor devices using GATT Data Sync.

The Equipment Tracking Application running on a rugged Android tablet, showing the Connected devices sync list

Why a tablet is the transport

equipment records its own position no network where it works BLE tablet in a vehicle drains the buffer in passing carries coverage to the equipment MQTT server history, zones, timeline when the vehicle reaches coverage
Nothing needs infrastructure at the equipment. The vehicle that was going there anyway is the network.

This suits equipment that sits for weeks in places with no power and no coverage — pumps, skids, plant left at a face or down a drift. Fitting each one with a networked anchor would cost more than the tracking is worth; a tablet already in a vehicle costs nothing extra.

Finding devices

The tablet scans continuously while the screen is open and shows what it can hear on a radar view, closest first. Discovery is filtered so it does not attempt every BLE device in a busy yard:

  • Manufacturer-specific advertising data must be present and long enough to parse.
  • The company identifier and device identifier must match the expected values.
  • Signal strength must clear a configurable floor, so a device three sheds away is not queued for a connection that will fail.

Scanning is restarted automatically if the operating system stops it — Bluetooth toggled, or the OS throttling a long-running scan — because an interrupted scan on a moving vehicle means a missed device.

What a sync does

Two procedures run against a device, both over the GATT Data Sync channel:

ProcedureSteps
Matchpoint syncconnect → synchronise time → drain the stored matchpoints → record success
Status syncconnect → read and store configuration → synchronise time → record success
Records are persisted chunk by chunk, not at the end of the drain. The device releases its buffer as it delivers, so a transfer that is interrupted three-quarters of the way through must not lose the three-quarters already received. Writing each chunk on arrival is what makes an interrupted pass harmless.

Several devices can be synced at once, up to a configurable cap, and a device that has synced recently is skipped for a cooldown period so a vehicle parked beside equipment does not re-drain it continuously.

Retries

A failed attempt is retried immediately a few times, then after a longer delay. On the delayed retry the tablet checks that it has heard the device recently before trying again — on a moving vehicle, a device that was in range twenty seconds ago may be several hundred metres behind.

Time synchronisation

Equipment that has been offline for weeks has a drifting clock, and its stored history is only useful if the timestamps are right. The tablet corrects the device clock as part of every sync, but only when the drift is large enough to matter — a write on every pass would be pointless traffic.

The tablet's own clock is sanity-checked before it is used as a reference. A tablet that has just booted without network time would otherwise push a meaningless clock into equipment that has no way to know better.

Reviewing what was collected

Collected history is browsable on the tablet without a server, in three views:

ViewAnswers
By equipmentwhere has this particular asset been
By zonewhat has been through this area
By timelinewhat happened, in order

Each device's last known configuration and its last successful sync time are held alongside, so an operator can see which assets are current and which have not been visited.

Forwarding to the server

Collected matchpoints are published over MQTT when the vehicle reaches coverage, in the same payload shape a device would use if it had a network of its own. The backend does not need to distinguish a record that arrived directly from one relayed by a tablet.

Publishing is resilient about reconnection: a failed publish tears the connection down and rebuilds it rather than continuing on a socket that may be mid-message, because a partially written message corrupts the stream that follows it.

Configuration

Settings screens cover the signal-strength floor, the concurrent-sync cap, WiFi credentials, and the RTLS and time server addresses used when provisioning devices.

Related