Links to Virtual Instrument Cluster projects?

star-art · 07-28-2006, 02:50 AM

I've been pouring through dozens and dozens of posts and finding almost nothing on this subject. I'm not sure what the current terminology is for this sort of thing:

Virtual Instrument Cluster
Virtual Cluster
Virtual Guages

etc.

I am NOT talking about OBD-II diagnostics or any software run in diagnostic mode. Instead, I mean full time, software-based gauges running on one or more small LCD displays to replace your existing mechanical or VFD cluster. Since much of the data needed for a virtual instrument cluster is available from the OBD-II interface I thought this would be a good place to pose this question.

It seems many people are interested in this subject and would love to build their own software-based cluster, but the technology has not quite caught up to the concept. I envisioned a reconfigurable, software based system way back in 1991 and did my college engineering project on this concept, but it was just a pipe dream back then. The technology today, however, seems to almost be there to make this a reality.

Many companies and individuals have been researching proprietary solutions for years. Embedded apps are most often based on C and require a lot of effort to program the graphics. All this to save memory and make an app with a very small footprint so it can run efficiently on the cheapest possible hardware. But all that ceases to be a concern if a full-blown PC is running a Windows-based app, and with the advent of Car PCs this is now possible.

I am interested in developing a gauge application that can be built in VB.NET, perhaps open source, with graphics generated in Flash. This gives the most flexibility and ease of customization. The challenges remaining today are the need for "instant on" capability, reliable performance (if it hangs or crashes while driving, that's not very safe!), and the need to drive two or three small displays to fit in the small space available in most dashboards. A regular full VGA or XGA display simply won't fit around a steering column in today's cars.

For sure we won't be seeing anything like this from any major companies. All they want is something proprietary so they can make a buck. But seeing what folks here are doing with front ends, HVAC/radio/phone integration, and GPS, it seems we enthusiasts have the spirit to make something like this work!

So, are there any websites out there already devoted to this subject? Has anyone had success with this type of project? I'd love to talk to folks who have done it or want to do this. I've done a lot of research for many years as well as quite a bit of design work and I have a pretty good idea how such a system might be built. I'd love some pointers to existing sites or projects so I don't have to completely reinvent the wheel.

So, is there anything out there like this today?

Thanks!!

meddler · 07-28-2006, 03:00 AM

You might want to talk to Necrolyte on the IRC channel #mp3car on EFnet. He is doing exactly what you are talking about. I have seen some of his work and it looks awesome.

star-art · 07-28-2006, 03:05 AM

Cool, thanks! Unfortunately I don't do IRC or IM -- I just read the boards and send e-mail. Does he post here on the forums?

Thanks!

meddler · 07-28-2006, 03:07 AM

I'm not sure if he posts or not. I can definately point him to this thread when I talk to him next.

Still the best be would be for you to talk to him yourself.

wi77iam · 07-28-2006, 06:34 AM

There are already quite a few programs for doing this. Google on "obd virtual dash".

Here are some:
DeltaDash by ecutek
PCMSCAN
Obd-2 scantool

Most obd dataloggers come with a program that provides some kind of dashboard dial display for obd data. Most provide dials that look good on a 7 inch indash display. This is easier to do than having lots of small lcds.

necrolyte · 07-28-2006, 06:46 AM

Yep, I post, and I'm here

star-art: What I'm currently doing is build a new system for my Kitcar, its based on an old VW Beetle, with the air cooled motor (pre 70's). Obviously this car has no OBD configuration or computer to grab data from, so all of my hardware is being configured and custom made. We're using sending units from Dakota Digital, and feeding them into some hardware to input through the parallel port. This will allow me to grab data and calculate etc to display on my digital gauge panel.

What I have so far, is a digital panel coded in vb6, using directx8. It WILL be skinnable, for multiple resolutions and applications. I'm waiting on the first skin to come back from a graphic artist friend with the skin.ini file so I can base the code off that.

So far though, I do have digital gauges displayed on dual monitors (1280x480) with no skins, however the program is at a point where it could be reconfigured to mask in OBD-II as well. I actually have an OBDii device I could probably work in, as I use it in my Ranger with my carPC.

Here is a couple of screenshots:
http://mobilecpu.net:8080/installs/i...ftware/ss4.png
http://mobilecpu.net:8080/installs/i...ftware/ss5.png

Where the program currently stands, I can share with you guys. Once I build all of the hardware and release a full version, Dakota Digital is interested in buying the package, so I can't release that.

Let me know! Thanks for the interest

red_parchel · 07-28-2006, 08:13 AM

necrolyte, awesome work, that looks really good [very 31337] if it can/will be "ported" to use the obdii interface i would certainally [along with MANY others] be interested in the program .. and the dual screen idea is great, that way you could span them across 2 7"lcds to replace your cluser and still be able to read it if you wanted

meddler · 07-28-2006, 08:18 AM

Quote: Originally Posted by red_parchel

you could span them across 2 7"lcds to replace your cluser and still be able to read it if you wanted

that is his plan.

star-art · 07-28-2006, 12:52 PM

Glad to see someone working on this!

I knew some projects had to be out there. I have seen the OBDII programs and they are not what I had in mind at all.

It sounds like you are having to build quite a bit of hardware to make this work which is not surprising. If you are spanning two 7-inch displays, are you doing this by invoking the Windows multiple monitor support? How fast can your system boot to get your cluster working?

I think the software side of all this will be the easiest hurdle to overcome once a platform has been selected. With VB it is not as hard as coding in native C. With VB + Flash it gets even easier. I am both an artist and an engineer so I can create graphics and the programming is fun for me at the same time.

Unfortunately, I can't use huge 7-inch displays. There simply isn't room in the instrument cluster area. If you factor in the steering column and wheel, you are left with somewhat of a "U-shaped" viewing area that must wrap around the column. The only way to fill this area and maximize available space is to use three small LCD displays, each running less than 640 X 480. It seems like this will require some sort of special hardware configuration. At this point I have no idea how to drive them.

Things would certainly get easier by using larger displays! But how many people out there could actually install those in their vehicles?

Mcnovy · 07-28-2006, 02:02 PM

but does the obdII speedo's work real time, or are they updated like every second or something like that..?

star-art · 07-28-2006, 02:27 PM

I've heard people complain about "bottlenecking" in the OBDII feed, but others have said the data acquisition rate is not a problem.

Obviously, getting the data from the OBDII connection should be the easiest route. But how can you "plug into" this full time while still making the connector available to run diagnostics? In other words, how can you "tap" the data full time and still be able to plug in or use another tool for diagnosis? Since there is only one connection, is some sort of "pass through" adapter available?

RE: Speed readout. You can get this directly without going through the OBDII interface. Most vehicles have some sort of speed sensor. In GM and Ford cars, for example, this attaches either to the speedometer (using an IR sensor) or to the transmission (using a Hall-effect sensor IIRC). This sensor generates "pulses" which are fed to the ECU. Later models couple the sensor directly to the ECU which then relays these pulses to the speedometer in the cluster.

If you know how your vehicle is wired, you can get a speed signal somewhere. On older GM cars, for example, you would simply hook up to the VSS output which is either 2000 or 4000 pulses per mile, depending on the model. On newer cars you would tap the output from the ECU which goes into the speedometer cluster (both analog and digital clusters both have this input). As long as you know how many pulses per mile, your software can use that info to display the speed and the mileage!

Fuel used is similar. Ford vehicles with a trip computer get a pulsed feed from the ECU which tells the cluster how many gallons of gas have been used. I actually got the specs from Ford many years ago. It's so many pulses per gallon. You can use that to make your own trip computer and track instant and average fuel economy as well as distance to destination!

IIRC, older GM cars send injector pulse width information to their clusters and trip computers via the serial data line. I don't know if this is a "pulses per gallon" type of signal or just the actual time the injectors are turned on. If it's the latter, you would need to know the flow rate of your injectors to calculate fuel used. If an injector flows a certain amount per millisecond, then the "injector on time" in milliseconds will tell you how much fuel has been used.

joeyoravec · 07-28-2006, 02:48 PM

Quote: Originally Posted by star-art

Obviously, getting the data from the OBDII connection should be the easiest route. But how can you "plug into" this full time while still making the connector available to run diagnostics? In other words, how can you "tap" the data full time and still be able to plug in or use another tool for diagnosis? Since there is only one connection, is some sort of "pass through" adapter available?

OBD-II is a network and multiple nodes are allowed. DrewTech sells a 2-way splitter. You could accomplish the same thing yourself with several hours of soldering. You'd still need to ensure that your scantools aren't trying to use the same tester address, but most networks have 8 reserved addresses available. As long as you program things correctly it's possible to connect multiple tools simultaneously.

star-art · 07-28-2006, 05:33 PM

Thanks!!

RE: Speedo input I'm a bit rusty on some of the particulars since I haven't worked on my cars in a while due to back problems (yes, I'm getting to be an old timer!

) I found this page which discusses the signals coming from most vehicle speed sensors:

http://www.magsensors.com/vssapps.html

The VSS on my Fords, for example, is a Hall effect sensor which produces a digital pulse waveform. Each pulse is the same voltage, only the frequency varies with vehicle speed. All you need to do is count these pulses to get the mileage travelled, and count pulses per time to get the correct speed. I would recommend tapping this input directly for any speedometer application and getting other info like tach readouts from the ECU via OBDII.

SnyperBob · 07-28-2006, 05:50 PM

Quote:

http://www.magsensors.com/vssapps.html

Haha, my Ford Aspire is on that list!

necrolyte · 07-28-2006, 07:57 PM

Actually, like many have posted, the OBDii is fairly quick. The only problem becomes when you are trying to read multiple variables on the ECU side. Then it becomes a bottleneck.

With the software I'm working on, yes, it will span two 7" monitors, and I'll have a third monitor for my desktop space/frontend whatever, and I am using the multiple monitor stuff through windows, with 2 seperate video cards right now. My next option is buying a dual output card, along with onboard vga, to see if i can get three monitors going. My car is custom, so I'm able to do this behind the steering wheel. I agree that in most cars it would not be easy to be able to get this to work. More research should go into LCD's that span 3-4", and that could be coupled with some of the VGA boards out there (www.earthlcd.com)

My software is also skinnable to 1 screen, or multiple screens. However many you have, you just have to write the skin correctly. I will release a slim version so you guys can do what you want with the graphic/skin side once I get the first skin coded in.

Yes, my hardware is extensive because of the uniqueness of this in an older model and VERY custom vehicle. An OBDii wrapper I could easily code to this once I get the skins finished up. I have the source to the more popular http://www.obddiagnostics.com/ so it would probably be based around this.

The main things in the skin, that you have to remember to do, are the max/mins of the gauges, and the angle of the increment of whatever you're doing. So that the program knows the minimum and maximum angle of your numbers, and the increment to calculate the distance and locations of the rest. All of this is hardcoded to read in variables.

If you check out Dakota Digital (www.dakotadigital.com), they sell an 8k pulse sending unit for tach/speedo. This basically says it does 8000 pulses per mile, depending on tire size etc. There are ways to configure it. This would be the easiest hardware solution to bypass the obdii port. 8k pulses is about the normal for most cars.

As for the coding of my app, I chose VB as I know it inside and out, I'm just having to learn DirectX 8, which is mostly Direct3D. This code can be ported to C, VB.NET and many others pretty easily.

Also another option to your 'smaller than 640x480' res problem, could be to switch back into old DOS, it has a Screen 13, or 13h which is 320x200 IIRC. I used to code this with sidescrolls and RPG type games back in the day. Though its only 256 colors, so you'd have to be picky with your graphics. I can get Windows to boot in about 15 seconds normally, but again, with a custom car, who cares? Its not a daily driver, but for you guys, faster = better.

I tell you something too, using something like MediaEngine, which can load over the default windows shell, makes booting a hella lot faster as well. If something like this could be incorperated, or even run at boot without loading the default windows kernal, it would boot a lot faster as well.