Collision avoidance and proximity detection: the anchor rides the vehicle and reports distance to nearby tags over GATT to the Android tablet application in the cab, or to a third-party application.
This is the operating mode of the Vehicle Anchor. It shares hardware and a firmware image with the Fieldbus Anchor — one parameter decides which of the two a unit behaves as.
Infrastructure RTLS fixes anchors to the building and tracks tags on a server. CAS-PDS inverts both halves: the anchor moves with the vehicle, and the measurement is consumed on the vehicle rather than uploaded for tracking.
Operating mode and role are set together with node mode — 0x512D over GATT, parameter 0x7D over CAN:
| Value | Node mode |
|---|---|
0 | RTLS anchor — Fieldbus Anchor |
1 | RTLS tag |
2 | CAS-PDS anchor — Vehicle Anchor |
3 | CAS-PDS tag |
Bit 0 is the role (0 anchor, 1 tag) and bit 1 is the operating mode. The setting takes effect after restart.
Node-mode bit 1 and the raw operating-mode value have opposite polarity. In node mode, bit 1 set means CAS-PDS. In the underlying operating-mode parameter, CAS-PDS is0and UWB RTLS is1. Read whichever one you intend to act on — do not infer either from the other.
Node mode is a combined view over two separately stored fields rather than a field of its own, so older tooling that writes the operating-mode and role parameters individually keeps working.
In CAS-PDS the anchor responds to Blink + Poll from tags, rather than running the full Poll/Final two-way exchange used in UWB TWR. The shorter exchange is what keeps latency low enough for a proximity warning when several tags are in range at once.
The same distance means different things depending on what the machine is doing. A person standing beside a parked loader is normal; the same person at the same distance from a moving one is a hazard; and during boarding they are expected to be at arm's length. The anchor therefore carries a vehicle state that tags use to decide how to react.
| Value | State | Situation |
|---|---|---|
0 | Parked | machine stationary and not in use — the default at power-on |
1 | Driving | machine in motion; proximity is a hazard |
2 | Boarding | operator mounting or dismounting; close range is expected |
The state is set over GATT at characteristic 0x5116 — one byte, readable and writable. A write takes effect immediately, with no restart.
It is not a local setting. The anchor transmits the state to every tag it ranges, carried in the poll response of each exchange, so the decision about how to react is made on the tag while the anchor stays the single point of control:
Characteristic 0x511A assigns a command to one specific tag — 7 bytes: a 6-byte MAC followed by a 1-byte command. Up to 32 entries are held, and each ranging exchange checks the table before falling back to the vehicle state.
DE AD BE EF 00 17 02 this tag gets 2, whatever the vehicle state is
DE AD BE EF 00 17 00 remove the entry — the tag follows the vehicle state againA command of 0x00 is the removal instruction rather than a state value, which is why the override table cannot be used to force a single tag into parked. Writing beyond 32 entries is rejected and leaves the table unchanged.
This is what lets a banksman working alongside a moving machine keep a different alerting profile from everyone else on site, set once and cleared when the shift ends.
The state is not restored after a restart. The anchor powers on in parked (0) every time, regardless of what was set before. A vehicle that reboots mid-shift stops telling tags it is moving until something writes the state again — so a controller should re-assert it on connect rather than assume it survived.
The value transmitted to tags is the one written over GATT. The CAN parameter at 0x16 reads and writes a stored copy of the setting, but the ranging engine sends what arrived over GATT. Use GATT to change the state a vehicle broadcasts.
Each measured range is routed by the anchor's chain role (0x5119):
| Chain role | Own ranges | Ranges from other anchors |
|---|---|---|
0x00 — RX / master | GATT notification on 0x5111 | GATT notification on 0x5112 |
0x01 — TX / slave | RS-485 or CAN, per connectivity mode | — |
The GATT notifications are consumed by the Android tablet application in the cab, or by a third-party application written against the same characteristics. The anchor is a BLE peripheral and does not care which — anything that connects and subscribes receives the ranges, so an integrator can replace the supplied app with their own without changing the anchor.
A vehicle with one anchor uses the master role alone. Larger machines carry several — one per blind spot — with the master aggregating the others over the wired chain and presenting everything on one BLE connection. The application pairs with the master and sees the whole machine, rather than holding a connection per anchor.
The two characteristics carry the same payload and differ only in provenance: 0x5111 is what this anchor measured, 0x5112 is what another anchor on the chain measured. An application that shows direction needs that distinction — the same distance means a different thing depending on which corner of the machine saw it.
Use RS-485 for a CAS-PDS chain. A slave will transmit ranges on CAN if connectivity mode says so, but the master's CAN aggregation loop runs only in UWB RTLS mode. In CAS-PDS the master reads the RS-485 chain, so a CAN-wired CAS-PDS chain transmits into nothing.
Both characteristics carry the same packed 11-byte structure. Every field is big-endian:
| Offset | Field | Type | Notes |
|---|---|---|---|
0..1 | range | uint16 | centimetres |
2..7 | tag MAC | 48-bit | reads in printed MAC order |
8..10 | timestamp | 24-bit | local counter, wraps |
The timestamp is 24 bits and wraps. It orders measurements within a short window, which is all a proximity warning needs; it is not a wall-clock time and must not be treated as one. For absolute time use MQTT in RTLS mode.
Notifications are sent only while an application is connected and has subscribed. Ranges measured with no subscriber are not queued — the current distance matters, a stale one does not.
The BLE beacon scanner runs only in CAS-PDS mode; a unit in UWB RTLS mode never scans for beacons. This gives a Vehicle Anchor a coarse position of its own, from fixed beacons along the route, alongside the UWB ranging it performs to nearby tags.
Scanned beacon data is uploaded only when all three conditions hold: the unit is in CAS-PDS mode, connectivity mode is WiFi, and the device is online. Records collected while offline are buffered and flushed when the link returns — see Offline-online RMA.
| Not used | Why |
|---|---|
| MQTT for range data | ranges go to the app on the vehicle, not a server |
| The CAN aggregation path | master aggregation is over RS-485 in this mode |
| UWB TDoA | proximity needs a distance, not a server-side multilateration |
A unit switched from CAS-PDS to RTLS mode stops scanning BLE beacons and starts publishing ranges over the chain to MQTT instead — the same hardware, a different data path end to end.