[wolrah]

> I think the first part of this blog series had the gear selector sending it's state every 30ms - so you are looking at some averaged ~15ms of latency just from this thing.

For reference purposes at the standard gaming benchmark of 60 FPS a single frame is 16.666_ ms, so you're looking at the equivalent of a frame or two of delay.

That could be critical for a CRT-era fighting game that requires frame-perfect inputs, but as a controller for a traditional automatic transmission it doesn't matter in the slightest.

[stefan_]

Yes, exactly, that is terrible latency if you want to use it as an input device.

[wolrah]

> Yes, exactly, that is terrible latency if you want to use it as an input device.

Eh, yes and no. It's a lot worse than it could be, that's for sure, but there are a lot of major name game controllers that were sold for years and perform worse, yet a lot of players would never notice unless they did a side-by-side comparison against a good one.

For the use case, where the hardware it's controlling has an inherent latency measured in the many dozens to hundreds of milliseconds depending on which model and mode, it doesn't really matter. Likewise for the author's intended use case as a mode selector for an EV. A faster update rate is in all likelihood possible in the hardware, but when you're sharing a bus measured in kilobits per second with other potentially critical messages it seems reasonable to rate limit.