I'm thinking of doin this too, and maybe even having a secind computer dedicated to this purpose. Just one question, though: How can you tell how much gas is left in the car? Do they make something that can measure how much gas you have left, and transmit the data back to a computer?
How much gas? If the vehicle is "new enough" (probably post 2005, but certainly earlier on some vehicle models) you can obtain fuel level from OBD. To do that, you would also need some piece of hardware to connect to the vehicle's OBD port (e.g. ELM device, Mongoose, etc.).
i was thinking of installing an 8 inch screen and then 2 smaller ones on the side like maybe 3 inch screens.... The 3 inch screens would have gas and oil on one... and volt and water temp on other.... the 8 inch would have rpm and speed.... but the guestion I have is how would I connect all this together? currently my set up has the onboard graphics card and the a second card for the rear and passenger tvs.... Then on the other PCI slot a USB card.... is there a way to add a third graphics card?
Originally Posted by star-art
There are graphics cards out there that support up to four monitors.
I also believe that I saw a USB monitor out there recently.
I'm guessing you only have two expansion slots.
hutacars: If you're not using OBDII to get the gas levels, you'll need to tap into the "sending unit". ALL vehicles since (I believe) 1984 used an electronic sending unit. They obviously get more accurate as they get newer. Some used a floating ball, newer ones use digital sensors. No matter what type of sending unit, they all send information back as voltage variance. The lower the voltage, the lower the gas level. Some varied between 3V-5V with steps of 0.1 volts. Basically, it's going to be a mess if you don't have OBDII.
Turby: I completely agree with you that Flash is a very slow and inefficient way of going about this. Unfortunately, I don't know DirectX, OpenGL, or any other type of graphical programming yet. My skills are mostly limited to Java, PHP, and Visual Basic. So Flash was an easy decision since I use it often. Though if someone could program the front end, I'd have no problem programming the back end. I want to make the back end web based so that it can be run either remotely or locally on any type of computer OS with minimal CPU usage. I know this sounds strange, but believe it or not, after all my experience in programming and servers, it makes plenty of sense later.
I've been quietly studying up for this project for many months. It seems the technology wasn't quite ready, but is starting to catch up real fast.
First, a PC-driven display in the instrument cluster (vs in the center of the dash) is not ideal at this time IMO. Why? Because it seems PCs aren't quite ready for "instant on" capability plus the reliability needed to work without the system crashing as you're driving. (Imagine going down the interstate at 70 mph and losing your display!) So, I am back to an embedded solution for starters.
Ah, but that is where there has been some real progress. I am designing some embedded hardware (i.e. microcontrollers and circuits) to talk to the vehicle. This will gather the data for the display system and will be Phase I of my project. The first step is figuring out all the protocols for my car which I have pretty much done. Next, I'll build some test hardware, hook it up, and test side by side with an actual electronic instrument cluster out of the same type of car. This way I can make sure my hardware is giving me accurate readings. This stage of the project is currently in progress.
Phase II will involve connecting the custom hardware to a dedicated (i.e. embedded) display system that can be installed in the dash. This will replace the existing instrument cluster completely, offer "instant on" capability, and the reliability of dedicated hardware.
Some exciting new developments such as 4D Systems new AMOLED displays are just now becoming available that will make all this much easier. For example, you can now get "smart displays" that can be programmed using your PC in an IDE that runs in .NET. This custom programming language (not your usual VB, etc. but something programmers can easily use) will allow you to control all aspects of the display.
This removes two major hurdles to building a dedicated embedded instrument cluster solution, which are 1) generating the graphics and 2) driving the color display. Now, you can design your graphics and the program that runs them on your PC. Then, flash the code into your display module via USB. Finally, connect the display module to the vehicle interface hardware and, voila! You have a beautiful set of brilliant custom gauges.
Best of all, you should be able to change the look of your display (and its functionality) by updating the firmware. Just install a USB port somewhere on or under the dash, connect to a laptop, and flash to update the code that runs the display with the latest version. Finally, turn on the ignition and see your updated gauges!
I see AMOLEDs are starting to make their way into automotive electronics. While display life is a concern, it appears the temperature range is good for our use (-20C to +70C). Over the next few years, the displays are probably just going to get better and better.
One day, I will make it to Phase III and that is connecting the dedicated hardware to a PC on a chip or a single board computer that can handle the display reliably. That will then replace the embedded display to allow even more functionality like networking with the in-vehicle entertainment system in the center of the dash.
But, one step at a time. . . :D
Very neat. I've never heard of AMOLED. I'll look into it soon. I've also been out of the loop for a little while since I've been busy with other projects. I think you're definitely on the right track. An embedded solution is the only way (currently) to have instant-on capability without going through stand-by. OLED has always been my choice of screen (because of power consumption and contrast) so I've been waiting patiently for it to come to retail markets.
You can still use Networking and other non-embedded feature with an embedded system. I would require your software to do a resolve of data at the period of "instant-on" status. After all, your current gauges all do the same thing. When you turn on your car, all your dummy-lights and gauges flicker or come on waiting to resolve information from the car's ECU/Computer. So why not have your embedded system do the same? If programmed right, you could have your GPS work through the network and display turns or upcoming streets through your cluster. There's lots of possibilities.
Let me know how things are going with this. I've still be contemplating how I want to go about this with my project, and trust me, I've been thinking about this for many years. (Finally making enough money.)
Talk to you soon about this.
For sure, the sky's the limit. You can do just about anything your hardware can handle. I just want to get a display working for now and then I can go from there. :)
This application will require some non-volatile memory. I spotted some serial EEPROMS that are automotive grade. On shutdown, the controller will need to store certain data such as the current mileage, etc. Then, on power-up, this stored data will be recalled and realtime data used to update it until the next shut down.
When you refer to all the lights coming on at power-up, that's called "prove out." This is actually a diagnostic function designed to ensure all the display elements are working. For example, if your idiot lights are incandescent bulbs, you might not realize one of them has burned out. The prove-out function lets you check to make sure the bulb illuminates. If this was not done and a bulb burned out, a warning could be "on" and you might never know it. That could prove disastrous, so the "prove out" function was added as a safety measure.
This design philosophy was carried over to electronic displays as well. Having all the segments illuminate makes sure there are no bad segments. That's needed because nearly all electronic displays up to this point have been VF and LCD units made up of discrete elements. Once the move is made to a matrix display like a modern color monitor, this functionality is no longer needed.
Even so, I plan to emulate this function anyway. It just looks cool! :D
BTW, the "smart" AMOLED displays can be found here.
Has anyone actually completed such a setup? I was thinking about using a 7" LCD in my BMW for speedo and rpm. It looks like it might fit perfectly. I see lots of talk but no completed projects.
I've been running a setup in my race car for around 18 months. More info at http://www.mp3car.com/vbulletin/hard...ed-guages.html (post #15)
The screens and functionality have evolved from those shown but you can see the general idea.