BLE and Modbus Over One Bridge: The Architecture Behind A1SI-CVWS

There is a recurring problem in industrial software: the sensor you need to read speaks an old, wired, deterministic protocol, and the device you want to read it on is a modern phone that speaks none of that. A load cell under a truck scale talks Modbus RTU over a serial bus. The operator is holding an iPhone. Something has to sit in the middle.

In the A1SI Commercial Vehicle Weighing System (CVWS), that something is a small ESP32-based bridge. This post is about how the bridge works and, more usefully, why it is built the way it is — because the obvious naive version of this bridge fails in ways that only show up in the field.

The two halves of the bridge

Conceptually the bridge has a wired half and a wireless half, and the engineering is mostly about the seam between them.

On the wired side, the bridge is a Modbus RTU master. Modbus RTU is a request/response protocol over a serial line: the master sends a frame asking to read a set of registers, the device (the load cell) replies with the values, and a CRC on each frame catches corruption. It is deterministic and unforgiving about timing — RTU framing relies on inter-character and inter-frame silence, so the bridge has to respect those gaps rather than blast the bus as fast as the UART allows.

On the wireless side, the bridge is a BLE peripheral. It exposes the weight data as a GATT characteristic that a phone subscribes to for notifications, using the Nordic UART Service pattern — a well-trodden way to tunnel a stream of bytes over BLE without inventing a bespoke profile. The phone connects, subscribes, and from then on receives readings as they arrive.

The bridge's job is to poll the Modbus side on a sane cadence, take the latest valid reading, and push it out the BLE side — while making sure a problem on one half never silently corrupts the other.

Where the naive version breaks

If you write the simplest possible bridge — read Modbus in a loop, forward whatever you get over BLE — it will demo perfectly and then misbehave in the yard. A few of the failure modes worth designing against:

• Stale data that looks live. If the Modbus side stops responding (a cable knocked loose, the load cell rebooting) but the bridge keeps notifying the last value it saw, the operator sees a confident, unchanging number that is no longer real. The fix is to treat freshness as a first-class property: a reading carries an age, and a reading that has gone stale must be presented as stale, not as the current weight.
• Partial frames forwarded as truth. Modbus CRC exists precisely because serial lines drop and mangle bytes. A bridge that forwards a frame before validating its CRC will occasionally push garbage. The CRC check is not optional; a failed frame is discarded and re-requested, never relayed.
• Backpressure on the BLE side. BLE notification throughput is bounded by the connection interval, which the central (the phone) negotiates. If the bridge produces readings faster than the link drains them, queuing unboundedly is a memory leak waiting to happen. The bridge keeps the most recent reading rather than a backlog — for a live weight, the newest value is the only one that matters, so old ones are coalesced away.
• Reconnection that loses state. Phones walk out of range and come back. The bridge has to survive a dropped central, keep polling the load cell, and let a returning phone resubscribe and immediately get a current reading — not wait for the next poll cycle to populate.

None of these are exotic. They are the ordinary realities of a half-duplex serial bus on one side and a lossy, interval-bounded radio link on the other. Designing for them is the difference between a bridge that survives a demo and one that survives a season.

Why a dedicated bridge at all

A reasonable question: why not put a full gateway computer at the scale? Because the bridge's constraints are a feature. A small, single-purpose ESP32 device is cheap, low-power, rugged, and has a tiny attack surface. It does one job — turn a wired industrial reading into a wireless one — and it does it without a general-purpose OS to patch or a wired PC to babysit on a cold morning.

This is the same engineering A1SI offers as a standalone wireless bridges product line and as wireless connectivity work: connecting modern Bluetooth and BLE to legacy RS-232 and Modbus systems. CVWS is one place that capability is pointed at a complete product, but the bridging pattern generalizes to any situation where a serial industrial device needs to reach a phone.

For the product-level view of where this fits, the CVWS overview shows the full path from scale to dashboard.