Hi all, I’m working on a DIY OBD-II scanner project using the ESP32, aimed at reading real-time vehicle data and displaying it on a mobile interface. I’ve successfully connected the ESP32 to an ELM327-compatible OBD module over Bluetooth, and I’m able to read basic parameters like RPM, speed, and coolant temperature.
Now I want to expand the setup by integrating additional external sensors (like tire pressure and vibration sensors) and a GPS module for location tagging. The goal is to create a more intelligent diagnostics/logging tool that combines standard OBD-II data with custom sensor inputs. I’m also considering logging to an SD card or sending real-time data over MQTT for remote diagnostics.
My main concerns are around managing multiple data streams efficiently and syncing them with timestamps. Has anyone tackled something similar? What’s the best approach to handle simultaneous OBD polling, GPS updates, and sensor readings without overloading the ESP32 or causing delays in data refresh?
Would love to hear how others structured such systems, especially regarding task prioritization and communication protocols.
The esp32 has 2 cores, you could use one to fill a buffer for the incoming sync data and once full you just hot-potato the feeds…you can also implement interrupts and event handling
You’ll probably want to poll the important stuff most often (RPM, etc) and less important stuff can be polled @ lower frequency…for GPS you’ll want to parse the NMEA sentences and pass them over UART, sensors will use i2c, SPI or analog…a board like this SparkFun IoT RedBoard - ESP32 Development Board - SparkFun Electronics would suit it well (has SD slot for logging too!)
The ESP32’s dual cores and FreeRTOS scheduler are perfect for juggling multiple real‑time tasks.
Core 0 can handle time‑sensitive tasks like OBD polling (every 100–500 ms) and GPS updates (1 Hz).
Core 1 can run lower-priority tasks such as SD card logging, MQTT uploads, or sensor fusion.
Set your OBD task with a higher priority than logging to keep data streaming smoothly without dropping packets.
Tag each data read with a unified timestamp using either:
millis() or micros() when calling analogRead() for sensors,
Or use GPS timestamp directly—that gives you absolute UTC tagging.
Writing batches of timestamped OBD+sensor+GPS together ensures you can sync them accurately afterward.
Use Fast polling with ELM327-style commands (via Bluetooth SPP) or direct CAN via an MCP2515 or TWAI interface.
Use a hardware serial port (UART) with interrupt-driven reads to avoid blocking.
Pull sensors via I²C/SPI/ADC in the background Core or low‑priority tasks.
Check out projects like this ESP32 CAN+GPS telematics system—it reads GPS, CAN, logs locally, then uploads via Wi‑Fi/MQTT after driving. Good reference for structuring tasks and buffering.
If you also want to explore advanced DIY OBD-II scanner features, you can see this write-up. If You Know How to DIY Obd2 Scanners, You Will Get....
1 Like
Thanks a lot for the detailed response. I appreciate the structured explanation!
Yes, I’ll go with dual-core task splitting using FreeRTOS and assign priorities as suggested. Planning to batch timestamped data from OBD, GPS, and sensors for synced logging. This setup should give me smoother data flow, reliable logging, and a clear path to scale up later. Also, thanks for sharing the article, it’s a solid reference for structuring the project!
1 Like