Links to Virtual Instrument Cluster projects?

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

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

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.

**star-art** · 07-28-2006, 08:24 PM

Great info!

Yeah, it would be so much easier if everyone could fit a 7-inch display into their dash above the column.

Forgive me if I'm asking stuff that is too basic, but I've never coded Windows apps so I still have lots to learn about Windows hardware.

I am curious if it would be possible to create a window at a specific size which runs the gauges software, and then somehow take the contents of that window and send them to an external display device? So if you needed to run 2 or 3 small LCDs and you have the driver hardware for each, could you "dump" the contents of each window into this hardware and cause it to display just the window and nothing else?

BTW, I've been reading where a lot of people are trying to build trip computers or somehow capture fuel used data. It doesn't seem OBDII is the best way to handle this. You need to know the injector timing for your car and use that instead. If you are lucky, your ECU already puts out this info. I know Ford units do in both the EEC-IV and EEC-V models. GM ECMs also output this info. Combine this data with speed info from a VSS and you have everything you need build a complete trip computer.

**necrolyte** · 07-28-2006, 08:36 PM

Well, to be honest I'm not quite sure on the multiple window 'dumps' to smaller LCDs. It would be very neat if this is doable. I could see multiple forms being coded, one per lcd size, which you can make any size you want. However, trying to piece together a desktop with a bunch of little LCD's would be pretty technical I'm sure.

What MAY be the answer, is some type of splitter. Basically what I'm talking about is a box that takes 1 VGA input, and splits it out to say 3-4 smaller LCDs. If you had the LCD's in a square then it would draw the desktop correctly, but if you had them laid out differently, then you could just position things on your desktop where you needed them in the layout of your car. This may be very possible, then you could just draw the correct stuff in the area of your desktop that is on that certain LCD. If this makes any sense, i know it sounds confusing. Think of the big multiple monitor setups they have at bestbuy and circuit city etc on the wall. They use lots of smaller monitors to create one HUGE monitor.

I'm not too familiar up on current vehicles to get something with effiency and gas used, etc, but I'm sure there are many methods out there. You have to remember too that not all cars are fuel injected. What may be the best method is to calculate it by fuel used.

IE:
Keep up with the data that is given from the fuel tank, be it full, empty, whatever, compared to the milage you have went. Like a TRIP meter. Then you can fairly easily calculate MPG by how much you've used compared to how far you've went. It wouldnt give real time mpg, but it'd be usable.

I suggest downloading an IRC client (www.mirc.com) and coming to visit on #mp3car on an EFNET server, i can talk much faster/easier there if you want to pick my brain

**turbocad6** · 07-28-2006, 09:58 PM

I plan on putting an lcd in my cluster too, but I want to use a smaller lcd & just in the center of the cluster.... replacing the tach & speedo, but maintaining the original fuel level, oil pressure & temperature analog gauges.... I refuse to leave critical displays to the pc... just too dangerous & too much potential for problems that can turn into a real headache...

this will also look pretty factory, as mercedes, range & lamborgini do it this way, yes they use an lcd in the cluster, but this is surrounded by real gauges for the critical functions...

when I do do this, I will definatley want to have this lcd run on it's own system dedicated to just this, If I could have it done as a linux box that would be even better, just to have it work more like a component than a computer, but I know nothing about linux, so I guess it'll have to be a windows setup.....

**shotgunefx** · 07-28-2006, 10:07 PM

I've been working on this for awhile, OBDII for my car (ISO) sucks. Horrendously slow. Originally I was going to tap the gauge cluster directly and read the tach and speedo pulses directly with a microcontroller, but now there's been some headway in reverse engineering everything about the ECU for my car. Instead of datarates of 10-15 a second, people are getting 200+

I still need to get the dummy lights directly either way.

Here's a blurry old pic of the front end running (in sim mode).

And a better pic of my laptop

Where I left off was finishing the Elm32X perl module. It's almost done, I just haven't had the time to finish it off.

**mojoe01** · 07-28-2006, 10:33 PM

What a coincidence! I was just talking about doing this to my Chevy Silverado 2500HD truck on another forum...

http://www.dieselplace.com/forum/sho...9&postcount=55

My plans were almost the same as yours: Put two 7" LCDs over top of the existing cluster and using VB, write software to do my own custom instrumentation. I was going to tap into the Class II (VPW) line of my vehicle and use the existing serial data bus traffic to extract the gage information. It is already there, currently driving the gauges, and it is updated multiple times per second. That way, I wouldn't need to use diagnostic OBDII messages, which would be a lot slower. As far as the critical gauges and driver warnings, they are also already driven by serial messages. I was going to leave my existing cluster mounted and working underneath the LCD displays, so I don't violate any Federal odometer regulations.

I must say though, I really like the idea of creating a combo instrument cluster, with a single LCD screen and conventional analog gauges around. I'm not so sure now which idea to use...

On the other forum, this topic was born out of an idea to display custom messages on the DIC (driver information center), which is already in the cluster on the GM trucks. A carputer would have all kinds of extra information that could be displayed on a custom instrument cluster. Lets keep these ideas going...