Wiki

Technical reference for system integrators and engineers.

CAS-PDS Tablet Application

Android tablet application for collision avoidance and proximity detection scenarios in underground mines and factories.

One of two Android tablet applications for in-cabin installation, both implemented in React Native and JavaScript. This one is the consumer of the CAS-PDS Protocol — everything it shows comes from GATT notifications, with no server in the loop.

CAS-PDS Tablet Application — proximity display CAS-PDS Tablet Application — vehicle state CAS-PDS Tablet Application — anchor assignment CAS-PDS Tablet Application — vehicle configuration

How it connects

The tablet is a BLE central; the anchor is the peripheral. It discovers anchors by scanning, applies a signal-strength gate so it pairs with the anchor on this vehicle rather than one passing nearby, and then holds a single connection to the master anchor.

CharacteristicCarries
0x5111ranges measured by the connected anchor
0x5112ranges measured by other anchors on the chain
0x5116vehicle state — written by the tablet

Because a chain master aggregates its slaves, one connection gives the tablet every anchor on the machine. The two range characteristics are what let it tell which end saw something — see CAS-PDS Protocol for the 11-byte notification format.

Vehicle setup

Anchors are scanned and assigned over BLE from the tablet, so a machine is commissioned in the cab rather than from a laptop.

Setting
Anchors per vehicleup to four — front, back, left and right
Anchor interconnectwired over RS-485 in a master-slave arrangement
Vehicle profilelength, width, gaps and related parameters
Server synchronisationemployee and vehicle records sync when Wi-Fi is available
The wired interconnect is what lets one BLE connection serve the whole machine: the master aggregates its slaves, so the tablet holds a single link rather than four. Synchronisation is for identity data only — proximity warning never waits on it.

Vehicle state

The tablet is the source of the vehicle state that the anchor broadcasts to every tag around it. It writes 0x5116 with one of three values:

ValueState
0Parked
1Driving
2Boarding

State can be selected by the operator or switched automatically from observed movement, with a short settling period so a vehicle pausing at a junction does not flip repeatedly between parked and driving. Boarding is time-bounded rather than indefinite.

The anchor does not restore its state after a restart — it powers on parked. The tablet therefore re-asserts the current state when it connects, rather than assuming the anchor still holds what was last written. See CAS-PDS Protocol.

What the operator sees

Detections are grouped by where they are relative to the machine — front, back and sides — with a count per zone rather than a list of identifiers, because a driver needs to know where and how many, not which tag serial is nearest.

Shown per side
Distance to the nearest obstacleup to 100 m range, 50 cm accuracy
Quantity of obstaclesa count per zone
Type of obstaclepeople or vehicles

Warning distances are configurable and depend on the vehicle profile: a car-sized machine and a large hauler do not have the same side clearance. Thresholds carry a margin derived from UWB ranging accuracy, so a measurement sitting on the boundary does not toggle the alarm on and off.

Proximity warnings are audible as well as visual. In a cab with engine noise and a driver looking out of the window, a screen-only warning is not a warning.

Rejecting implausible ranges

Two filters keep the display trustworthy:

  • A distance window, beyond which a detection is not shown at all — a tag several tens of metres away is not a collision risk and would only add noise.
  • A phantom-range guard that discards readings consistent with a reflection rather than a direct path. UWB is resistant to multipath but not immune, and a reflected range reads as an object that is not there.

Recording

The application can log sessions to file and publish state changes to an MQTT topic, so a deployment can review what the system showed the operator and when. This is a review path, not the positioning path — proximity warning itself never depends on connectivity.

Related