Looking to create a simple OBD display and oil pressure monitor

The Veepeak OBD reader and OBD Fusion which I have work pretty well, but there is no way to integrate engine oil pressure into it. I am toying with the idea of using a microcontroller and a TFT touchscreen to interface with the OBD reader as well as oil pressure sender, and putting all the info on a compact TFT or OLED screen, and 3D printing a holder to mount everything maybe under the center of the dash. I'll have to experiment to see what looks best. I don't want to be cutting anything on my dash. The screen would show whatever was selected from the PIDs and the pressure sensor output. There wouldn't be the amount of gauge customization there is with OBD Fusion, but it would probably show a concise display similar to below. I'd love to hear any thoughts/suggestions on this. I'd like to end up with something that is tidy, looks nice, is semi-permanently mounted, and just works without futzing around connecting, messing with the phone, etc.

 

Would be great to add actual oil pressure to my OBD Fusion dashboard, all I have now is a green/red icon that changes to red if it gets the low pressure signal. Unfortunately, I don't think our trucks have a scaled pressure sensor signal (i.e., to give actual pressure reading), only a low pressure trigger. Probably need to add additional sensor. Would love to be wrong though.

- Sorry, just realized you are talking about integrating an additional pressure sensor.

 

I know you can sniff the CAN bus with wireshark and get a shield for arduino to talk CAN, but I have never actually tried it. What is the chance you can create a new PID for your oil sensor on the bus with an arduino shield and query it from OBD fusion?

 

Interesting idea, but the coding interface will be a giant pain in the ass.
There appears to be various open source projects that can interface with the Veepeak type controllers.
I have a passing interest in writing one, but the amount of time involved and my number of other projects precludes doing so.

I look forward to seeing what you discover.

 

Probably slim to none, hence the microcontroller. I will stick with what I'm experienced with; use a voltage divider to pipe the sensor output to an analog input on the controller, and convert the voltage to a pressure. As for the existing PIDs, I have a library that translates CAN protocols to C, and compile for the microcontroller. TBH, the graphics will take longer to do than the CAN implementations, LOL.

 

I agree that writing a library would be a huge time-sink, but there are several out there that have done most of the heavy lifting already. It may take me awhile, as I have many other obligations (as do we all). Fortunately, I should have this truck for a good long while (I hope!). My 2008 lasted 16 years, and is still going strong. The only reason I got this new one now is because of the 2024 switching to the tiny turbo, and an 8 speed transmission, if I recall. Neither of which I have any interest in owning, TBH.

 

It seems I was mistaken. There may be a way to add custom PIDs to OBD Fusion. I'll have to research it some more.....

 

I read some howtos on adding a node to the CAN-BUS via arduino. Libraries exist and it seems turn-key to implement. I think it is definitely possible, but I don't know enough about the protocol to have an opinion whether the rest of the truck would tolerate it well. I am hoping to try it this summer sometime, unlesss I run across indications otherwise in the meantime.

 

I am also unsure if that will mess with the truck's ECU...on second thought, I'll just go with my original idea.

 

Well, here's where I'm at: I have the arduino display written, and it can communicate with the trucks canbus. Now, I am in the process of identifying the specific process IDs and formulas. Apparently, the Toyota extended PIDS are the biggest secrety-secrets in all of secretdom. Why? Don't know. It's not like one can reverse-engineer them and make one's own power-train. Anyway, it is what it is. I have the scangauge xgauge values here, and am in the process of translating them to normal PIDS and the requisite formulas to translate the canbus gibberish to meaningful data. I have this , written awhile ago. I am inputting the values obtained in the form of user-defined PIDs in the OBD Fusion app, but no matter what I enter, I am just getting the "no data returned" message. Obviously the PId code I'm inputting is not correct, since even if the formula were wrong, I'd be getting gibberish, not a null return. I have a pretty solid background in micro-controller programming, but this canbus stuff takes the cake for deliberate obfuscation and needless complexity. Where else do you need a formula like (((((A*256)+B)*(7/100)-400)/10) to return a goddam thermistor reading in degrees F?

Is there a newer conversion guide for the scangauge data? I know there are a lot of folks here that know a lot more about this stuff than I ever will, so any input is helpful.

On a more positive note, I will soon be adding an engine oil pressure function, and it will automatically start and stop the transmission oil cooler fan at programmable setpoints (If I can figure out how to get the tranny temp into the app, LOL)

 

Update 6/26/24:
I have working PIDs and formulas for both transmission thermistors, the transmission gear indicator, the engine coolant temperature, and the system voltage. I cannot get the engine oil temperature PID to return a meaningful value; it seems the formula is wrong. The fuel consumption calculation is also returning absurd values. After fixing those, the next challenge it to get the arduino to retrieve these values instead of the Torque Pro app.

If I understand the process, the monitor (whatever it may be, OBD Fusion, Torque Pro, etc,) sends a request to the canbus system, and then parses and converts the returned data string into human-readable values. Toyota apparently complicated things a few years back by routing everything through a central hub, hence the need for the OBD header value of 701 to be transmitted. For instance, the values for the transmission pan temperature is:
701221627, where 701 is the header, 22 is the retrieval code, and 1627 is the PID. It returns a single hex byte, which is then converted to a decimal and then 40 is subtracted from it: A-40 is the formula, returned in degrees Celsius.

 

Kudos for your work.
Following with great interest, as I have the Veepeak BLE+ and OBD Fusion on my iPhone.

I'm in the computer business, and you are on the right track.
No different than cracking the Blu-Ray copy protection schemes... just need to find the key.
The BD player has the code in its firmware, so it is possible to do the same in software.

If you are inclined to share, post your OBD Fusion specific PID info for those you have identified.

 

Thanks for posting about this. I have wanted to do the same, so just ordered up the parts. Will definitely try plugging into my '04 for a while before trying to interface my '23.

 

The attached spreadsheet is what I have so far. I do not have a working engine oil temperature PID. I tried using the one on the scangauge page, with the same formula as the transmission temp PIDs; A-40, and while I get a return, it stays at -41, so apparently it is the wrong PID.

None of the scanguage Xgauges seem to work, as I believe Toyota changed the system sometime after 2016.

 

What is the "B" component, and how is it derived?

Battery voltage (256*A+B)/1000

 

I just happened across this, looks like a fun project.
I just wanted to clarify that while the Engine Oil Temperature is a valid PID and shows up in data it is actually a calculated value, there is no Engine Oil temperature Sensor.
Also the file below shows all possible data PIDs, normal ranges, and bi-directional controls for the 3.5L

 

I really miss not having an oil pressure guage on my dash. I am thinking of maybe going mechanical. I really wish the manufacturers would let you display everything on the screen and check/clear codes.

 

As I understand it, sending a valid command to the canbus system causes it to respond with a datastream containing the ID, the number of bytes sent, and the data bytes themselves, which may be from 1 byte (A) to 8 bytes (A,B.C,D,E,F,G,H,I) many of the commands I am using only send one byte, and the final value is derived from that. The battery voltage apparently sends 2 bytes. There is a lot of bit-shifting going on in the multi-byte returns, hence the A*256 and such. I don't understand every detail of it, so take anything I say with a grain of salt, LOL

 

I do too. Getting an oil pressure display was the main reason I started this project.

 

Thank you. I had figured there was no actual oil temp sensor, since I could not find such a replacement part. I assume the temp is calculated from the coolant temp, ambient air temp....and maybe vehicle speed (airflow) as well?
I don't suppose you have a PID and formula for the engine oil temp? Nothing I have found seems to work.