Probably OT, ADC and PCs

[Jacampb2]

I couldn't really decide where the best fit for this thread was, but I guess this is close enough.

This is actually car audio related, but it is way outside the scope of car audio... I am building a car PC for my project vehicle. For some time, the idea has stuck in my head that I would like to do a "virtual instrument cluster" driven by the car pc. I would install a LCD in place of the dash cluster, and ideally have the PC sample the analog inputs and display the data on virtual gauges that could be skinned and moved to my liking, also, possibly minimized to a ticker type display to allow video to be displayed in the LOS.

I have looked high and low online for any similar products or ideas. I am coming up with squat. It seems that most of the data necessary could be sampled via parallel port, with no usb or serial interface necessary. How difficult will the actual application programming be? I get the basic idea as to how "skins" are made for applications, but I have no idea where to even start in writing an application that will sample analog data and drive any sort of display, a text readout, or a virtual analog gauge.

Is this something that could be pulled off in a low level language? I have a lot of experience with the old BASIC, I imagine I would pick VB fairly easily. I have limited experience with C+ due to some tinkering with PIC's.

Does anyone know of any online sources to get me started. Any kind of analog sampling and display on the PC, it does not have to be mobile related.

TIA,
Jason

[fuzzysnuggleduck]

First of all, I love your idea.

Now for the meat...

Yes, you could do it in a low level language. Neither BASIC or VB are considered low level though. Low level usually refers to assembly. VB is pretty high level.

I would suggest a robust language like C, C++ or possibly Java if you can make good use of the built-in classes.

You're a pretty technical guy, if you understand both analog and digital circuits, you will likely be able to pickup programming, even low level quite quickly.

People say assembly is hard. I tried a bit myself but never was competent enough to do anything useful with it.. but I'm not a math mind programmer either, so I forgive myself. You can also embed asm into C or C++ code (dunno about Java, doubtful consider it runs in a VM)

You're looking at a couple different things here... one grabbing the data from whatever OBDII or analog instruments and the second is designing and programming a real time interface (GUI, pretty much) to display the data.

From the data gathering point of view, you might be able to pickup a USB OBDII reader and have all the data available to you programmatically (if the product publishes APIs), or just use the analog instruments and come up with a way to read their data through your parallel port.

From the GUI point of view, I would suggest looking into various available widget toolkits that draw all kinds of controls for you making the whole development process much easier. It does depend on how custom you want to go however.

Tom should be able to help quite a bit, he's a Java developer by trade.

Edit: I'm saying OBDII because I assumed it's a modern vehicle. Perhaps that is not the case.

[Jacampb2]

Well, I stand corrected. I was under the impression that a "low level" language alluded to the complexity. I did some reading about assembly when I started teaching myself about PICs. It is difficult for me to understand as well.

Java is interesting, but I have absolutely no experience with it. I may have to learn.

The vehicle is not OBDII. Something similar to what I would like to do exists for OBDII. I want to poll the data straight from the analog sensors and use that. I know how each and every sensor works. 99% of them are simple variable resistive dividers with a 5v or 12v reference. The vehicle is new enough to have a VSS (vehicle speed sensor) for the feed to speedometer and odometer. It puts out 8000 pulses per mile, that should be fairly straight forward using a frequency to voltage converter, or possibly by buffering the signal and reading the pulse train directly. Similar for tachometer output. A Frequency to voltage IC would handle it easily. Resistive sensors could be polled and voltage correlated to a certain reading, obviously it would require some mapping to calibrate.

I know this is not a incredibly complex project, neither in hardware nor software. It blows my mind that there is so little out there. I found some "race pack" type stand alone systems, price ranging from about $700-$5000. That is retarded for the technology involved. Some of the OBDII interface setups to allow real time code reading and other things can display virtual instruments, and at a much lower price point, but I am not OBDII, and in all actuality, when the final motor build is done, I won't even have a factory ECM...

I will wait for more input, but once I have some solid recommendations on a language to use, I will pick up some books and try to start learning.

Thanks,
Jason

[Rold Gold]

Don't they have a display that plugs into the lighter than can tell how fast yer goin and rpm levels and even 1/4 mile runs.. Maybe I'm dreamin.......

But this may be a start...........or template........

You could monitor justa bout everything possible....speed, voltage, front/mid/rear oil temp, BOOST, exhaust temp, turbo temp.........
But yer thinking abit less windows 98.........as am I........

[fuzzysnuggleduck]

Sounds like you have the instruments reading portion of this plan down very well. Your understanding of that is much greater than mine.

As far as programming goes, you'll do well learning pretty much anything.

Since the graphical interface is a very big portion of this, I would lean towards using a language with an available widget toolkit that most closely matches your vision. Since you're looking for "skinning", that will be an important part of which widget toolkits you'll be looking at.

Look at this list

If you're going to be running this on a Car PC with a decent GPU, you could use OpenGL (or DirectX, I suppose) to draw your interface.

Agar looks pretty cool. Even works on older framebuffer devices.

Since you can use Agar in Perl, you might be able to quickly prototype your code in Perl and if you find you need more speed, do a rewrite in C.

[Jacampb2]

They have some plug in stuff that uses an accelerometer to extrapolate various things over a known time frame. Good for use at the track, but if we are thinking about the same "boxes" then there is no speed/RPM or any other type of real data. They guesstimate based on accelerometer data and a certain track length. So, in day to day driving, they can only display things like g-force, maybe pitch and yaw.

In the end, with a PC based setup, you are only limited by the number of inputs you can bring to the machine and the software. I only want fairly routine stuff, but you'd think the ricers would be all over something like this.

Later,
Jason

[stipud]

Not much time to read through this thread... but the base idea is actually pretty common, and I have seen it implemented in a few cars. There's actually a lot of datalogging/OBD/gauge software built for in-car PCs. The only difference between your idea and theirs would be using your gauge cluster as a screen, versus a smaller double-din screen or similar.

My only concern with replacing the gauge cluster is visibility. It's very hard to see LCDs, if the sun hits them at the wrong angle. Most gauge clusters are fortunately hidden under a shroud, but there may still be issues at certain angles.

I would start checking around at mp3car.com for similar installs... that is THE forum for Car PC's, and there are lots of tuners there running various apps over OBD, etc. Now doing this on a non-OBD car will be a LOT more work, since you will have to build custom probes for all your sensor. Not even sure where to start with that one... it would probably take years and lots of money!

[Jacampb2]

The truck is actually OBDI, but it makes little difference, as OBDII was the first interface to actually handle most of the instrument data. With the exception of some of the "bus" type instrument interfaces and most of the new generations (after 2k)of PCM/ECM, even OBDII doesn't keep track of some of the variables.

I don't think visibility will be a huge hurdle. The truck has a pretty deep baffle/shroud, and there are some good displays available.

Unfortunately, I cannot visit mp3car from work, unless I use an anonymiser. The MP3 in the URL triggers the babysitter. I need to find someone who is well versed in instrumentation and control. There are some techies here at work who may be willing to help me, at least to get a broad grasp on things, but you are right, it will take a lot of time for sure.

I really think it is a sweet idea though. My original was to try to do some kind of HUD on the windshield, but it turns out that learning about optics and all of the voodoo involved with that is waaaaaaay more complex than most stuff I think about tackling...

[Jacampb2]

A quick update:

I have decided to teach myself Java. Interesting language. Reminds me a lot of C++ but for some reason it is easier, but still a lot the same.

I started looking at using a Audrino board to interface, it is similar to a PIC or BASIC stamp, but a bit more advanced. It would have meant familiarizing myself with another language though, and there really is no need for a micro since I am going to display everything with a PC and not a stand alone display.

This led me back to PP, Serial, or USB interface. Juries still out on interface. PP looks very tempting. There are enough inputs, it is easily interfaced with with software, and all I need for supporting electronics is a ADC, several are available specifically for interfacing with the PP. USB is likely a mess, serial is another lucrative option, been around for long enough that there is a lot of info on home brew interfaces...

So, I will let you all know when I think I have an handle on java. I will probably be asking questions of the more knowledgeable, and once I get to the pertinent coding, I will probably be looking for help in reviewing things as well.

Later,
Jason