Virtual gauges for my new Challenger

I need some help with a new project. I want to replace the gauges in my new Dodge Challenger with computer generated ones. I am planning on using an embedded Linux device connected to Three 6" (or so) OLED screens. I have been able to find the hardware I need but I can't seem to find the software. I will need some thing to interpret the information from the car and some thing to let me translate that into a virtual gauge for each of the three screens. I would also like it if the program would make it easy to design skins (or just the world... which ever).

Any help would be appreciated.

Essentially you would need to be able to read data from the ECU. You are looking for OBD2 software, unfortunately you won't find much open source stuff for linux:

http://www.mp3car.com/vbulletin/linu...tive-wine.html

Not true! Take a look at OBD2GPS logger in our OBDII forum. Linux, open source, fully accessible programmatically. That's what you need to read the data.

It will run on a device like a Sheeva Plug which can be converted to operate on automotive power and has a USB port on it.

Pair it with an OBDII reader (check the ScanTool forum for some info) and you'll have an interface with the car.

Consider doing a worklog of how you do this with OLED screens! I'd like to follow how to do this myself and lots of people come here looking for a way to do virtual gauges. Your project is unique because you will use separate OLED screens to do it.

for a digital dash, you probably won't want OBD data. It's not fast enough. you'll probably want to interface directly with the proprietary messages in your system. The cool thing is, OBDGPSLogger is freedable, so you can still use that, just seed it with the data from a plugin that reads from the ECU/CAN Bus.

To be fair, OBDII in modern [CAN] cars is sufficiently zippy that a digital dash is actually feasible.

Out of the box, I get 20+ samples per second with either of my USB dongles. That's completely-without-clever-optimisation. With a few pretty small optimisations I think I can double that, probably more [I have heard "60 samples per second" bandied about from a couple guys, but I haven't verified that myself].

If all you record is vehicle speed and rpm, it's a tenth of a second between samples; an animated dial would mean you never know the difference. And really, RPM and vss is all that my mini offers me on the dials in its normal form. At least, they're certainly the only two dials I ever look at :-)

I'm looking at how to effectively change things to log on the fly, and some ideas have been coming to me. If it's the difference that means someone will actually use my stuff, I'd move that up the queue of things I'm implementing [as kev000 will verify :-D]

Gary (-;

Quote:

---

Originally Posted by kev000

for a digital dash, you probably won't want OBD data. It's not fast enough. you'll probably want to interface directly with the proprietary messages in your system. The cool thing is, OBDGPSLogger is freedable, so you can still use that, just seed it with the data from a plugin that reads from the ECU/CAN Bus.

---

If your grabbing data from the can bus why would you even need obdgpslogger? Write your own plugin and thats it...

Quote:

---

If your grabbing data from the can bus why would you even need obdgpslogger? Write your own plugin and thats it...

---

Mainly because obdgpslogger does a lot of the hard work for you, and it's a lot easier to write something pretty that listens for dbus signals than it is to interface with serial stuff, parse the data, deal with errors, that kind of thing.

Of course, I may be slightly biased.

Gary (-;

I really appreciate all of your posts, even with the limit time my questions has been up you have provided me with some thing very important that I did not have, a starting point.

I have looked at some of the links and software you mentioned, I am very interested in the hardware and software offered by ScanTool.net. Although I do not like the idea of a non open source option (or the idea of paying for it), it looks like it will do much of what I will need it to do. It does not mention system requirements or if it will allow for multiple screens. Even if I decide to use it, I will still need to have drivers for the OLEDs and I don't think getting it all to work together will be as easy as downloading the newest version of Java.

I would appreciate any input concerning using the ScanTool.net products and if there is a better option. Pros and cons, advantages of other options, why your option will make me look cooler... Anything you think is pertinent or constructive.

I am fully willing to use a less main stream option, as long as it will take less effort to develop and implement as the invention of Tang.

Quote:

---

Originally Posted by chunkyks

Mainly because obdgpslogger does a lot of the hard work for you, and it's a lot easier to write something pretty that listens for dbus signals than it is to interface with serial stuff, parse the data, deal with errors, that kind of thing.

Of course, I may be slightly biased.

Gary (-;

---

Psshhh... real men right their own CAN Bus reader... And their own kernels. you wuss! :P