The sensor abstraction layer: from raw volts to calibrated weight and multi-zone temperature

What actually arrives from the device?

The common mental picture is that a tracking device "measures fuel" or "reads temperature". Reality is far lower-level and rougher: a resistive fuel sender emits a voltage that changes with float height; a load cell emits millivolts proportional to compression; a temperature probe sends a digital value that needs a scale factor and an offset; a door sends a single bit; and a CAN bus carries frames holding dozens of encoded parameters that do not explain themselves. Device families then differ in how they wrap those numbers — Pixa today ingests 18 supported and tested protocol families, each with its own way of numbering and naming parameters.

The result, for anyone receiving this data without deliberate processing, is a screen full of numbers that are technically correct and operationally meaningless. A value of "2870" might be fuel millivolts, temperature multiplied by ten, or tyre pressure — and nothing in the number itself will tell you. The gap between "data arriving" and "a reading someone can act on" is precisely what the abstraction layer closes.

Add to this that every device family names the same parameter differently and numbers it differently: what "element 201" means at one factory may be fuel voltage, and at another something else entirely. The CAN bus then makes the scene both richer and messier: a single physical quantity may arrive from more than one source at once — temperature from a wired probe and from CAN, fuel from the tank float and from the vehicle's computer. Unification does not come from the devices; it comes from the layer above them — the one that lets you pick the authoritative source per vehicle while keeping the rest for comparison and diagnostics.

The abstraction layer: one contract above every protocol

The central idea is simple: separate how the number arrived from what the number means. In Pixa, any raw parameter — from any device, over any protocol — can be defined as a sensor through four elements:

• A name: "front-zone temperature", "payload weight", "rear cargo door" — language an operator understands, not an index of numbers.
• A formula: a mathematical transform of the raw value — dividing millivolts, applying scale and offset, inverting a signal.
• A calibration table: where needed, a multi-point table mapping raw values to true physical values, interpolating between measured points.
• A unit: liters, kilograms, degrees Celsius, RPM — so screens, reports, and rules agree on one language.

Because the definition sits above the protocol layer rather than inside it, the same machinery serves weight, multi-zone temperature, doors, PTO, passenger counting, RPM, and whatever parameter appears tomorrow — with no bespoke development per case. Defined readings appear on the vehicle card of the live tracking screen and immediately become material for rules and reports.

Perhaps the clearest test of this layer's worth is device-replacement day: a vehicle moves from one protocol family to another — from an economical tracker to a CAN-reading device, say — and the raw shape changes completely, while the business definitions above it stay put; the rule watching "front-zone temperature" does not care which byte the degrees came from. Without the layer, every device swap becomes a full reconfiguration project for rules and reports.

The calibration table: where the trustworthy number is born

A linear formula suffices when the relationship between raw and real is a straight line — which is rare in the field. A cylindrical or irregular fuel tank means each centimetre of float height corresponds to a different number of liters depending on where it sits; load cells drift from linearity at the edges of their range. The correct answer is a multi-point calibration table: real points measured across the operating range — an empty tank, then known-volume additions up to full; or reference loads of known weight — with the system interpolating between them.

The principle we hold to at Pixa here is strict: calibration is built from actual field measurement, not from an assumed theoretical curve. A table invented from a datasheet produces numbers that look precise and are misleading — and a misleading number is more dangerous than a missing one, because a person will act on it.

Nor is calibration a one-time event to be forgotten: replacing a tank or a sensor, or altering how load cells are mounted, demands re-measurement. A sound system makes recalibration a documented routine — a new table superseding the old — rather than surgery that halts operations for days.

Fuel is the complete example of the chain: a calibration table converts raw to liters, then smoothing absorbs slosh during movement and cornering, leaving a reading stable enough to detect fills and drains — theft — by volume, time, and place with an instant alert, and to compare actual against standard consumption. Details on the fuel management page.

From the field: weight, temperature, doors, PTO

The table below summarizes how a raw reading becomes an operational decision through the same layer:

Note the last column: every row ends in a decision or a rule, not merely a number on a screen. Multi-zone temperature, for instance, becomes independent rules in the alerts engine — the freezer zone has its threshold and the chiller zone has its own — each with escalation and acknowledgement. And actually measured PTO hours feed hour-based maintenance plans instead of calendar guesswork. The same holds down the rest of the rows: passenger counting meets operating schedules, and door events meet geofences, so a bare "door opened" becomes "door opened away from authorized delivery points" — the shift from monitoring devices to monitoring operations.

The raw-data viewer: a glass box, not a black one

The most delicate moment in this field is installation: a new device, a new sensor, and first readings you do not yet know whether to trust. That is why Pixa provides a raw-data viewer showing parameters exactly as the device sends them — before any formula or table — making the commissioning path explicit: watch the raw stream, identify the right parameter, bind it to a sensor definition, take calibration measurements in the field, then compare calibrated against reality before declaring the sensor ready.

The value of this path shows most clearly with silent failures: a sensor drifting gradually over time, or its readings suddenly flatlining at a fixed value. A quick comparison of raw against calibrated settles immediately where the fault lies — in the wiring and the sensor, or in the definition and the table — so the maintenance technician goes to the vehicle with a specific task, not an open guess.

Once ready, the calibrated reading flows into everything above it: the vehicle card, the rules, the trips, and 29 ready-made reports plus a schedulable custom report builder — see the reports page. One layer, built once, serving every screen.

Before you buy your next sensor

The question that saves you money and disappointment: "when this sensor's number reaches the platform, who turns it into a trustworthy value, and with what calibration?". If that question has no clear engineering answer, the new sensor will add a column of numbers, not an operational capability. Our rule at Pixa is plain: we do not display an unproven, uncalibrated number where a person will act on it — an operator's trust in the whole screen is built from trust in every number on it. Contact the Pixa team via the contact page to review your current and planned sensors and watch the road from raw volts to decision — on your own data.