Can it be done... Arduino-based full Digital Auto Instrument Cluster

Hi. I'm new to this microcontroller stuff, and haven't done much in the way of programming other than a couple of simple programs for a graphing calculator years ago. However, when it comes to automotive, there isn't much I can't do...

Which is why I want to replace my 25-year old analog instrument cluster with a nice new set of LED gauges. First off, I KNOW someone is going to suggest an LCD display. My dash has 4 gauge holes with six gauges in it (2 large for tach and speedometer and 2 small in each of the other holes) that are approximately 4" in diameter (US English here, don't need or want metric), and I don't have room for a reasonably sized LCD display, plus I would need something to fill the other 3 holes. Yes, I know there are prefab gauges out there, but none for my application. I'm looking for a combination of 7-segment displays and single LEDs that act as a bar graph, similar to the analog gauges. I have been researching this for a couple of years now, and purchased a couple "books" with schematics for a decent set of gauges. The only problem, however, is that there are what seems to be WAY too many chips involved. I'm trying to keep my costs as small as possible, because anything over about $4-500, and I might as well get the pre-fab universal gauge set and trim it to fit in my stock cluster housing. Not to mention I would like to run an LED odometer, 7 digits, and the schematics in the books provide for a power loss of 10 days. Which doesn't help if I want to take the car off the road and disconnect the battery for 6 months. I have done a couple of searches, and found something called the "Multidisplay", built by a member here. Problem with that is that it's run using an LCD, for one, and doesn't include all of the gauges I'd like to see, for 2. My current gauges are as follows: 8-18 VDC voltmeter, would like to have a 10-LED bar graph and a 3-digit (volts, tenths, and decimal) LED Coolant temp, running off a 0-5 VDC sender, maximum of 260*F (something like 130*C), would like to see same as above and also for 0-120*F intake/inlet air temperature, no decimal needed 10 LED Fuel gauge and also a 10 LED Intake Vacuum gauge running off of a Motorola MPX4250APX pressure sensor (no boost), which, I believe, has a 0-5 VDC output, or a stock sensor that DOES have a 0-5 VDC output 0-70 PSI engine oil pressure gauge, sender also has a range of 0-5 VDC The large gauges, I would like to see about 20-30 LEDs in the bar graph ring and 4 digit LED displays: 0-6500 or 7000 RPM tachometer, 3 reference pulses per revolution on a V6, currently have a tachometer system, and looking for more accuracy than a 3-digit gauge 0-150 MPH speedometer AND 7-digit odometer, possibly with selectable/resettable trip odometer if possible (the EEPROM is why I'm curious about the Arduino so I can have a non-resettable odometer). I do not have a cable speedometer, mine runs off of a 2000 pulses per mile sending unit assembly...

I've been looking at any number of solutions to satisfy my curiosity, including a Maxim ICL series driver chip for the tach, the MAX 7221 for the odometer and possibly other gauges, and a document I found through Google that describes a speedometer with odometer for a motorcycle BUT uses an LCD instead of an LED display, complete with schematic (but I decided there has to be a different way with fewer parts, right?). I'm hoping an Arduino or similar is the answer to my problem... If it's possible, I'll work the hardware end first and then deal with the coding later as the car isn't going anywhere for a while (being completely rebuilt after being completely stripped down). And yes, I do plan on retaining the factory odometer in a hidden spot to keep the government happy...

It seems entirely possible, and quite fun
I would suggest tackling each point one at a time to ensure it will work and then combine it all

I've retro-fitted my truck with a speedo, nice big 2.3" numbers.

I didn't read all your requirements but the bottom line is you have several analog and digital inputs that need to be displayed on several LED displays. There are always a lot of issues in the details but this is basically a simple thing to do.

For displays I would probably daisy-chain several chips like the AS1108, these can handle 32 LEDs each so can be used for 7-seg, bar graphs, indicators etc. There are also other chips as you have found. You can do each gauge with 1 or at most 2 chips.

The non-volatile odometer needs some thought, but I think a standard EEPROM or flash chip that's updated every few seconds (with a wear-leveling scheme) would do just fine. Alternatively just use internal EEPROM and save the current value whenever the ignition is turned off.


I noticed that I forgot to mention a couple of things:

The engine controls system (GM OBDI, pre-1990) will be run off of an aftermarket ECU known as the MegaSquirt II. The MSII has a CAN capability, which would, in theory, make it easier to derive the tachometer, coolant temperature, intake temperature, intake vacuum, and system voltage signals. However, this adds wiring to an already overcrowded under-dash wiring harness (also running aftermarket security AND a factory security system and the harness just barely fits where it's supposed to run without damage). If someone were to suggest something along these lines, I might be able to see what I can do with the harness as there is a part of it that does need to come out (no more cruise control with new engine setup as the old system is incompatible mechanically) and there is some more rewiring to be done... I also need to get an interface board between the DB35 on the MSII and my factory engine controls system, which would need some minor tweaks before I can add a CAN capability to it.

Anyways, I was going to start with the big gauges first as those seem to be the toughest in terms of both hardware and software, and then go from there. I would skip the external EEPROM entirely unless it's necessary (probably use an SD card shield or something if needed) and just use the internal EEPROM, as I wouldn't think that a string of bytes making up a 7-digit and a 3-4 digit (depending on whether I would make the trip odo either 3 digits, 0-999, or 4 digits, 0-999.9) numbers would be too large, right? I would be using the basic Sanguino with expander board, I think.

The schematics I have in the books use a combination of the LM2917 (frequency to voltage converter), the LM3914 LED bar graph display driver, the CA3161E and 3162E (3161 being a BCD 7-segment display driver and the 3162 being an A/D converter). Which are all used at the same time (one of each) for the tachometer and basic no-odometer speedo. This seems to be kind of a waste of board space, money, and parts, even though it does work (I guess). Each combination of parts for each gauge is on its own board, with the small gauges paired up per board. Not to mention that each board has its own LM7805 regulator... (Can we just assume I'd like the whole deal to have one power source instead of multiplexing those as well?)

I'm looking at KingBright and SUNLED for sources of the 7-segment displays, and will probably have to call and get a 7-8 digit LED made for the odometer (probably would leave either the leading or trailing digit blank as it will probably end up covered by the gauge overlay). I also suppose I'll have to look around a little more for the display drivers. I'm guessing getting a couple large breadboards is in order. And I also think that I'm going to have to get my third laptop (the only one I have with an RS232 serial port) a hard disk and get it going. There are a bunch of datasheets on my second laptop that I'll have to go through when I have time, maybe later this week.

Luckily for me, I have a spare gauge cluster I've been playing with and a testing device called a stimulator that goes with the MegaSquirt, that I have been using to play with the gauges in the cluster a little bit. The stim produces a tachometer pulse (for the tach AND the speedometer, works the same, pretty much) and also has voltage signals for the air and coolant temp circuits. Which would make testing relatively easy once I get the parts together.

as I wouldn't think that a string of bytes making up a 7-digit and a 3-4 digit (depending on whether I would make the trip odo either 3 digits, 0-999, or 4 digits, 0-999.9)

Unless you plan to drive more than 4 billion miles 4 bytes is all you need, but you need to be careful about wearing out the EEPROM with too many wites.

The schematics I have in the books use a combination of the LM2917 (frequency to voltage converter),...

All very 1980s, forget that lot. Like I said, each gauge should only need 1 or 2 chips.

call and get a 7-8 digit LED made for the odometer

Just use 2 4-digit displays, 4 2-digit or 8 1 digit.

either the leading or trailing digit blank

Totally up to your software.

with an RS232 serial port

Why do you need RS232?

will be run off of an aftermarket ECU known as the MegaSquirt II.

If you can get half of what you need from the MegaSquirt then I'd look into doing that, which means adding CAN to your project.

However, this adds wiring to an already overcrowded under-dash wiring harness

CAN is only 3 wires isn't it? And the MegaSquirt is mounted elsewhere I would think or is it under the dash as well. As for the instrument cluster you can do all the displays with 3 wires as well. Sounds like you will have a lot less wires.


  1. MSII is only programmable through an RS232 connection. My laptop hates USB adapters (and USB printers, but that’s another issue). I was assuming the Arduino uses a similar connection standard…
  2. MSII does not have a vehicle speed input… Only gauge info I could get from it is what I posted above, RPM, coolant/intake temp, vacuum, possibly system voltage (but I would rather almost directly monitor the alternator as it’s failed a couple of times on me now). I’d probably use the 2-chip system from the books (2 LM3917’s, I believe) for just the fuel gauge as it seems to be easiest and it would free up an analog port.
  3. Yes, the MSII is under the passenger’s side of the dash. However, the dash harness-to-engine harness connector is already at capacity. I could piggyback something or add another connector, but it’s not that connection that I’m worried about. The center of the harness, where the cluster connects and everything branches out, is already too large. I’ll have to get the dash out of the garage and get the harness out of it again to see what I can do with it, as I plan on running at least 8 more wires regardless, down into the center console, for additional controls.

I’ll start with getting the Uno and working each gauge individually when I get the chance. To enable the CANbus in the MSII anyways, I need to do some modifying to it (if I can… Using extra ports already).

What’s the failure rate on SD cards? I know I burned one up in my laptop due to the port being right next to the graphics processor and hard disk, but that was due to heat (lost all of my good pics on it too, :frowning: ), and I was wondering if they had some maximum number of read/write cycles similar to the EEPROM.

Ok, I just need to solder in the wires to the MSII (all run but not soldered yet) to give it full CANbus capability. I had to cut 2 terminals from the board that run into the DB37 (I seriously doubt the MSII needs to have 15 ground pins! No, there is no way to add another connector to the board), so that should be all set there. Found out I only had one SPR output port left and decided I needed to modify the DB37 to make things easier, as I'll probably end up using the SPR port for the "check engine" light driver.

MAXIM 7219CNG. This chip can control 8 7segment leds (or 64 leds.) Here's ten of 'em for 5 bucks. Now for the car interfacing, I can do nothin' for ya.

If auto meter can do it (to the tune of $1300), no reason arduino can't. Use driveshaft output pulses for speed/odo.

The Megasquirt is a great box. I know a couple of people that have it on daily drivers. One guy has it on a turbo 360 in a dodge dakota. That will get you all the sensor data you will need. Just get the CAN bus working, get speed/odo, and you'll be set.

Here's your 4 digit panel:

I don't see any 3 digit'ers, so just use a 4 digit and don't use a digit?

Bar's won't be a problem. Use one LED for every 5 MPH in a 270 or so degree circle for speedo, similar for tach (250 rpm per LED?). Minor gauges might be a tad more difficult to package.

Already have the designs laid out for both the stock instrument cluster AND the cluster for the dash I plan on putting in the car at a later date. Yes, my car is a DD (or at least it was before I found the rust!) with 248K on the clock. Doing some engine work requiring a retune of the stock computer, which is difficult at best to tune (nobody touches it), so I decided to scrap it for the MSII (and because I'm sick of replacing that one sensor about every year and a half that costs a pretty penny for factory parts because aftermarket fails faster). Already have the speedo wire running to the dash (no speedo cable drive system, one of the early ones to be completely electronic). I already found a set of 3-digit LEDs from SunLED. I'd have to look at the sheet I have the P/N written on to tell you the size (height).

Going to have to learn coding as well. Good thing I have the book "Complete Idiot's Guide to C (C++, maybe)".

Don't be so quick to discount other peoples projects just because they don't perfectly match the setup you're looking for. IMO the (accurate) data acquisition is the hard part of this project Once you've got the numbers into the project then the rest is just making lights blink, and there's no shortage of tutorials on that online.

Personally I wish I had a CAN bus to pull data off of. In my application I found directly reading the sensors to be quite a bit of a pain with lots of noise and interference issues, but my experiences seem unusual compared to other similar projects so you could very likely have better luck.

I also suggest you use the CAN to get all the data you can from it. The MS can impletmenation is a bit strange. It is not "information availible" you will need to request the data you want from the MS and it will respond.

One of the projects I got my arduino for is a CAN enabled MS dashboard/SD datalogger.

I'd like to connect my LC-1 wideband's serial output to the arduino, and write that to the MS's memory location. (this will be more accurate than the analog output I currently use) I'd also like to connect the wheel speed sensors to the arduino. (perhaps after a frequnecy to voltage IC) I will probably still a convential analog autometer tachometer, with it driven directly from a tach out circuit from the MS. I cant compromise on update speed or accuracy there.

The lack of aftermarket dashboard support for the MS is it's only remaining hurdle to truely compete with off the shelf standalones IMO. The goofy CAN implentation is not helping either.

I'll get all of the data I currently need from the CANbus and then maybe get some more later when I possibly add more gauges/sensors. What would be ideal would be dual oxygen sensors (1 per bank) and dual EGT sensors, as I would like to monitor both sides of the engine individually, but that's a long way off from now (but would give me a good reason to cut up my cracked dash pad).

Having a bit of trouble understanding the SPI and I2C interfaces for multiple chips, specifically when it comes to coding.

Also confused on how to run both a 3/4 digit LED CA display AND LEDs set up as a bar graph off of the same MAX7219/7221 (probably going to use the 7221). Would like to start working on the schematics in ExpressSCH or PCBArtist...

I'll probably nab a Nano (I know I said Uno above, but I meant Nano, smaller is better here) and a decent size breadboard to start with. I have a few feet of 4-wire 22-gauge intercom cable I can cut up for the required jumpers. I also think I'm going to use the MAX7221 IC for most of this project, and a small SD card for the shutdown non-volatile memory.

Nick Gammon has good coverage of basic SPI usage on his page

Arduinos have EEPROM built into the chip, as long as your non-volatile data is less than a couple of K you don't need any external storage for that alone.

If you want the smallest footprint for your project I would recomend getting whatever board you like to prototype with, but then plan on designing a custom board with SMT components. Boards are reasonably cheap to get manufactured, and it really is easier than it sounds once your circuit is already designed and prototyped on a breadboard.

I think I may have a working schematic, I drew one up on paper last night for the speedometer. I have to transfer it over to ExpressPCB on my other laptop (doesn't have wireless or ANY internet connection) and then over to this one in a jpeg format so I can post it and see what everyone thinks. I'm thinking that if I use a single MAX7219/7221 and connect the bar gauge LEDs as digits 3, 4, and 5 (on the speedo, which has a 3-digit display; 4, 5, and 6, possibly 7 on the tach, which will have a 4-digit display), and use a "segment" of each "digit" to control the bar graph, it should work, right? Or does the MAX72XX series not work like that?

I'm not worried about the width of the project as I have rather large housings to work with that are mostly square (except for the steering column cutout in the one housing), and the mountings inside can be trimmed to fit, but I'm concerned with the depth, which shouldn't be too bad if I limit myself to between 2 and 3 boards thick (I have about an inch and a half or so in each housing to work with in depth). Also concerned about heating inside the cluster housing. Surface mount is going to be difficult at best for me as I have enough difficulty with DIP IC soldering... Can someone recommend me a power regulator? It would seem to me that there would be a lot of LM7805's required to fulfill the power requirements of both the gauges and all of the MAX72XX chips. I'll probably end up using a 7805 for each gauge display, but I'd like to cut down to one regulator for all of the chips (with the exception of the Arduino, which will have its own input).

Another problem is the manufacturing standpoint... I have a PCB drawn up for the MSII to stock engine computer interface, and, since the company using ExpressPCB requires 2 of them, it's around $70 for 2 2"x6" boards, dual sided. I'll start with a breadboard for each gauge and then see what happens. Then, hopefully, I can use something like a RadioShack PCB for each gauge set. It may be messy, but as long as the displays light, it won't matter, as I'm going to have the inside of the cluster housing lens covered in tint film to hide the guts. Yes, I'll draw PCB's up on ExpressPCB and get quotes, but I don't think it's going to be cheap unless I can find a way to make single-sided boards.

First off, for PCBs, . Cheaper than hell, three boards for the price of one. Also, he'll check out your eagle files so you don't try and send off a board with serious errors (no drill layer, like I did :-P.) Second, the MAX72xx can control any arbitrary arrangement of LEDs up to 64.

There are quite a few good options. I've heard good things about Dorkbot, BatchPCB can come cheap if you're willing to wait a little longer on it. I got mine done at SeedStudios and I paied like 38 bucks for 10 boards 3"x4"

Okay, made 2 more schematics, one for the tach (that I'm posting), and one for the odometer, which is a total of 3 now. I was going to post up the one for the speedometer, but I realized I need to fix a mistake I made in both it and the odometer schematic, being that the digits on the LED displays are labeled left to right and the display controls on the MAX72XX series run right to left :~ .

Another problem is that I seem to be stuck with ExpressPCB and need to get the PCB designs made up before I can transfer them out to another program to be converted into the Gerber format. Free Eagle doesn't have the board sizes I'd prefer, and I'm sure it's going to take me more than 30 days to get everything taken care of in the PCB and SCH designs, which is how long the free trial of full Eagle lasts (this is a back-burner project, only working on it a couple hours a day max). I would use PCBArtist, which seems to have the proper output files, but then I would need to manually input nearly EVERY component I'm using (no LM3917, MAX72xx, MPX4250, etc in the library), which is a big headache and time constraint. As it is, I will need to manually make the outlines and pinouts for the LED displays in ExpressPCB...

Tach schematic... Well, I have it on my laptop here, but I can't figure out how to post it :eek: .

Free Eagle doesn't have the board sizes I'd prefer,

How large do you want? It does a fair size board.


Well, I'd like to try to get at least most of the actual displays on one board, connected to the brains by something like a ribbon connector... One is 5 1/2" by 14", and the other is 5 1/4" by 18" (2 separate clusters, one at a time, though, starting with the 14" cluster). And then for the 5 1/2 by 14, there is a separate card going with it because of the shape of the cluster housing, approximately 5 1/2" square with cut-offs (speedometer/odometer). I could divide the large 14" board up, as in the stock gauge face cards, but that would mean more connectors and money... I was hoping one large board and one large connector would work.

BTW, would a simple socket for the Nano work on the main "brain" board? If so, what kind of socket is it? I can't seem to find a package outline description.

I think I'll post the tach schematic on Photobucket and then post a link... Seems like it would be easier that way.