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.
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.
| Characteristic | Carries |
|---|---|
0x5111 | ranges measured by the connected anchor |
0x5112 | ranges measured by other anchors on the chain |
0x5116 | vehicle 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.
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 vehicle | up to four — front, back, left and right |
| Anchor interconnect | wired over RS-485 in a master-slave arrangement |
| Vehicle profile | length, width, gaps and related parameters |
| Server synchronisation | employee 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.
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:
| Value | State |
|---|---|
0 | Parked |
1 | Driving |
2 | Boarding |
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.
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 obstacle | up to 100 m range, 50 cm accuracy |
| Quantity of obstacles | a count per zone |
| Type of obstacle | people 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.
Two filters keep the display trustworthy:
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.