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
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 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.
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.