Why Bluetooth live data feels slow

You plug in a Bluetooth adapter, open six gauges, and the tachometer lags behind the engine like it is reading the car by post. Nothing is broken. A cheap ELM327-style adapter talks to the car one question at a time, and on an Analogue-era car the wire it talks over was designed in the early 1990s for reading emissions data, not for drawing a smooth needle. This page explains where the time goes, why a CAN car feels so much quicker than a K-line car, and what refresh rates are honest to expect.

One question, one answer, one gauge at a time

An OBD-II live value is a PID: you send a request such as 01 0C (engine speed), and the engine computer sends back a reply carrying the number. The ELM327 handles the protocol for you, but it cannot ask two things at once on most cars. It sends the request, waits for the reply, and only then takes the next one.

The wait has a tail. The ELM327 datasheet explains that because several computers may answer the same request, the adapter normally keeps listening after a reply to see if more are coming, and stops only when a timer runs out. That timer, set with AT ST, defaults to about 200 milliseconds. Elm's Adaptive Timing, on by default, learns a shorter wait from how fast your car actually answers, and an app can skip the wait completely by adding a digit to the request that says how many replies to expect. Done well, that removes most of the dead time. Done badly, every gauge pays a fifth of a second just for the adapter to be sure the car has finished talking.

Then there is the Bluetooth hop. Every request goes phone to adapter, adapter to car, car to adapter, adapter to phone. I am not going to put a number on that hop because it depends on the phone and the adapter, but it is paid on every single round trip.

So the arithmetic of a dashboard is simple: the adapter can collect a certain number of answers per second, and every gauge you add takes a share. Six gauges get a sixth each. That is the whole reason one gauge feels lively and a full screen feels sluggish.

The K-line: 10.4 kbit/s and enforced pauses

Analogue-era cars that speak OBD-II on pin 7 use one of two K-line protocols: ISO 9141-2, or ISO 14230-4, which is KWP2000 for emissions data. ISO 14230-4 says its physical layer is fully compatible with ISO 9141-2, fixes the speed at 10,400 baud, and allows only the normal default timing set. Both are slow by design, and the timing table in ISO 9141-2 shows exactly how slow.

Each byte is a start bit, eight data bits and a stop bit, so at 10.4 kbit/s one byte takes just under a millisecond on the wire. A request for one PID is six bytes: three header bytes, the mode, the PID and a checksum. A reply for a two-byte value such as engine speed is eight. Then the standard adds gaps:

• P4, 5 to 20 ms: the gap the scan tool must leave between each byte it sends.
• P2, 25 to 50 ms: the gap before the car starts its reply (for cars that use key word 08H; 0 to 50 ms for 94H).
• P1, 0 to 20 ms: the gap the car may leave between the bytes it sends.
• P3, 55 ms to 5 s: the gap after the car's last reply before the scan tool may send its next request.

Add the minimums for one engine-speed request: about 6 ms of request bytes plus 25 ms of P4 gaps, 25 ms of P2, about 8 ms of reply, and 55 ms of P3. That is roughly 120 ms per answer at the very best, which is a ceiling of a little over eight answers a second. With P2 at its 50 ms maximum it is closer to 145 ms, or about seven. That is before the adapter, Bluetooth or the app add a single millisecond.

Those figures are the ceiling the standard allows, worked from its minimum timings, not something I have measured. Real cars and real adapters come in under them.

Two more K-line facts shape the experience. The session has to be opened with an initiation sequence: the ELM327 datasheet says ISO 9141 allows only a slow initiation of 2 to 3 seconds, and the ISO 9141-2 timing table puts the worst case at 2.44 s. And once open, the bus has to hear from the scan tool regularly or it goes back to sleep: P3 tops out at 5 seconds, and the ELM327 sends its own keep-alive message after 3 seconds of quiet. Lose the session and you pay the 2 to 3 seconds again before the first gauge moves.

CAN: faster wire, and six PIDs per question

ISO 15765-4 CAN runs at 250 or 500 kbit/s, against 10.4 kbit/s on the K-line. At 500 kbit/s the wire is about 48 times faster, so the bytes themselves stop being the bottleneck.

The bigger win is in the request. The ELM327 datasheet notes that SAE J1979 allows several PIDs in one message only when the car is on CAN. Up to six can be asked at once, and the car sends back one reply containing all of them. Six gauges can be one round trip instead of six. That is why the same adapter on a later CAN car feels like a different tool from the one on a K-line car.

What The Analogue does with a Bluetooth adapter

Here is what the app's poller does today, straight from the code:

• It ranks the gauges. Engine speed and air flow are asked every round. Coolant, intake temperature, throttle, timing, manifold pressure and battery voltage are asked every second round. Fuel trims, oxygen sensors and the rest of the standard set rotate through, one at a time.
• On a K-line car it updates the tach early. It pushes engine speed and air flow to the screen as soon as they arrive, before the slower values in the same round, and it waits 1.5 seconds after each round before starting the next so a slow engine computer is never flooded.
• On a CAN car it batches. The high and medium values go out in one combined request, and the low-priority values go six to a request, with a 0.6 second pause between rounds.
• It does not ask for what the car does not have. It reads the car's list of supported PIDs once at connect, so a K-line car never spends a round trip on a value it does not carry, and a PID that stops answering drops out after ten misses in a row.

The guided driving legs of the Vitality Test record the tracked values once a second, which is a comfortable rate for averages and trends on any of these buses.

What logging rates are realistic

• K-line cars on OBD-II: the standard caps you at roughly seven or eight answers a second in total. Log a handful of channels and each gets about one or two samples a second. Logging twenty channels at once means each one is sampled every few seconds. That is fine for warm-up, trims and coolant trends. It is not fine for catching a single misfire or a fast boost spike.
• CAN cars: much better, because the wire is quicker and six PIDs share a request. The limit moves to how fast the engine computer answers, the adapter's own processing and the Bluetooth link, which vary too much for me to quote one number.
• Fewer gauges is faster. Whatever the car, if you need a smooth needle, watch one or two values, not twelve.

The MasterLink is wired to the K-line in the car, and its poller spaces requests 60 ms apart, just over the 55 ms minimum. It obeys the same standard, so it does not make the K-line itself faster. What it changes is what you can ask: on K-line BMWs it reaches the body modules that OBD-II never sees, and it is built to ask the engine computer for its own data, which I am still proving on cars.