For those embarking on building a DIY Isaac OBD2 CAN bus PCB board, understanding and minimizing communication latency is crucial for real-time data display. As we refine our approach to reading ECU data – particularly in light of challenges in directly querying the Check Engine Light (CEL) status – addressing gauge delay becomes paramount. This article delves into the primary sources of latency in ECU communication and display, focusing on serial communication bottlenecks and strategies to mitigate them, directly applicable to projects like building a custom OBD2 gauge using an Isaac PCB board.
Latency in displaying real-time data from the Engine Control Unit (ECU) can stem from several factors. In DIY automotive projects, especially those involving custom PCB boards for OBD2 interfaces, serial communication speeds and code efficiency are often the primary culprits. We can identify three major areas contributing to delay:
- LCD Serial Communication Speed: Communication with the Liquid Crystal Display (LCD) at a relatively slow 9600 baud rate introduces a bottleneck.
- ECU Serial Communication Speed: Similarly, communicating with the ECU at 4800 baud also contributes significantly to delays in data retrieval.
- Code Efficiency: Inefficiencies within the code itself, particularly in mathematical computations and algorithm execution, can further exacerbate latency.
Initially, the system polled the ECU for data each time an update was needed. This involved sending a request, waiting for a response, processing the data, and then updating the display. For three parameters, this polling process involved sending 28 bytes to the ECU (including headers and addresses) and receiving a 13-byte response for each parameter update cycle. Calculating the time spent on serial communication with the ECU alone reveals:
(28 bytes sent + 13 bytes received) * 8 bits/byte / 4800 bits/second = approximately 68 milliseconds per update cycle.
Updating the LCD display also adds to the latency. With the LCD set to 9600 bits per second, refreshing the display involves sending commands for cursor positioning, data display, and special characters. While the exact byte count for a full refresh wasn’t precisely calculated, estimating around 32 bytes for a full screen update is reasonable. This leads to an LCD refresh time of approximately 27 milliseconds (32 bytes * 8 bits/byte / 9600 bits/second), equating to a refresh rate of about 37.5 Hz.
Since these processes occur sequentially, the total delay is additive. The combined latency from ECU polling and LCD refresh results in approximately 95 milliseconds per update (27ms + 68ms). This translates to a refresh rate of roughly 10 frames per second, a delay readily perceptible to the human eye and far from the fluid, real-time display desired in a custom OBD2 gauge.
To effectively reduce this latency and improve the responsiveness of our DIY OBD2 gauge – a key objective when building projects like an Isaac OBD2 CAN bus PCB board – we can focus on two primary strategies:
- Reducing Polling Overhead: Minimizing the number of bytes transmitted during ECU polling.
- Increasing LCD Communication Speed: Boosting the baud rate for serial communication with the LCD.
Considering the challenges encountered in directly querying the MIL (Malfunction Indicator Lamp) status, we can streamline the polling process by omitting the MIL address from regular updates. Furthermore, parameters like intake air temperature, which change relatively slowly, don’t necessitate updates every cycle. By reducing the number of polled parameters per cycle, we can decrease the data overhead to approximately 33 bytes round trip, bringing the ECU communication time down to around 55 milliseconds.
To further optimize ECU communication, we can leverage a “fast polling mode.” By sending a specific command (e.g., “1”) before requesting data addresses, we can instruct the ECU to continuously stream responses without requiring repeated polling requests for each data point. This significantly reduces the transmitted bytes to just 11 per update, achieving an ECU update time of a mere 18 milliseconds, corresponding to a much improved refresh rate of about 54 Hz.
The second crucial enhancement involves increasing the LCD communication speed. Unlike the fixed 4800 baud rate often required for standard Serial System Monitoring (SSM) with ECUs, the LCD and Arduino microcontroller offer flexibility in serial communication speeds. By increasing the LCD baud rate to 57600 bits per second, we can drastically reduce the LCD refresh time to approximately 4.5 milliseconds (32 bytes * 8 bits/byte / 57600 bits/second). This translates to an exceptional refresh rate of approximately 225 Hz for the display.
By implementing these enhancements – optimizing ECU polling and accelerating LCD communication – we anticipate a substantial reduction in the overall cycle response time. From an initial 95 milliseconds, the combined update time is projected to decrease to approximately 22 milliseconds (18ms + 4.5ms), resulting in a refresh rate of around 43 Hz. This improved refresh rate should deliver a significantly smoother and more fluid user experience, eliminating the perceived lag and providing near real-time data visualization crucial for effective monitoring with a DIY OBD2 gauge built around a board like the Isaac PCB. Assuming efficient code execution on the Arduino and the system’s ability to handle the continuous data stream from the ECU, these optimizations promise a responsive and valuable tool for automotive diagnostics and performance monitoring within your DIY project.
