Slashdot Mirror
Making a Color LCD Dashboard Replacement?
DarkHand asks: "I've recently begun a project that would allow me to replace the analog gauges in my cars dash with a TFT LCD screen displaying a digital representation of the same. A number of animated analog-looking gauges would display the same information the physical gauges display, based on info from the ECU, as well as any other information the ECU has access to, such as intake air and coolant temperatures, throttle position, pop-ups for any warnings or error codes, etc. I'm looking to be able to add, remove, and customize the positions of the individual gauges, and possibly even make the background skinnable. Stability is crucial, so I'm leaning toward a Linux-based system. I have a few software friends who are willing to help on that end, but finding the proper hardware for such a project has proven difficult."
"I need something that either boots within a few seconds, or draws very little power when idle so as to remain active and run off the cars battery. A laptop or small computer boots too slowly, and draws too much power to stay on all the time. A high powered PDA with a larger screen would be perfect, but as far as I know it's not possible (or at least not easily doable, both in hardware and software) to change out to a larger display. The best option I've found so far is the venerable Gumstix board, but as far as I can tell, LCD support is still shaky. Has a similar homebrew project been done before, where I could go for wisdom? What kind of hardware would the Slashdot crowd use in such a situation?"
I suggest getting a Toyota Prius if you want to drive a space ship. Check this picture out.
http://www.thelung.org
Wouldn't this kind of things have to be certified first? I mean, I can imagine a scenario where the driver would say to the police: I didn't know I was going 120 /h, look, my gauge pnly says 20 :-)
I'll do the stupid thing first and then you shy people follow...
what you want is an RTOS. Look around at various embedded sites, such as www.circuitcellar.com or www.embedded.com to find similar projects that us an RTOS or no OS at all.
Do not for the love of God make your speedometer be a PC.
--buddy
I don't think your car would be road-legal with a software speedometer. What you might be able to do is use an FPGA as that does not strictly count as software (sometimes). Use an FPGA and an LVDS driver chip and not much else, and you might be able to get away with it.
If you don't know how to do that I would *seriously* reconsider your idea of replacing a piece of hardware that you trust with your LIFE.
Let's be honest, you don't want your eulogy to be "Well, he wanted his car to play the Back To The Future music when he got to 88 mph."
I googled 'OBD II' a while back and found these:
t m
http://www.obd-2.com/
http://www.ghg.net/dharrison/obdscan.html
http://www.obdii.com/ubb/Forum1/HTML/000359.html
http://www.andywhittaker.com/ecu/obdii_software.h
http://www.elmelectronics.com/obdindex.html
http://www.dynahud.com/default.asp
They should get you started...
Leaving a computer in the cold weather might also be a problem, and LCD's have a noticably slower refresh rate in the cold.
Make your computer faster: rm -rf
http://www.arcom.com/pc104-xscale-viper.htm
Some of those thingies running embedded Linux might do the trick. Just attach it to the car's computer via USB or serial cable. It has its own LCD controller and can run embedded X windows even. Then writing the software is relatively simple.
The GeekNights podcast is going strong. Listen!
Well, it strikes me that the obviously wisest choice here is to leave well enough alone. Mechanical components are so much more reliable, there's no comparison.
Plus, I'm not sure what the regulations are in your country/state, but here in in Australia it is an offence to reset an odometer unless an engine has been replaced (in which case the vehicle has to pass an inspection by agents for the authorities). I'm pretty sure that kind of modification, where the gadget could be easily reset without trace would be illegal.
I'm sure there must be more useful avenues to apply geeky talents.
You won't be able to see it in the sun, this is a bad idea...
You might consider one of these
From the site:
SIS 55x processor (x86 compatible)
3 USB ports
2 Serial (RS-232) / 1 Parallel port
Built in AC97 audio - Audio in/out
2 VGA out ports
ATA-33/66/100 support
1 or 2 RJ45 for 10/100 MBit Lan
PS/2 Keyboard/Mouse connector
Single 5 Volts DC @ 1.8 A support
128 MB RAM
20 GB 2.5" hard disk
1 NTSC or PAL video in (frame grabber)
1 NTSC or PAL TV out
Support for two VGA displays
I've been looking at doing a project like this for a while now, so I'd be interested to see how you go about some things.
Most manufacturers deliberately have their speedometers read high by several miles per hour (my MINI Cooper reads about 3mph high at low speeds - going up to 5mph high at 80 to 100mph).
They do this for liability reasons. If for some reason the gauge is off by a little bit and you get a speeding ticket (or worse, you get into a wreck) - then they don't want you to sue them claiming that the speedometer was reading too low. By making them read a little high - then even if they get mis-calibrated (eg due to tyre wear, higher-then-recommended tyre pressures, etc) they still won't be reading *LOW*.
So - if your LCD speedometer is off by a bit, you won't really be that much
worse off than with the stock speedo.
As someone previously suggested, you might want to look at the OBD-II specification. All cars sold in the USA in the last 10 or so years have a port located down under the steering wheel somewhere which delivers a wealth of interesting information in a more or less standard format. You can certainly read RPM for your tachometer - along with the rotational speed of each wheel independently and a bunch of other fun stuff. You could probably interpret the error code readouts it gives you to light up warning lights in a meaningful way.
www.sjbaker.org
I think for that, I'd use a linear guage like a progress bar, which you can update as often as you like and let the LCD take care of blurring it "in hardware" (when life hands you lemons, make lemonade :-) ). The number can be a running average of the last second or so to stabalize the number, and with only slightly more cleverness you can ensure that if that number is flopping between two close numbers like "74" and "75" that you'll suppress that.
(You may even be able to kill two birds with one stone here; I'd suspect, though I'd want to test, that an algorithm that says "Don't change the number on the display unless it is more than 1 mph (maybe 2kph) off" would fix most problems.)
Which brings up why I think this whole project is dangerous; this sort of stuff is non-trivial, and I for one wouldn't care to have information critical to my life running on something I whipped up yesterday because I thought it was cool. (I would be confident I could do something with user testing support, but it would certainly take many iterations to get all the bugs and suboptimal behavior out.) We all know how good most programmers are at user-friendly interfaces, so good that I feel I should point out that "user-friendly" also encompasses presenting relevant information in a format that is easy to read since the evidence suggests a lot of programmers haven't caught on to that facet either. Also note the distinction between "bug" and "suboptimal behavior" in my parenthetical, another distinction a lot of programmers miss; functional can be the enemy of usable. I can't wait until you're programming your car dashboard. (Might learn something about the subject, though.)
It's a free country, of course, but if I got the car hacking urge, I'd much rather hack up my radio than my dashboard.
I've chosen to install analog speedo, tach, H2O temp and oil pressure. This allows the LCD screen to be less expensive and less important so I don't mind as much when it's unreadable (say, a cold start at 0 degrees).
:)
Even with a good (transflective or super-bright backlit) screen, you'll need to ensure that it is shaded well against light from an oblique angle. Depending on your dashboard, that might be easy or it might be hideous.
Right now I'm thinking I'll gut an IPAQ H3950 running Linux to supply the display and controller. Apparently it has a good screen, and I'm sure it's rugged enough for automotive use. The battery will help a lot too. The one drawback that I can see is the screen is only 320x240. I yearn for 640x480, but I've been unable to find aything daylight readable in that resolution for less than a few thousand dollars.
How to interface to it? Wifi!
Be sure to check out mp3car.com. I'm currently installing a PC in my car that will have an OBD-II interface. The forums there will probably be able to help you with your hardware and software selections.
Actually, LCD's don't really have issues like that at the moment. Check out the Pioneer AVIC-N1. Its a DVD player that hooks into the vehicle and will display the gauges, just like the story parent wants. Its possible, just a matter of making it work from scratch.
I'm doing this myself now. I'm still in the early stages but have most of the parts. Just need to pick the computer itself and the power supply. (Probably go Opus with a ITPS)
;)
:)
It's definitely going to be linux. I think I'm going to just put a half tower in the trunk as I'm going to need a lot of expansion cards.
I'm leaving the gauges in place and putting the monitor (lilliput 8" touchscreen) in front of it and wrapping it up in custom fiberglass cowel.
My wiring passes through the gauges into other systems, for instance the battery charger so it's easier to leave everything in place and easier to just remove screen and replace with stock cowel for inspection time.
For the harddrive, I'm using a ruggidized harddrive designed for automotive use. Slow but it's got a great temperature range and shock rating.
The keyboard I'm using is a tiny one I found on ebay. I cut it down to fit in a 1 DIN position. It fits between the stock radio and AC controls. You don't know it's there when retracted.
Most of the inputs will come from OBD-II (elmscan that I embedded inside floor) but it's not fast enough for the tach and speedo. (4 samples a sec at beast ISO) I'm tapping the tach, speedo and a few other input signals directly and processing them with a PIC. The PIC will then communicate with the PC via serial.
I'm thinking later, I'll add a large commodity drive for other non essentials that will be activated via a temperature controlled relay. So if it's under 40F in the trunk, it won't power the harddrive until it is hot enough or maybe I'll just use a USB drive.
My first advice is to buy the factory service manuals on ebay. They are invaluable. I got mine for $40 US. Three phone book size volumes with schematics as well.
You might find the factory training books for the electrical and whatnot as well. I did. It was nice to have the whole ECU protocol detalied. (Though not planning to tap into it at this point)
If possible, buy extras of whatever your going to mod on ebay. For most parts I'm fooling with, I have 2 or 3 extras that I've amassed over time. If your patient, you can get stuff cheap.
For instance, in my spare room, I have a spare dashboard, gauges and most everything else on the dash. I'm using this to work on the fabrication so I don't have any downtime (or screw up my car)
$1700 dollars worth of stuff righ there. $240 shipped in mint condition. Patience is the key.
As far as the legality, I'm not concerned. If I had a massive failure, the only thing that I would be missing are my current speed, engine rpm, fuel and oil temperature. Nothing that would ever cause a crash. I can estimate the first 3 fairly accurately. Certainly enough to safely pull over and remove the screen and use the OEM gauges. A fuse could do the same thing to the OEM gauges (and has to me before)
Besides the fact that I'll have more readings on my car (which will actually improve safety), In phase 2, I'm going (try) to tap the ABS wheel speed sensors. By using the four sensors, I've now added differential tire pressure monitoring to my car.
My whole design goal is to have something integrated, yet I want it stealth. If you walked by, you'd have no idea it was anything special. You might if you were astute, notice the monitor, but you would probably just mistake it for a regular an OEM readout.
A great site (Australian cars though) for technical car info and ideas is Autospeed.com.
There is some other stuff, but I'm not going into detail until it's done
-William Shatner can be neither created nor destroyed.
Free RTOS has an open source RT kernel as well as some handy dandy how-tos and technical resources.
R(k)
If you own the vehicle, as long as it's safe, why would you be unable to drive it after replacing parts? [emphasis mine]
It doesn't just need to be safe - it needs to be certified as safe. If the authorities in charge of traffic safety where you live can't verify that it's safe, they'll err on the side of caution and not let you drive it. For your safety and others'. Those authorities are accountable to society for maintaining safety and they will cover their own asses.
You make the mistake of thinking you can educate the fundamental stupidity out of people. You can't.
Response time has already been pointed out, but I think contrast ratio is much more important. LCD technology is not suitable for this application. Consider how bright the glowing needle of a modern gauge is, compared to the dead black of the face behind it. Or vice-versa, for the white-face gauges with thick black needles. An LCD has a continuous backlight and relies on each pixel to block light in its region. A little bit inevitably leaks through, resulting in the mottled gray that LCD makers euphemistically call "black".
If the contrast ratio weren't bad enough, you have significant temperature and response time issues. Most affordable screens will go nearly blank in extreme hot or cold, as the controller's adjustment ratio hits its limits. Wide-thermal-range LCDs are expensive and have their own tradeoffs. At least you don't have to worry about viewing angle.
Plasma displays would be better suited for this. By actually generating the light at each pixel, they solve the contrast problem pretty neatly. Their mechanism is also fairly temperature hardy. Interfacing color plasma displays is even more arcane than LCD though, so I wish you luck. If large OLED displays were available, I'd suggest them.
Did you say skinnable interface? Watch out for cock-shaped soundwaves. Holy shit, as if the usability of modern vehicles wasn't already bad enough.
Anyway, a replacement for the stock cluster sounds a bit ambitious. Try an add-on panel for now. Actually using a PDA like you suggested sounds like a good way to start. Get your software worked out, for pulling the values off the bus and drawing gauges with low latency.
One more thing just occurred to me: Have you ever watched the display of an LED clock jump around while chewing, or walking, or anything that makes your eyes wiggle a bit? Each segment is only lit for a small fraction of each second. LCDs don't suffer as much from this problem because the crystals in each pixel are slow to respond, but you still might get shimmer or wiggle as you go over bumps in the road. The refresh cycle of your display's controller will determine how obvious this is.
Next issue: Getting the data from the ECM. OBD-II doesn't allow high refresh rates, last I checked. It's fine for watching parameters like throttle position and temperature, but a tach might not be practical unless you're reading straight off the CANbus. Alternately, try to get the data that the computer's already sending to the gauge cluster, in whatever custom format that is. The problem here is that this high-refresh-rate data is only sending the parameters that your existing gauge cluster needs to know about.
I don't want to sound like a killjoy, but from the questions you're asking, this project sounds a little complicated. There's no harm in trying, but don't be disappointed if you end up with a marginally useful system. Publish your findings so that others can benefit.
We can provide you with hardware in exchange for writing the software.
We've been in this space for quite some time now and we're very familiar with it.
Our site: www.dashwerks.com
We're linux and RTOS embedded...
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.