Interacting with Onboard Car Computers?

joshmccormack asks: "I've seen lots of projects where people are making great looking computers that fit into the dashboard of their cars that play MP3s, movies and even some that do some GPS and mapping stuff. I'd love to find projects where computers connect with the on board computers in most cars from the mid 90s on to show temperature and performance of various parts of the car. There are diagnostic tools that mechanics use, and that you can get to get data, but I'm particularly interested in real time, in-dash, open source options."

Comments

Similar to TEC

[b00m3rang]

Electromotive systems makes a system called T.E.C. (Total Engine Control) that performs the functions you're looking for and much, much more. Although with this setup, you don't interface with the car's computer but replace it entirely. It allows you to control fuel curves, ignition advance, turbo boost, and pretty much any function of the engine to your exact specifications.

Maybe it's time to start developing OpenTEC?

Obstacles

[The Clockwork Troll]

One of the nice side effects of emissions legislation in the past 10 years is that all cars since 1996 are required to have an on-board diagnostics port to which standard tools can connect and report on the vehicle's various operating parameters (ignition timing advance, manifold pressure/mass air flow, various temperatures).

On OBD-II equipped vehicles, the port is typically located to the right of the steering wheel in the driver's side footwell. It is trapezoidal.

There are many systems available for reading this information, from scan tools to computer interfaces.

It sounds like what you want is something like the PSI data display unit (DIN-sized). These connect up to OBD-II enabled cars.

The big problem you may run into is that the OBD-II standard requires only that the most basic parameters be reported to scan tools. Manufacturers are notorious for obscuring the most interesting information and it's typically been up to enthusiasts to reverse engineer manufacturers' proprietary additions to the OBD-II protocol.

Oligopoly

[ADRA]

I don't think any car company release their onboard computer protocols. They could be running RS232 or 10baseT for all we know.

Best chance for you is to wire into the analog sensors that they are using!

Re:Oligopoly

[Smidge204]

Except that would:

1) Probably break the car's computer system, which relies on the proper function of those sensors

2) Require you to understand how each sensor operates (Which I'm sure are equally undocumented)

3) Build your own interface circuitry

4) Do your own calibration and correction

5) Understand what the sensors tell you, and how to deduce the status of the vehicle from them

The onboard computer does all that. All you need to do is ask it what's going on.

At least the hookup is designed for car/computer communications. It would be easier to reverse engineer one access point and protocol than to hack together a complete, seperate system that doesn't break the existing one (which would kill the car). Especially since there is some documentation on it, and equipment that is designed to interface with it is available. (Very expensive though - got any buddies who work in a repair shop?)
=Smidge=

Do I know what I am talking about?

[XBL]

I think people who develop software/hardware for doing auto stuff have to pay licensing fees and junk like that. And I think that stuff is also limited to dealers for the high-end stuff. GM Goodwrench has priority over Greasemonkey Auto for the good stuff, and that priority probably come with how much $ you have to pay to GM or whoever.

A lot of the auto mechanics shops just have error code readers, with the capability to disable the error codes. That is all they need pretty much.

I also bet that most car computers dont have the output capabilities that you desire. Probably you would have to use a whole custom computer from a 3rd party. Those are probably expensive too.

Here's an old site

[Howard Beale]

but may be of some value:

http://www.knightrideronline.com/

Ask for 'Michael'.

Delta Dash

[GeorgeH]

I'm planning on building one of these computers over the summer (what? A slashdot poster with grand plans in a nebulous phase of completion? Never have I heard of such a thing!) based on information over at the mp3car.com forums. You should especially check out the OBD-II forum, which is addressing your specific question.

Personally, I'm going to just buy (now a slashdotter is going to buy software? A sign of the apocolypse!) Delta Dash because it is supposedly great with my WRX.

Well sourceforge to the rescue

[pbox]

Have you actually tried

a. Google
b. SourceForge
c. neither

And the correct answer is c.
While a. or b. would be even correcter!

freediag that I have found on sourceforge which I have googled with "open source obdii".
---

Re:Well sourceforge to the rescue

[xoran99]

Then again, how are you supposed to google it if you don't even know what the freaking thing is called?? That's why human communities are so effective, even though almost everything can be found through google.

Specialty shops do this now

[chaotica1974]

A lot of the specifics you are looking for are probably already done by a speciality shop. For example, I love my Camaro Z28, and ls1edit.com has a $500 setup that will tell me everything about the car in real time.


I doubt though that car manufacturers are going to standardize on anything electric except the emmissions part, and that's probably the goverment forcing them to. Geez, take a look at aftermarket radios, If they could standardize on anything it could be that.


Now, if someone *would* build a custom touch screen LCD screen that fit perfectly where my radio and environmental controls are and then made it open enough I could plug a laptop into it (MP3s, Maps, etc..) then I would be one happy camper. Of course, it would have to be skinnable (for my mood) and environmental controls would have to be included in the touch screen LCD. Well hell, just include the lights, wipers, hazards, defogger, yadda yadda ya.


Hmmmm, I should get to work on that now. To the patent office! First comez za money, then comes zee power. Bwooo ha ha ha ha.

Cheap Code reading tool

[eakerin]

I bought an OBD2 interface board from scantool.net works pretty well, pretty easy interface protocol.

I wrote up some functions to grab different data from the box, and drop it in a struct for later processing. I also wrote up another function to handle the later processing and give you the raw value. Pretty simple code really.

The only problem I ran into (which was the kicker for me), I was only able to get about 3 samples per second from my Jeep's computer...Hardly fast enough for a realtime display of all the normal dashboard information, but cool none-the less.

Maybe I'll zip up the code I wrote and post it on the net, now that it's getting warmer I might be interested in spending some time on it.

freediag

[austad]

Your ECU has most of the info you want. Pull it with FreeDiag and output it to the display of your liking.

Make something neat so I can use it too. Your car needs to be OBDII compliant to use it, most (all?) recent cars are.

dashpc.com

[bergeron76]

It's been seen on here a few times, but it's currently the best linux-based open-source car computer website. It has OBDII compatibility via a FreeDiag driver. The software has been slow in development, but lately things have been picking up quite nicely.

http://www.dashpc.com has all the juicy details about how to build your own DashboardPC and how to interface with your car via your PC.

megasquirt

[Stinson]

another build it your self ecu would be Megasquirt [http://www.bgsoflex.com/megasquirt.html]. Otherwise, i'd suggest just reading the input from all the sensors, they're pretty easy to interface, just make sure all your circuits are designed properly so you don't burn anything out. +Temperature sensor: resistance changes with temp, higher the resistance, the colder it is (not all are like this). Example, on my Saab, 1000 ohms is about 8 degrees F. +O2 sensor: if you want to know the fuel/air mixture, the output from the O2 sensor normally ranges from 0-4 volts. Figuring out timing and dwell is a bit harder, requiring crankshaft position sensor, and knowing the current rpms of the shaft. Most automotive books for your car will describe the various sensors, and their outputs.

Here ya go

[YrWrstNtmr]

I'm designing something similar for my truck.

Inexpensive Free software for Win or Mac. Inexpensive cable.
Expensive. Very pro display, and you can get all the extended codes sets.
Opensource(you still need to build/buy the cable)

There are others out there. Google for obdii

All you need do is hook this up to the serial port of whatever car PC you make, and run the s/w. Presto, virtual dashboard, with more readings than you will ever use.

Friend of mine at work has the cheaper one, and it works quite well. You can even record a drive, and play it back later. Output to OO.org or excel compatible csv for further analysis.

Interaction with computers while driving

[merlin_jim]

I tried this sort of thing. EPIA under seat, hooked into the car audio and video system (5" on-dash LCD)... custom harness to interact with the in-car computer. Luckily the busses are serial, so a regular serial port or a hacked hi-speed parallel port can interface...

A couple observations:

1. The interface should not be mouse driven no matter what. You need buttons. Buttons are BETTER than a touch screen in this case.

2. A numpad can be used for interface, but a serial module with built in buttons or some other contraption would be better.

3. Very few commercial programs are suitable to this interface method. Expect to do some heavy lifting in code to pass the girlfriend test. The girlfriend test is the same one I have for MythTV. If she sits down with no instruction, does this gadget improve the experience, or at least not degrade it in any way?

4. Audible interface is nice. You need a music pass through for a regular CD player, on top of whatever lossy compression you're using to store music. Any type of audible, no-eyes-off-the-road notifications are great. A good text reader would be even better but I doubt you could get it to work well enough.

5. Forget speech recognition. It's still just barely good enough to be acceptable in a lab environment. Road noise will completely kill any chance you have of running it in your car.

6. Certain applications should not be used while driving. No, not even stuck in traffic. Ideally, if the car is in drive, they will simply be unavailable. E-mail is a maybe. Video playback is a maybe. Any program requiring more than three or four buttons to operate should be avoided while driving.