LCD Monitor Gauge Cluster
My 2007 Chevy Cobalt has a fully implemented CarPC with Gigabyte mobo running @ a Pentium E6300(2.33ghz x 2, technically a core2duo by architecture), 2gb RAM, Xonar D1 sound, an array of available media reading capability, full wi-fi and internet from my hd2 running wi-fi router, BoomzBoxHD, Phoenix SOHO card, BU-353 GPS, running CF3.1, Lilliput 629 monitor, Win7 x64 and soon to have the OBD2 scanner ordered.
I've been in the community for a number of years, but as of 2 years ago I made my dreams come true and started with an old Duron setup, upgraded to my old P4, and now to my current machine.
My CarPC runs 100% stable. Hybrid sleep functionality works flawless, in fact every operation thus far on my new box which has been running for months operates flawlessly. From standby boot it's under 10 seconds. From hibernate boot it's under 30 seconds, without having done extensive bios/os tweaks.
My newest project involves installing a non-touch screen or touch screen widescreen, preferably 10inch, over the gauge cluster(very easy, gonna leave stock stuff behind as a just in case) as an overlay. Will look professional when finished. The goal is to have normal cluster functionality on the lcd while including the ability to access any of the media windows, cams, gps, or obd diagnostics directly from the drivers gauge cluster monitor.
I'm hoping that the community and MP3Car will see the value in this development and help make my next dream a reality.
Also, Intel is just up the road from me. If they ever wanted demo's or anything I'd be more than willing to give a sweet demo for them.
Attached are a few of the video's I've captured. In a couple you should be able to view the gauge cluster.
Newest, CarPC night. Taken off HD2
CarPC, no sub vs sub, with a lil peel
Back with the P4 setup
When I was first doing tests on the CarPC. Duron setup
And some Q/A that's already occurred in the thread:
One thought was to tie into the connections on the actual cluster using a fusion brain. But that's not really a viable option as the stock gauge cluster is actually fed by the CAN bus.
Originally Posted by 2k1Toaster
Another thought that I had, the E37 computer equipped in the car has a very fast refreshing and higher baud obd bus. Because of that, I was thinking the easiest route would be for my friend Steve and I to interface using that, and polling the values through the link. My friend Steve already has a proof of concept that he has shown me, via a console which allows him to send commands of his choosing(so long onboard computer understands the command) thru and receive info from the OBD/CAN.
If I went the second route, I could probably talk to the guy that tunes my car, an ex-lead dev for Microsoft Windows, and see how he's gone about FULLY interfacing with the E37. I mentioned the idea of putting his custom tuning suite on the carpc, he said if I later had time he would look into it. His suite even allowed for live monitoring while observing the tune.
So there are a few options available at this point. I'd personally want to go the ecm obd route for ease of use, and then use a fusion brain to determine turn signal actions and reverse gear engagement.
As for placement, I'd make a nice custom overlay to simply cover the stock gauges(removable so if something happened....). There is a lot of room within the gauge cluster cowl to stick a monitor in and not get massive glare. I was putting my HD2 up in the cluster area, it looked absolutely amazing.
my carpc doesn't update on its own. if anything, i choose when to update and what to update. that really should be the route anyone takes when updating their carpc....just like IT admins do when choosing which Windows Updates to approve etc.
Originally Posted by colin
if the carpc became so unstable that the functions of the digital speedo/tach failed, it'd be easy to simply remove the custom overlay, thus revealing the still perfectly functional stock gauges.
i recognize this project is new ground for most, as not many folks have done this. the goal is to keep the, at least the POC app, as non-bloated as possible and providing stable connectivity through an attached OBD/CAN or possibly analog interface.
the better the hardware interface the better, the newer the vehicle the better. I'm sure my bud would take a look at other subset protocol's or other protocols in general so long as there is a proper hardware interface. on an obd bus he's shown me how he can sniff commands and replicate them with response through his own console, thus allowing him to make a customizable array of commands to run.
Originally Posted by colin
the extended potentialities are there :)
i've taken a look before. while it accomplishes some goals it ignores others.
Originally Posted by hans14914
my concept route already uses a middle man approach in both getting real-time data to the dash while also providing a plethora of data accessible to other software etc. taking the simplest route possible with the least amount of tangles and allowing for bidirectional communication of the CANbus are two requirements for this. don't forget i was even talking about the idea of tuning solutions....
Thanks for your time,