Suggestions on how to retrieve real-time OBD-2 data??

Hi everyone. I've had a really hard time trying to find someone that is familiar with something specific I've been trying to accomplish and was hoping someone here wouldn't mind giving me some guidance. I'm currently using an STN2120 on a custom slave PCB that will be plugged into the OBD-2 port of a vehicle. The STN will be interpreting the CAN protocols, and passing engine sensor information to a master PCB via UART. The ATMEGA2560 MCU on the master board will then be monitoring OBD-2 engine sensor values it receives from the STN2120, and the master board will activate digital output circuits based on certain conditions being met based off the CAN sensor data I'm monitoring. I need the MCU on the master board to be able to read the data at the same speed that the CAN bus produces it (ie: up to 500 kbps, I believe).

The person that is designing my boards came to the realization that using the master PCB's ATMEGA MCU to request the data from the STN, and to then receive that data, will likely result in a refresh rate of over 1 second, per sensor data I'm looking to read on the master board. While I don't need absolute instantaneous data from the CAN bus, it needs to refresh at a rate of several times per second for my purposes.

Based off what I'm describing, is there a better way of collecting this data on the master board that will result in a much faster refresh rate when looking at say 15 sensors' data on the CAN BUS? Could some libraries perhaps be loaded on the ATMEGA, that allow it do exactly what the STN2120 does? Sorry for the ignorance here... I'm just a car guy with a concept, and very little microcontroller knowledge :slight_smile: Thanks a bunch to anyone who is willing to help!!

Either You listen to the conversation on the CAN bus ordered by the bus master, at the frequency caused by that master, or You introduce a second master sending out requests for certain data. Will this work? I'm not sure it will not cause trouble for the original bus devices.
Why ask for data at a higher rate? Is the device sending that data capable to gain info faster and deliver to Your new device?

Thanks a ton for the help Railroader! So a CAN BUS is apparently capable of passing the data at up to around 500 kbps. Based on what the guy helping me with 2 boards said, once the master MCU receives the request, it will be slowed to a refresh rate of over 1 second per piece of data, one at a time, based on his current understanding of what we're trying to do. So while the CAN BUS can't send any faster than 500 kbps per second, I need the master MCU to be able to read at up to 500 kbps so the refresh rate isn't too slow. Does that make sense? Sorry, I'm not very technical about the issue and the PCB side of things.... I only know I need to capture the sensor data as fast as the CAN BUS can spit it out :slight_smile:

Looks like maybe a Microchip MCP2515:

coupled with a library like this:

would probably be as good as any a place to start.

(Can't personally vouch for either but it may help inform your hardware and software design directions.)

The rate of transmission, 500 kb/s has nothing to do with the rate sensor data can be delivered. Some periferal must read the sensor and respond by sending the data as an answer to a request for data, at the rate You require.

I understand you are in the process of a project. You are going to write custom software to read the CAN-buss, correct?

Have you considered, instead of writing a ODBCII engine, using a device like Freematics or the Spark Fun ODBCII modules? I use a Freematics ODBCII module to do ODBCII thingy. My project, based on a ESP32 MCU, makes a data request and the Freematics, via serial, returns the requested data. Saves a lot of tome and effort working out the code to talk to my car's ECU.