I could write a tool that would feed the application data so it made it look like it was pulling from the obd2 port. The plus side is you could get some bad *** horsepower readings out of it. The down side is it would all be fake.
I love this idea, but I have one thing to add. It's just my 2 cents worth, but I think you should license the system to Dakota Digital instead of selling. Go through the legalities and get a lawyer to handle it. I would hate to see something like Linux turn into something like MS.
Anyway, I LOVE this idea and would like to see it continue to evolve.
hey, lets see some pics of that screen in your das ins. cluster. done yet?
I like Necrolyte's display :-). Is it your own code ?. I want to do something similar for the twin diesels in my boat. I have an industrial adc unit(Datascan 7320), which, at 16, should have enough inputs for the job !. Does anyone know of source code, or configurable application that will run on Linux ?
In response to turbocad6's concerns, the most likely bit to fail is the sensor, rather than the computer. At least the computer(if sensible programmed) will let you know that there is a fault. Most electronic interfaces will include a "sensor fault" detection, and the program should indicate this state.
I just love necrolyte's setup. Now, if it could run on Linux .......... Where are you on it now ?. If there is anything I am likely to be able to do to help, in return for getting access to what you have done, let me know. I am an electronics engineer, with quite a few years on microcontrollers.
For "splitting" displays, there are systems used for "video wall" setups which do that. What the technology is, I don't know.
I am busy with something similar, will run 3x6" displays, or 2x 7" Xenarcs to display everything I want to.
Below is a sample of a setup I have designed, basically playing, there's so many options, but this is just an idea of what I am planning for the virtual cluster.
I will add the FPV logo to the main gauges, and most likely overlay GPS inside the speedo unit, so that only the edge of the pointer will be visible once in GPS mode.
Well, there is really so many possibilities with a virtual cluster, it's up to your imagination.
Let me know what you guys think of my first effort. See my project log link in my sig to see the vehicle they will go into
It might we worth looking at this thread which has similar content.
Computer Controlled Guages
It shows a couple of early screens for my race car taken last year.
Regards gauge update times - I found that for numeric values anything more than 0.5 seconds is pointless as you can't "decode" the information fast enough. If you need faster updates than use some sort of graphical display - even then I find that updates more often than 0.2s just become noisy. Also make sure all gauges support flexible damping / smoothing / filtering algorithms (I use all 3 for different gauges) again this helps reduce noisy fluctuations around a base point.
Take for example, my "curved" rpm gauge, each bar segment is 100 rpm and it updates 5 times a second, I also now show rpm rounded to the nearest 20 rpm (not shown).
For my actual race screens, I only show RPM, speed - more for the benefit of in-car camera than me to watch (I use shift light reflections on the windscreen to determine gear shift). The only race specific gauge shown is stopwatch (autostarts when the wheels start moving and stop when the course length is reached) and a BIG segment bar showing the amount of time I am up (green) or down (red) on my best course time. Anything else of importance is flashed up in an alarm window and logged for posterity.
The only other felixible and costly commerical systems I have seen are the ones from Cougar Data Recording www.cougardatarecording.co.uk and X-Dash from http://www.dtafast.co.uk/XDash.htm.
Thanx for the input, and your link - looks like a good project you have going.
I see you mentioned in your log that OBD is slow?
My car's netowk is running the CANbus protocol, which is is fully OBD-II compliant, and the datarate is 500kbits, so no problem there.
Of course, some older busses like the ISO protocol is a fair bit slower.....
I will keep your advice re damping etc in hand, thanx
My race car isn't running an OBD2 device but luckily the ECU and data logger spew out data more than fast enough
I have diagnostic pages for each device which simply shows all raw data received from that device in numerical form at least 5 times a second, usually to a greater degree of accuracy than I ever show.
One other thing, when developing on a nice fast desktop PC at 3GHz, lots of ram and fast graphics card, its a world away from running on the target hardware (in my case a M12000, on board video and 512 MB RAM. I have had to spend a lot of time optimising the instrument graphics especially the painting of the dial and bar gauges. To aid in this I have several internal data channels which include various redraw times and CPU usage.