Custom OBD II Gauge in With OEM Look

70,396

587

54

Posted

Introduction: Custom OBD II Gauge in With OEM Look

Glovebox Gadget Challenge

Second Prize in the
Glovebox Gadget Challenge

https://github.com/stirobot/arduinoModularTFTgaugesI built a custom OBD II (on board diagnostics version 2 http://en.wikipedia.org/wiki/On-board_diagnostics) gauge in the clock of my Subaru BRZ (GT86, FRS) and a lot of people wanted me to build them one. Here is how you can build one of your own. My wife is about to give birth to our second son and all the code is open source, so I have nothing to lose by posting this.

(I still may sell the installation as a service or possibly the packaging of a kit in the future, but that won't prevent others from using the open source pieces to do what they want in their own installations, other cars, other displays, etc. and frankly there is no money to be had in this. So, I'd rather share it with the DIY community at large.)

I'll try to point out where I did things that are specific to my model of car and where you might want to change things to suit your needs. Hopefully this will allow others to build on what I've done.

The all important github link:https://github.com/stirobot/arduinoModularTFTgauge...

And more generically my code is here: https://github.com/stirobot/arduinoModularTFTgauges

The car specific forum where all of this is getting discussed: http://www.ft86club.com/forums/showthread.php?p=1967204#post1967204

Step 1: What You Will Need to Do This (parts/tools/software/etc)

Parts (generic/specific):

-An Arduino or Arduino clone – I specifically use the adafruit pro-trinket for its small form factor and 5v logic.https://www.adafruit.com/products/2000

-STN1110/ELM327 board. I chose the Sparkfun one because it is stable, uses UART for communication and doesn't cost and arm and a leg. https://www.sparkfun.com/products/9555

-Assorted hookup wire

-128x32 SPI monochrome OLED display. I used the adafruit one. The ebay ones may work just as well, but I haven't tested them.

-Your OEM clock. I used the OEM clock from a Scion FRS that I got on ebay.

-Some resistors (for the button setup)

-Optional – sensors (autometer oil temp, autometer oil pressure, acceleromter, pressure, temperature). I have some arduino code that will let you plug analog sensors into a system like this. I'll make one of the “steps” pages about this.

Tools:

-Soldering Iron

-Wire stripers

-Wire crimpers

-Helping hands

-scissors

-dremel tool

Code libraries used:

-Arduino ELM327 library: https://www.clusterfsck.io/blog/2014/05/23/arduino-elm327-library/ . I thrashed around with the UART comms to the OBD II board for a long time. (you can see it in my crummy code for the 1.8” TFT version of this). This saved my project and my sanity.

-The Adafruit libraries for the OLED screen and tutorials: https://learn.adafruit.com/monochrome-oled-breakouts I love supporting this vendor as they always provide a lot of extras when you buy from them (support, working code (emphasis on working), tutorials, etc.)

Software:

Sublime Text2 Stino plugin (because real syntax highlighting is refreshing) - http://robot-will.github.io/Stino/

the dot factory – for making monochrome bitmaps into arrays so you can display them on the screen (That's how I got my icons)

windows paint – for drawing icons and splash screens

Step 2: Choosing Your Screen

I've been through several projects like this in the past and I have some advice to share on selecting a screen.

-You want the screen to fit in the OEM location with as little modification to the car as possible. I ended up measuring everything and cutting out templates on paper to see what would fit. For an old project similar to this I used a standard 16x2 character LCD. It fit perfectly in the GD Impreza's clock location (https://code.google.com/p/robotmeter/)

-You want as much support as you can get in terms of a graphics API. The adafruit stuff is awesome. Their TFT and OLED graphics API's are great.

-You want the best visibility in all lighting conditions. Cars see night, day and direct sunlight to all their displays. OLED screens are great at this. Transflective LCD's are also good at this. Reflective and Transmissive LCD's are not good at all.

-Polarized sunglasses can sometimes ruin a great design if their polarization lines up the wrong way with the screen you select. Test things out before you dive into coding.

Step 3: Reuse Code From the Community

I reused the wonderful ELM327 library from David Irvine (https://www.clusterfsck.io/blog/2014/05/23/arduino-elm327-library/) and it saved me a lot of headache. Please reuse my code as it might save you some time or at least give you some ideas.

Graphics API's are great, but what's better is looking at the code that uses them. Look at other projects that employ the API you are using and see how they deal with things like screen flicker, drawing bar charts, scatter plotting, etc.

Step 4: (if You Are Using My Code or Making Your Own) Find the Vehicle Specific CAN Codes for Your ECU

Finding the vehicle specific CAN codes for your vehicle can give you much more info than the generic OBD II PID's. In my case the BRZ/FRS/GT86 community has discovered two important codes which show data that you would otherwise not be able to get from these cars via the standard OBD II PID.

For my car these included oil temperature (very important for track/autocross driving) and fuel remaining.

I had to modify/use the David Irvine API to use the Oil Temp PID. For a lot of applications (and for mine), this was a two part process. First you have to express a CAN header and then ask for the PID like you normally would. I added this code to the ELM327 initialization code:

runCommand("AT SH 7E0",data,20); //(FRS/gt86/brz specific CAN header)

Then I queried for the oil temp:

status=getBytes("21","01",values,1);

(I added my own function to the ELM327 class for this.)

So, the hard part is finding what these are for you car. The easiest places to look are:

-The Torque android app forums

-The vehicle specific forums for your make/model of car (I found that this is especially true of a lot of the diesel truck models).

-The Scangauge X-gauge PID library (http://www.scangauge.com/support/x-gauge-commands/)

-And, finally if you can't find what you are looking for you can do some CAN sniffing of your own (which there are other instructables on: https://www.instructables.com/id/CAN-Bus-Sniffing-and-Broadcasting-with-Arduino/ )

After you find the correct PID the next part is picking out the data out of the (sometimes long) string of characters returned. Getting this position correct is sometimes a pain and requires a lot of debugging and possibly a specific arduino sketch where you guess and check positions until you get close. Another approach is to spam the responses to the serial monitor (an arduino mega is helpful here) then graphing them in a spreadsheet to figure out which hex number (converted to decimal) changes with the specific sensor reading you are interested in. You may also want to check this against the ground truth of an actual sensor or a known good OBD II program like the torque app.

Step 5: Disassemble Your Clock

-Find the car make/model specific forum of your choice and find the DIY section to find out how to get the clock out without breaking anything. Be especially careful if the clock shares a PCB with something critical (in my instance the airbag status lights and hazard button are on the same PCB). Sometimes a DIY which describes how to change the color of the clock (popular modification in a lot of cars) will come in handy.

-De-solder (https://www.instructables.com/id/How-To-Desoldering/) the clock or cut it out entirely (depends on your specific car). I have included pictures of what I did to mine for reference.

-On my car this included removing back-lighting LEDS as well.

Step 5: Reusing clock buttons

I was lucky in this regard. My OEM clock has three buttons. I was able to reuse them to control the screen. I assigned them these functions H=high, show the peak measure; M=mode, switch display pages; 00=reset the peak readings.

In order to reuse the buttons I had to remove them from their curcuit and wire them up to a circuit like this: http://tronixstuff.com/2011/01/11/tutorial-using-analog-input-for-multiple-buttons/ .

I ended up pulling them off of the circuit board with pliers and then using electrical tape as insulation. This is far from ideal. The better way to do it is to follow this instructable: https://www.instructables.com/id/Solder-on-PCB-traces/ . Use and exact knife to clear out traces around the one you are interested in.

If you aren't lucky and don't have buttons to reuse, buy some spst buttons of your liking and mount them wherever you'd like. I suggest using ones the come in a screw casing so you can drill a hole and mount them neatly.

Step 6: Test Everything Out Before Taking Everything Apart

(yes this is out of order)

This should probably go without saying, but test everything out before you wire it in permanently and before you hack up your clock.

Step 7: A Word About Power Savings

The ST chip used in the OBD II UART device has some excellent power save features. I use the one which puts the chip to sleep when it is not getting power to the UART pins. This allows me to keep everything semi-permanently installed without worrying about it draining the battery. Specifically I make use of this command in the initialization to put it in this mode:

runCommand("STSLU", data, 20); //sleep on UART inactivity and wake on activity

There a whole host of other power save options that you can read about here: http://www.scantool.net/downloads/79/stn11xx-powe... I have yet to test this with a multimeter, but will soon (and hopefully remember to update this page).

Step 8: ​Wire Up and Power Up

This is the fritzing diagram of how I have everything plugged in for reference. I did it with the more common arduino form factor instead of the Adafruit Trinket that I am actually using at the moment. Hopefully this will make things more clear for some people.

Step 9: Innovate!

The world is your oyster here. Things I suggest changing or customizing:

-What is displayed on each page. What OBD II readings you are interested in.

-Find CAN specific PID's for your car and use those.

-Change the button config to only use one button and use long holds to reset things or display highs.

-Scale to a 128x64 OLED or other larger screen.

-Reuse some of my sensor code found in this project to add off the shelf gauge senders/accelerometer/etc to your project: https://code.google.com/p/robotmeter/

-Fork my code. Publish what you've made (here on instructables and elsewhere).

Share

Recommendations

  • Epilog Challenge 9

    Epilog Challenge 9
  • Sew Warm Contest 2018

    Sew Warm Contest 2018
  • Gluten Free Challenge

    Gluten Free Challenge
user

We have a be nice policy.
Please be positive and constructive.

Tips

Questions

53 Comments

Hey JustiN1, found your instructable in a forum while looking for a way to diagnose an overheating problem I have with my 2006 Subaru Legacy. I just logged in to say thank you for the great instructable. To me, your instructable (and your courteous, informative reply to comments/questions) represents the essence of such social networks (and dare I say a diminishing great human quality): helping complete strangers and sharing knowledge without asking for anything in return. Like you used to be, I am a lurker here and your instructable inspires me to one day post my own instuctables to give back to the community.

Wow thanks for the compliment. I will let you write my next resume.

On the legacy, unfortunately the probability that you need headwork is there. There was some issue with some motors of a certain generation and they required work because of some headgasket issue (my sister had one with this problem). (http://kentbrothersautomotive.com/an-explanation-of-common-subaru-head-gasket-problems/

Hi.

I'm looking at making an Arduino OBD interface with analog gauges. I think you've already done half the job for me!!

One thing I don't quite grasp: why do you need an OBD serial cable as well as an OBD UART board? I can see that the cable provides a 9-way connection for the board, but if you have a serial connection in the cable, why bother with the board? Is it the case that the cable just provides the data stream and the board does some decoding for us?

Thanks!

So the board that sparkfun sells has a chip on it that does the OBD II standard instruction sets (there are a bunch that you will find out about as you start digging into things). The arduino (or other microcontroller) communicates with the board via a serial interface (rx/tx) and uses AT commands (if you are old enough you may remember these from early modems). The serial DB9 interface from that board to the obd port is purely the choice of the people at sparkfun who designed it. It probably has to do with it having a sufficient number of pins and being cheap and readily available.

I love this! I was just thinking how badly I'd like to display some other information in place of my broken digital clock on the dash of my Celica. This looks perfect, BUT....

Being a 1991, it doesn't have OBD II. You have code for analog inputs in addition to the OBD II stuff, could it run with just analog inputs and without the OBD II interface?

I do have some analog input stuff. In fact I'm doing some of that for my car right now...
I've got turbo pressure, oil pressure, oil temp and in some old projects I did some thermistor stuff to get air temps from the engine bay (which is pretty usesless). You can dig around in my github stuff here https://github.com/stirobot . But I'll just paste the functions that read the boost and such values here (there is test code you can comment out or use for when you just want to make sure your display is working):


void getBoost() {
float rboost = analogRead(A0);
//float ResultPSI = (rboost*(.00488)/(.022)+20)/6.89 - atmo; //leave of the /6.89 for kpa
float ResultPSI = (((rboost / 1023) + 0.04) / 0.004) * 0.145 - atmo; //by 0.145 to calc psi
return (ResultPSI);
}

void getOilPSI() {
float psival = analogRead(A1);
//Serial.print(psival);
if (psival > 722) {
return (0);
}
if (psival < 257) {
return (110); //110 swings higher than the gauge goes which will alert the user to something being wrong
}
if ((psival <= 722) && (psival > 619)) { //722 = 1.42
return 174.7 - (psival * 240) / 1000;
}
if ((psival <= 619) && (psival > 520)) {
return 180.2 - (psival * 250) / 1000;
}
if ((psival <= 520) && (psival > 411)) {
return 169.4 - (psival * 230) / 1000;
}
if ((psival <= 411) && (psival > 257)) { //257 = 100.68
return 141.8 - (psival * 160) / 1000;
}
}

Basically what you want to do is go to a sensor manufacturer (I like autometer and that is what some of my stuff is based on) and ask them for resistance curves for the sensors. A lot of sensors change the resistance based on a change in the environment. You then set these up in a voltage divider circuit (google it, it's fairly straightforward) and that gives you a voltage reading that you read off of one of the analog input pins on the arduino. Then after that it's just a scaling problem to get the right numbers to show up on whatever display you are working with.

Well, got the Trinket and display, installed the test and mocked them up in my clock assembly. I had to cut a slot in my circuit board for the wires, of course the one trace that I'm using for the 3 buttons is preventing it from going any lower. Might have to cut it and run a wire from one side to the other.

Anyway, now onto modifying the program and acquiring sensors.

37196908706_095737dc4f_z.jpg

Awesome. You are my hero!

I gutted my clock, that 128x32 display is virtually the exact same display area as the stock clock. So I ordered it and the pro trinket. I hope to start playing with it next week!

Hi JustinN1, I cannot get any of the sample codes to compile unless I pretty much remove any of the useful OBD parts and in the end, I can only switch modes and look at nice graphics. Are you able to tell me what I should do?

Sure...post what errors you are getting (aka why the OBD parts don't compile). I haven't looked at the ELM code in a while and it is possible that it isn't compatible with newer arduino stuff.