Digital Auto Instrument Cluster

[martianent]

Okay, it's been a while since I've been on here, wondering about the best way to go about building a 4-digit tachometer. I've gotten a new book by the same guy where I had gotten the tach idea, which includes schematics for a full digital instrument cluster. However, it has occurred to me that there seems to be a TON of unnecessary parts in these plans IF I choose to use a microcontroller as was suggested to me in the other topic.

My goals are the following:
LED DISPLAY. NOT LCD. When the gauge cluster is assembled for the factory dashboard, I WILL NOT have any room for an LCD. Period. The factory gauge holes are too small, which would make reading an LCD difficult at best.
Cheap. As in UNDER $400, the point at which I could buy a Dakota Digital gauge set and have to seriously modify the boards to fit in my cluster housing.

The gauges to be made are:
10 LED bar fuel gauge, resistance of 90 ohms full and none empty.
10 LED bar engine manifold vacuum gauge using a spare Motorola MPX4250APX I won't be using in my replacement engine controller. I think the maximum output of the 4250 is 5 VDC, but I need to dig up my datasheet to confirm. If not, I have a spare factory manifold pressure sensor that DOES have a maximum output of 5 VDC that I will need to add wires for through a couple of connectors before running to the gauge cluster.
Combination bar and digital 7-segment 3 digit readouts:
Battery voltage gauge, 8 to 18 VDC.
Intake air temperature gauge, probably somewhere between 20*F and 120*F
Coolant temperature gauge, maximum reading of about 260*F before I would like the display to flash if possible.
Engine oil pressure gauge, 0 to 70 PSI (yes, it seems high but the engine oil pump regulator is set to max pressure of 70 PSI from the factory), 2-digits. All 3 of these temp and pressure senders have a max output voltage of 5 VDC.
The big ones, at least 20 (between 20 and 30) LED bar graph and 4-digit segment display:
Engine tachometer, 6500 RPM maximum, 6 cylinder. Currently have an analog tach.
Vehicle speed indicator, maximum of 150 MPH. Currently have an electronically-driven analog gauge with 2000 pulses per mile (PPM) on 13" radius tires (26" diameter).

I have been researching this like crazy the last week or so now that winter is coming and I have a little less to do outside, and the only things I can come up with don't come close to my dilemma and most have an LCD display.

I have another gauge cluster from another car that has a VTF (I think that's how it's abbreviated) display. This display includes: bar fuel gauge, speedometer in either MPH or Km/H, trip odometer, vehicle odometer (non-resettable). I would reverse-engineer this thing but I can't find datasheets on what was apparently custom-made chips. The rest of the gauges are analog.

Which leads me to my last problem: The schematic in the new book for the digital speedometer also has an additional circuit for a digital odometer. However, I do NOT want to have to reset this odometer if the battery lies dead for 10 days (how long it takes before the backup circuit in the digital odo loses power), say, during winter storage for 3-5 months. Which is why I was hoping I could at least build the tachometer (using the MAX7221 display driver) and the speedometer (probably using the same chip) with the attached odometer (MAX7221 with EEPROM for memory storage) using a microcontroller, which would probably reduce parts significantly. And yes, I know about the legality issue, which is why I plan on retaining the factory speedometer for the original odometer, in case things go batty, hidden behind a couple of heating vents which no longer connect to the heating duct.

I was thinking it would be easier to have the inputs go into the microcontroller for the frequency measurement off of the vehicle speed sensor output and the tachometer feed from the ignition, and then use an A/D converter (CA3162E is mentioned but seems useless) for each of the voltage inputs for the other gauges.

I just need a mention of a decent microcontroller and the rest of the ICs, of which I will dig up datasheets and draw schematics accordingly until I get something I can use. Coding will come later when I get my hands on a programmer (have a chip to read as well for another purpose).

 

[fastback86]

I know this is 6 months old but I have schematics for everything except for the odometer which is what I am currently researching.

 

[martianent]

I've done some further research since then and have decided that an Arduino Nano-based cluster is the best way. I have the schematics and boards drawn up, but haven't submitted the boards to be etched and cut as I need the money for other things at the moment. I have the Nano, however. The Nano will be taking inputs from the factory instrument cluster connector and feeding the output data into a set of Maxim MAX7221 ICs for every gauge except for the intake manifold vacuum and fuel gauges, which will still be run by LM3914 ICs. Good thing is that the Nano has a built-in EEPROM that will save the odometer data when programmed properly. Once I figure out the programming, however.

 

[3v0]

The an electronic odometer requires non volatile memory. Every so many spedo pulses is one mile.
The trick is to not wear out the memory chip. You could use battery backed up ram and only save it to flash or eeprom every 100 miles or when the the power going away.

This is most easily and possibly cheapest to do with a small micro controller.

 

[martianent]

Best thing to do would be to save to EEPROM every time the vehicle comes to a stop as some trips are less than 10 miles. That way, you wouldn't end up losing mileage for a trip to the grocery store (unless the store is far away). And also finding a way to use different parts of the EEPROM for saved information.
Arduino Nanos are less than $30, and are even sold at RadioShack (USA), and come ready to plug in the digital AND analog inputs. But then comes the programming.

 

[fastback86]

I've done some further research since then and have decided that an Arduino Nano-based cluster is the best way. I have the schematics and boards drawn up, but haven't submitted the boards to be etched and cut as I need the money for other things at the moment. I have the Nano, however. The Nano will be taking inputs from the factory instrument cluster connector and feeding the output data into a set of Maxim MAX7221 ICs for every gauge except for the intake manifold vacuum and fuel gauges, which will still be run by LM3914 ICs. Good thing is that the Nano has a built-in EEPROM that will save the odometer data when programmed properly. Once I figure out the programming, however.

I would be interested in seeing what you have so far...

 

[fastback86]

The an electronic odometer requires non volatile memory. Every so many spedo pulses is one mile.
The trick is to not wear out the memory chip. You could use battery backed up ram and only save it to flash or eeprom every 100 miles or when the the power going away.

This is most easily and possibly cheapest to do with a small micro controller.

I didn't know you could wear out a memory chip I've found code for a clock and a frequency counter based on a 16f628 I'm sure I can modify it to count pulses but I don't have a clue how to add memory.

 

[ronsimpson]

FLASH and EEPROM will ware out. RAM will not.

 

[KeepItSimpleStupid]

MRAM is a relatively new technology which holds data forever and can be written an unlimited number of times: **broken link removed**

They really do exist and they are available in SPI: http://www.digikey.com/scripts/dksearch/dksus.dll?vendor=0&keywords=MRAM

 

[dougy83]

but haven't submitted the boards to be etched and cut as I need the money for other things at the momen

If you're interested in an affordable PCB service, I've used seeedstudio a couple of times (https://www.seeedstudio.com/depot/fusion-pcb-service-p-835.html?cPath=185). They're cheap and quite fast; pcb quality is very good (except the silkscreen overlay is quite low resolution which doesn't matter to me).

It's easy to add loss-of-power detection to the micro to enforce writing to the eeprom. The wear on the eeprom (>100,000 write tolerance) won't be a problem -- even if you're writing to the same location each time -- if you are a little careful with deciding when you write.

 

[OlPhart]

Howdy, another ... So long as real power is available (+12 bat) just keep the odo total in ram. If/when power goes completely out; have a cap big enough to allow time to write to Flash. Used this 2+ projects, make sure cap is well big enough to worst case write all data to Flash. A power isolation diode for just the micro & Flash may help...

The power out sense can be IRQ*... <<<)))

 

[3v0]

I really do not see using an arduino for this project. If you can manage the arduino you can do it with C on a PIC too.

Start with a 100mA regulator designed for use in cars. I will post the number when I think of it 29 something I think.

Then use a modern low power 16F or 18F PIC (I prefer 18F) with page erase byte writeable flash. These uC's have several sleep modes including one that preserves RAM. Some have Real Time Clocks. With this setup you should be able to play some games where the flash would last much longer then the car.

The only other thing you need is the display and any signal conditioning the tach signal needs.

The pic will be under $5 and you can use the money not spent on the arduino for a picKit2 or pickit3 to program the PIC.

 

[martianent]

Okay, I have put this on the back burner... Had to redesign the cluster twice now and have other things to worry about before messing with this.
I don't see where a PIC plus ANY burner will cost less than the $20 or less I paid for the Arduino Nano I have plus the programming cable (which was free since it's merely an old digital camera cable).
New design is using a similar design as is already posted on the Arduino forums, but that is merely a datalogger whereas this is a full instrument cluster. All of the inputs are run into an MCP3208 and then run via SPI to the Nano. The MCP gets the tach signal and speedometer signal from 2 LM2917s. The output side is handled by a series of Maxim MAX7221 ICs, one for each gauge. I have not quite figured out what I'm going to do for the odometer retention, but I think that the program will be so large anyways a 256 MB SD card is in order, and I could probably use a small block of that for the odometers.
I have the Nano and have played with it a bit, and also have the MAX7221s, but I haven't done anything with the combination yet because I don't currently have a common cathode 4-digit LED (the one in the Arduino starter kit I bought was common anode). And, like I said, I have put the project on the back burner for now, seeing as how it will be over $250 for both boards either way (not including LEDs or other parts).

 

[KeepItSimpleStupid]

Use FRAM memory for the Odometer. https://www.google.com/url?sa=t&rct...iWnOc8hS6J6U0tw&bvm=bv.67229260,d.cWc&cad=rja

If you use any other technology, you can also try to minimize writes.

A possible display: https://www.sparkfun.com/products/11440?gclid=CMGY2e2_ub4CFesDOgod2WwAYQ I think there are I2C to LED drivers "out there".