Slashdot Mirror
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."
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?
It appears that the new version does allow you to interface with the vehicle's computer to retrieve diagnostic codes, but I'm not sure of the level of integration possible.
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.
There are no karma whores, only moderation johns
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!
Bye!
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.
but may be of some value:
http://www.knightrideronline.com/
Ask for 'Michael'.
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.
Why can't I moderate something "Wrong" or at least "Grossly Misinformed"?
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".
---
Code poet, espresso fiend, starter upper.
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.
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.
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.
Need Free Juniper/NetScreen Support? JuniperForum
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.
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
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.
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.
The code readings are standard, and well known. Each manufacturer also has extended code sets, but they are not magic. $100-$300 will tell you more about your car than you will ever care know.
One of the cooler products that I've seen that integrates with the onboard computer is this module with integrates a Valentine 1 radar detector with the onboard computer. Very slick and I'd buy one in an instant if it was available for the OBC on my car.
With alot of manufacturers switching to the MOST bus, I think we'll see more integration like this in the future and it would be cool if someone created a simple interface so that we could write our own apps to be displayed in the car.
------
Objects in Mirror are Losing!
AutoXray (www.autoxray.com) has a pretty good selection of code scanners and data loggers. Covers most makes since OBD-II was required (96). Previous comment was right in that not all parameters will be able to be scanned on all platforms. But what you mentioned, coolant temp, etc (basic engine parameters) *should* be part of the standard protocol. Also, the protocol is not RS-232 or ethernet - it carries some SAE spec J-something or other. I have an Autotap for my 96 Pontiac Trans Am - there is a microcontroller in a dongle that converts the car's datastrean into RS-232.
Build yourself a little analog digital converter board and interface it to a PC or handheld. I did something like this for an article I wrote for Circuit Cellar, PalmOS Data Acquisition. Interfacing with the existing OBD I/II bus is one way to go, but unless you have the factory-approved tools, the updates are usually very slow and usually crippled in some way.
If you go custom, you get the ability to do lots of other interesting things too.
..don't panic
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.
Unfortunately, it is illegal to drive a aftermarket ECU equipped vehicle on the road - compliments emissions laws almost everywhere. Not that it stops anybody, but you should be aware of this.
Almost all cars have a facility to blink you a warning light, usually the only tool you need is a paperclip, at least in the case of my car. The amount of other data you can get varies, and the update speeds of the OBD-II ports are limited.
..don't panic
Auterra has an OBD-II scan tool that runs on PalmOS. One of my friends has it, and seems pretty happy with it.
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.
I am disrespectful to dirt! Can you see that I am serious?!
My idea is similar, except the HUD is also connected to a radar detector the displays a warning when a police officer is within range and his location relative to your vehicle along with the location and speed of friendly/neutral vehicles nearby.. Now if I could only figure out that pesky heat signature target lock
As far as engine control goes, it is hard to beat Motec's line of ECU's. While it is designed for racing applications, it is completely capable of being tuned for a road vehicle. They offer a huge variety of sensors and have some other trick items like a replacement dash that is configureable and has 8 Mb of memory for logging data from sensors. Also trick is the fact that it supports telemetry via serial I/O and high speed bi-directional CAN. It can be adapted to implement traction control, control a nitrous system, and a wide variety of other things. And if you are feeling really adventurous they offer a geek racer steering wheel complete with LCD read out and programable warning LED's. More importantly it is programmed in realtime via an interface to a PC. So it can be the perfect complement to engineering something to control multimedia devices and enviornment controls. If anyone in the US is interested, I would contact Bob Norwood at Norwood Autocraft. For more geek quotient, he is the man who built John Carmacks Ferrari's into the transmission eating beasts that they are, and used MoTeC's on all of them. Keep us updated on what you figure out as I am a car guy and very interested in your project.
1) If you wire in parallel with the sensors with a high-impedance sensor, you won't affect its existing operation.
2) 99% of the sensors themselves are very well documented for diagnostic purposes. For example, I can tell you that the oxygen sensor used in late-80s/early 90s Chrysler vehicles ranges from 0-5v depending on air/fuel ratio, with 0.8-0.9v being the optimal level, less being lean, and higher being rich.
3) Not that difficult
4) Again, not that difficult. Most of these sensors are either pulse generators or linear analog sensors with a range of 0-5v or 0-12v.
The other option is to use the OBDII diagnostic port of the computer, and possibly any other ports available. (For example, on a lot of Chrysler vehicles from the late 80s to the late 90s, they used a bus called CCD for Chrysler Collision Detection. Most people think this means some sort of detection of a physical collision, but it actually refers to collision detection in the network access sense.)
The CCD bus is basically 8N1 serial at a somewhat oddball bitrate (I forget exactly, but it's 10 kilobits/sec and can be created by an integer divisor of an 8 MHz clock), plus some weirdo access control stuff that isn't necessary if you just want to read the bus. Uses differential signalling.
retrorocket.o not found, launch anyway?