Offline-online RMA

The Reverse Matchpoints Algorithm tracks location with no network coverage of any kind — no WiFi, no cellular, no cabling to the asset — and synchronises the stored history when a connection becomes available.

Positions are recorded continuously while the device is offline. Nothing is lost between contacts, and no infrastructure has to reach the asset for tracking to work. This is the operating mode for underground mines, tunnels and remote sites where network coverage does not exist along the route.

Offline and online phases

Tracking does not depend on connectivity. The network is required only to collect the history, not to produce it.

Reverse RTLS

Conventional RTLS places fixed anchors in the infrastructure and tags on assets, and requires those anchors to be powered and networked. RMA inverts the arrangement:

Battery-powered BLE beacons are fixed along the route. They require no cabling, no PoE and no network drop.
The device rides the asset, scans the beacons and records its own position.
Reporter and subject are the same device, so its messages carry a LocatorID and no separate tag identity.

RMA is implemented on the Smart Lamp Locator, the Vehicle Anchor and Locator Lite XT.

What a matchpoint is

A matchpoint is a virtual reference point placed on the map in the web portal. Matchpoints are positioned to correspond to known fixed points in the real site — for example survey pegs in an underground mine, shaft stations, intersections, or equipment bays.

Raw RTLS observations are noisy and do not land on a meaningful coordinate. RMA approximates the raw data to the nearest matchpoints, so a position is reported as a location an operator already recognises and can act on, rather than as an approximate coordinate that has to be interpreted.

Matchpoints are configured by the operator on the portal map to match real reference marks on the site. The device reports which of them it is at or between.

The matchpoint record

On the wire, a record identifies the pair of reference points the asset is between, by beacon identifier, and when it was observed:

MatchPoint {
  beacon_a    // reference point most recently passed
  beacon_b    // reference point now approaching
  timestamp_s // when the observation was made
}

The portal resolves those identifiers to the matchpoints configured on its map, so an operator sees named site locations — survey peg numbers, stations, bays — rather than raw beacon identifiers.

The record carries no coordinate. Position is expressed against the site's own reference points, so no distance is interpolated from signal strength and no accuracy is implied that the measurement does not support.

Storage and synchronisation

Matchpoints accumulate on the device and are transferred through the GATT Data Sync drain when a reader appears:

{"cmd":"count","type":"match_points"}       -> {"count":N}
{"cmd":"records","type":"match_points"}     -> protobuf chunk

On reverse-RTLS devices match_points is the store selected when a command omits type; sensor and gnss are recognised and refused rather than answered from the wrong store. Chunks use the mach_point.proto schema (MatchPoint, MatchPointChunk).

Records are erased only after the response has been read to its end, so a handover interrupted by an asset moving out of range leaves the history intact for the next contact.

Operating characteristics

No network at the asset. Tracking continues indefinitely without WiFi, cellular or cabling along the route.
Infrastructure. Battery-powered beacons only; no powered or networked anchors are installed.
Power. The device scans and records segment changes rather than participating in a ranging schedule.
Missed beacons. A beacon that is not observed widens the reported segment; no coordinate is interpolated.

Reaching the backend

Once synchronised, matchpoints reach the backend over MQTT in the {prefix}/Locators/{LocatorID}/ tree, under the device's own ID. Live positions go to RTLS and buffered ones to BufferedData:

{"MessageID":42,"LocatorID":"LXT0042","DeviceType":"bler",
 "ArrSize":12,"CurrIndex":3,
 "WB0":1041,"WB1":1042,"vBat0":3910,"vBat1":3905,
 "TimePos":1755262798,"Mode":"Eco","Lamp_Status":"ONLINE",
 "Timestamp":1755262800123}

WB0 and WB1 are the observed beacon pair. TimePos dates the observation — which for buffered records may be long before delivery — while Timestamp is publication time. A consumer ordering an offline device's history uses TimePos.

DeviceType is bler for positions produced this way, distinguishing them from the uwb and uwb2 sources described in MQTT.

Wiki