The inner dual is the whole argument
Any bus operator can explain why tire pressure matters: fuel, tire life, kerb damage, and the fact that a bus with a soft tire on a loaded axle handles differently with sixty passengers on board. The argument that actually gets a bus fleet TPMS approved is narrower and more practical.
A two-axle city bus typically has six wheel positions, and four of them are rear duals. The inner dual on each side is the wheel that no fitter checks, because reaching it means lying under the vehicle with a gauge and a hose, usually in a depot at night, usually in the rain. Manual check sheets across the industry tell the same story: the outer wheels get recorded, the inner wheels get estimated.
That is the real case for TPMS on a bus fleet. Not that the fleet does not check pressures — that the check cannot be trusted on the wheels that carry the most load.
What "depot-level" changes
A per-vehicle TPMS that only shows pressures on a cab display is a useful product and a hard fleet project. The data never leaves the bus, so nobody at the depot can see a trend, nobody can prove that last week's check happened, and when a bus is off the road for a tire fault there is no record to review.
Depot-level monitoring means the unit of management is the depot, not the vehicle. Three things have to be true for that to work:
- Every bus reports into one view the workshop already uses, keyed by fleet number.
- Alarms arrive before the bus leaves, or at the latest at the daily check, not when the driver notices a soft tire in service.
- Every wheel position is identifiable, so a work order can say "bus 4127, rear left inner" without ambiguity.
That last point is a maintenance system requirement, not a sensor requirement. It is also the one most often skipped.
Four ways to get data off a bus
Fleets we talk to usually land on one of four architectures.
Cab display only. Lowest cost, fastest to install, no dependency on the depot network. It solves the visibility problem for the driver and does nothing for the workshop. Reasonable as a first step on a small fleet.
Cab display plus a handheld reader. A technician walks the depot at night and reads each vehicle. This preserves the manual check workflow but removes the need to open a valve. It scales badly: the labour is the same as before.
Vehicle gateway or telematics integration. The receiver outputs on CAN 2.0B at 250 kbps by default with a 500 ms data period, both software-configurable, and the platform also covers J1939, RS485, RS232, Modbus RTU, PROFINET and UART. If the bus already has a gateway, tire data joins the same data stream. This is the architecture that turns TPMS into fleet information.
Cloud or depot server. Data uploads when the bus returns to the depot. Our receiver supports up to 256 wheel positions, which is far beyond a six-wheel bus; the capacity that matters here is the number of vehicles, not wheels, and that lives in the platform rather than in the sensor.
Most serious projects combine the last two: real-time alarm in the cab, records in the depot.
At fleet scale, the specification changes
The technical requirements for one bus are unremarkable. At a fleet scale of around 1,500 vehicles a year — which is the order of magnitude we supply to a major Chinese city bus operator — different things start to matter:
- One part number. A fleet with three sensor types accumulates three sets of spares, three mounting procedures and three training sessions.
- Sensor lifetime versus wheel service interval. The internal sensor is rated for at least five to six years, the external type uses a replaceable CR1632 rated for at least two years. Choose based on how often the fleet opens wheels, not on unit price.
- Environmental range. Depot washdown, road salt and the temperature range a bus sees across a year. Internal sensors are rated −40 to +125 °C, external ones −20 to +85 °C, and both are IP68.
- Battery and power. Receivers run on DC 10–30 V, which covers the bus electrical system without a converter.
- Pressure accuracy. ±7 kPa is fine enough to catch a slow leak that a weekly check would miss, and tire temperature to ±3 °C adds the overload signal that pressure alone can miss.
Rolling it out without stopping the depot
A 1,500-bus fleet is not installed in one project. The sequence that works is boring:
1. Start with one depot and one bus type, and fix the wheel map wording there.
2. Instrument a month's worth of deliveries rather than the whole yard, so the workshop learns the alarm workflow on a small number of vehicles.
3. Agree on the threshold that raises a work order, and who owns it.
4. Only then scale, model by model, with the same bill of materials.
The temptation is to install everything at once and design the workflow later. That produces a fleet of buses reporting alarms that nobody has agreed how to handle.
From alarm to work order
The value of fleet TPMS is realised in the workshop, so the last step of the project is administrative, not electrical. Decide in advance:
- Which pressure or temperature condition creates a work order automatically
- Which one only creates a note for the next scheduled service
- How a wheel position is written on the order, so the fitter goes to the right wheel
- How the alarm is cleared, and by whom
If those four are undefined, the fleet will have more data and the same number of tire failures. We have seen the same pattern in every vehicle class: the sensor is the easy part, the workflow is what decides whether the project pays for itself.
How we work
GZVIA designs and builds the sensor, receiver, repeater, display and cloud platform in-house in Shenzhen. We supply a major Chinese city bus operator at around 1,500 vehicles a year, and port machinery builders under their own brand at around 600 units a year.
If you are specifying TPMS for a bus fleet, send the fleet size, the bus wheel configuration and the system that has to receive the data. We will reply with a configuration and the protocol documentation.
See the applications overview, the city bus installation, or the IoT platform. To start a project, contact us.