OBD-II Engine management

Has anyone looked at OBD-II engine management and the possibility of monitoring
your engine from the empeg ?

All cars in the US after 96 have this system, not sure about the rest of the world.

The background page here gives a good overview http://www.obdii.com/background.html

This was discussed some time ago (search under OBD) but I don't think anything came of it.

-Zeke

The problem is the OBD-II protocol is not publicized anywhere. I think you have to purchase a license to develop a tool or software on the protocol this leads to tools costing $$$$$$$. Many of the cheaper tools out there reverse engineer the protocol.

Calvin

I am the one who was looking at the idea; I was going to be monitoring ODB-2 data over an adapter to serial and displaying it on the empeg screen. There are a number of delays on it, and I have done no further work in several months now.

It's not impossible; the serial protocols are published in a number of places, and it is basically a non-polar 5V serial diff connection. You can buy ODB to 232 adaptors all over for relatively small money. The major problems are that you must process and display on the fly (in RAM working - interferes with the player) since the disks are mounted RO at startup, and you must co-operatively share the screen with the player to display any stats, either graphically or otherwise. Otherwise you have to stop the player, and allow your app full control of both memory and screen. It really is not worth trying to write data to disk and risk a head crash while active.

My current approach is to look at a small footprint, high perf JVM with AWT graphics for the display part, but I have no co-operative solution operative.

Have a look for previous discussions about data acquisition and display on the empeg, and other threads on ODB with the search mechanism.

My current approach is to look at a small footprint, high perf JVM with AWT graphics for the display part,

The OBD stuff would be cool, but I would be much more interested in a light JVM that could run on the empeg along with the player. Does such a beast actually exist?

-Mike

There are a number of Coldfire and Dragonball (Motorola) K Vm implementations; there is also an ARM one which I found through the ARM home page when I was looking for a compact embedded JVM solution for a telephone a couple of years ago. I am looking at KVM for Linux with a Java Micro Card-like class set (NOT J2ME, which is considerably bigger). The KVM is clean-roomed implementation from the spec, with MC class restrictions. You should be able to use the SUN ME verifier on code you have written to target the KVM on Linux.

OK, but do you have a link to something that will actually run on the empeg or a page explaining how to get a KVM setup on an ARM system?

-Mike

So it sounds like real-time readings are possible with an empeg dedicated only to ODB-2 data collection (if one had am extra empeg and a place to mount it)

Or could you just set the input to Aux and not listen to musicwhile doing it? Or is that still too much CPU usage?

Reading ODB would take almost no CPU time (much less than 1%), someone just needs to write the code.

Adaptors for ODB-serial ports are available already, try a google search.

Hugo

New the the empeg thing, just got it this week. Already attached to it.... I remebered about 3yrs ago seeing it when it was a backyard project and drooling...

I also VERY much like idea of the OBD monitoring, already have cable. Would like to monitor boost and engine data on my GMC Typhoon. Don't know much about programming (know a lot about CNC, I am assuming a diff. animal). Got some questions.

-What program language should I learn to make this happen?
-Any good websites to steer me into learning Linux and other stuff I need to make this work???
- Any other help would be great also.
- Maybe a basic idea of steps would help also, ex. (write code, compile, load, test, jump up and down,????)
home email
[email protected]
jeff ty#1295
mk2a #2159

From what I can gather, this isn't the sort of beast you want to learn if you don't know how to program in C/C++. C and C++ take years to learn well enough to do major programming. Not that I'm calling this major, but I would say that at least a few months of reading up would be required. Unless there are already header files, etc. for OBD that someone has already produced that you can link into your code and all that would be required is dumping to the screen. Which can be doine using bitblit'ing or echoing from the terminal.

I played with reading GM pre-OBDII data from the ALDL ('assembly line diagnostic link' or something like that -- the plug under the steering column) back when I had a Buick. I built a small circuit which did level conversion for the serial data, and found some links for parsing the data. I got bored with the project before I did much with it, but I still have some links around. Here's one:

http://www.mindspring.com/~amattei/aldl.htm


Now that I have an Empeg, I'm more interested in this kind of thing, since almost all the hardware is already there. But now I have a pre-OBDII Subaru and don't have a source for the data format. (Presumably, getting the car's data stream into the Empeg would be easy; reverse-engineering the meaning of the bits would be a huge project.)

Is C type programming the best to learn then? I am ready to learn, I like taking on new projects and skills, might become handy and benefitial in job also. I could take some classes at local college and even get work to pay for most of it.

As far as knowing what bits are what, not a problem. I already have that data and it is well documented. I just need to know how to get the computer to understand it.

Jeff

Okay, this is fairly far off-topic, but in my experience, most modern shops want either C, Visual C++, or Java experience. At the same time, if one is a competent programmer, it shouldn't take very long to become competent with a new language. But if you've never programmed before, I have a few notions about what you should start with. I've always believed that Pascal was a wonderful teaching language for the same reasons that it's a lousy real-world language. You get to learn the concepts of algorithms without having to worry about a bunch of underlying crap that is irrelevant to what you're trying to learn. On the other hand, it will not be directly useful to you in real life. C is not a horrible learning language, as it's very static. That is, there are not a dozen ways to do the same thing, so it's easy to decide which way to go. And it's, by far, the most common language for writing Unix applications. [religion]C++ is a horrible language in almost every aspect[/religion], but if you want to program for Windows, you'd better learn it. Regardless, it's a horrible language to learn basic programming with. Java is, for the most part, a nice language, excluding the fact that you have to run Java programs within a virtual machine. There are a few native compilers here and there, but they're not as common as they ought to be. Note that Pascal and C are procedural languages and Java is an object-oriented language and C++ is a bizarre amalgam of procedure and object-orientation. I'd suggest starting with a procedural language, as it seems the most straightforward to me, whereas object-oriented languages help programmers who already know what they're doing and are trying to reutilize code as much as possible, but that's far more personal opinion than the rest of this postulate.

Hi.

I mostly agree with you. However I wouldn't condemn C++, but I do condemn most APIs that are associated with it, like MFC (blech). There is only one C++ API that I would call a clean, object-oriented (though event-driven) API, and that is Trolltech's QT (which also makes your programs fairly portable).
My favorite language for quick applications has always been Pascal or (nowadays) Delphi. It is also a good language if you only just start learning programming, as it allows the good old procedural programming style, but also allows the introduction of object oriented programming.
The programming language I tell every beginner to avoid is Perl (but I love it for scripting purposes, and also know some good programmers who are able to do amazing things with Perl), there are way too many possible syntax variants and solutions to given problems to be of much use for learning how to program cleanly.
I strongly advice any programmer to gather at least some experience with C, it is way to widespread to ignore, and almost any low level (near the hardware) application is written in C today (if not in assembler).
Wether you choose Java or C++ as your object-oriented language is up to your personal taste. Java has the advantage that it is different from C, C++ has the advantage of being similar to C. Sounds confusing? It is. Let me explain: If you already know C, and start to do object-oriented programming in C++, you are often tempted to fall back to simple C for the smaller tasks, but this ruines the object-oriented layout of your software. However, these fall back solutions in C are often faster than doing the same thing strictly OO, so they can be of advantage as well. Java on the other hand does not allow the same kind of fallback (even thoug Java _can_ be programmed in a procedural style if you are crazy enough to try that), so you are (mildly) forced to stay with your OO design.
Java's use of a virtual machine is a disadvantage that many underestimate, that JVM costs a lot of memory and CPU time, so a Java program is almost always slower than its C/C++ equivalent, and just as often a lot bigger. The advantage of the virtual machines is the portability of Java. But this portability is degraded by the need of additional classes for hardware access which, in turn, aren't very portable at all. But thank god, most accessory classes (like for serial port access) are available for the most important operating systems (usually Unix, including Linux/Solaris/etc., Windows and MacOS).

So if anyone wants to learn how to program, learn Pascal/Delphi first, learn about the most important algorithms (like how lists, arrays, trees etc. are handled "by hand"), than start to think about which language you might want to learn next. I would advice to learn C, learn about its pitfalls and its drawbacks as well as advantages over Pascal.
When you are somewhat confident to be able to program in procedural languages, start looking at OO designs, than start looking at different OO languages, most importantly C++ and Java (yeah, I know Modula-2, but is it used anywhere today?). As said above, I would recommend Java. If you know C and Java, it is very easy to learn C++, but if you know C and C++, it is still hard to learn Java.
If you did al that, and still feel like you should learn yet another programming style, try learning a functional language (like perhaps Standard ML or Scheme[did I miss a bracket again??*]) or a logical one (like Prolog).
Even more adventurous natures might like to learn one assembly language or two as well.
Oh, if you would like to learn an extremely weird (functional) programming language, learn APL (a development originally made by IBM). There have been obfuscated APL programming contests. One of the winners didn't even recognize his own program after the jury removed all comments from the code. That language uses a lot of special characters of which each represents its own function (like create a matrix of n*m with o on each of the (i,i) positions or convert a string into a list of single character strings). A really weird language.

Did I miss anything important?

cu,
sven

* Scheme programs "known" to contain more brackets than letters or numbers.

Hi.

Back to the topic:

To those who know some things about OBD-II (I certainly don't): Is it possible to read the current speed through tha interface, or the current mileage? If so, shouldn't these two infos be quite valuable for navigation systems? And if that is the case (I think so): Do you guys think that it is fairly easy/cheap to get a circuit together that allows the quasi-simultaneous read-out of both necessary information sources (GPS and OBD-II)? something like accepting command strings from the empeg that are prefixed by a code for the receipient and the actual length of the original command string, and sending the original string only to the device that was specified, and in turn taking the inputs from both external devices, prefix them by identifiers (and length specifier), and send those on to the empeg?

I know this could also go to the PCA thread in projects as well as to the nav thread over there. May be I should post a cross reference over there.

cu,
sven

I would personally suggest that if you're in the market to learn OO, that you find a language that's as OO as possible, in order to avoid falling back to old habits. My personal suggestions for that would be Ruby or Smalltalk. Java is not quite OO enough, IMHO, to be excellent for this purpose. Once you've got OO down, then you'll be able to use any OO-ish language to its full potential, even C++.

From what I recall of the GM datastream I played with , the PCM (powertrain control module -- I think they got NASA to name that one) would periodically emit a packet of data containing, among other things, vehicle speed. A lot of the relevant data was pushed, and you could just listen to the wire. Things like fuel maps were more complicated and required a bidirectional protocol. (Caveat: I only spent a few weekends playing with this stuff...) I have no idea if OBDII resembles this, but my guess is that it does.

If you wanted to multiplex the serial line, you could hook a pair of analog switches to one of the serial port control lines (assuming they exit the wiring harness)... then you just assert/deassert e.g. DTR or CTS in software to switch.

At http://www.opendiag.org/ there seems to be a project to get at the ODB-II bitstream as well as "crude" designs for converting to RS232.

From their mailing list :



"We are about to release an alpha version of ODBII scantool stuff for Linux.

Its early version, only supports K line type interfaces [not VPW/PWM ones as
I dont have a VPW/PWM car], and isnt GUI based.

It will be opensource, and on sourceforge.

It supports "Jeffs" interface (and the Andy Whittaker derivative), the
Multiplex-Engineering interface and the Silicon Engines interface. I dunno
anything about Alex's interface but I would imagine its similar to Jeff/Andy
[i.e a rs232 to K line converter][anyone got some more details of Alex's
interface ??]

Im just trying to make time to do some web pages etc and test the code on my
new PC after my development box and my power supply blew up :-( Its sort of
been sat on my box waiting for a couple of months now ...

Andy Whittaker is working on porting it to Windows aswell

One of us will write VW specific code soon [I need to borrow someone else's
Audi stereo to complete that]

Regards
Richard"

-Kit

Intercal deserves a mention...
http://www.ugcs.caltech.edu/~jlm/intercal.html

'Marius (Escort Cab + Mark II)

Maybe Toby can write the code, then the empeg can read the actual speed of the car from the vehicle computer and do things like speed sensitive visuals, speed sensitive volume control -- perhaps even RPM sensitive "engine noise" compensation... cool bean stuff like that.

Calvin

Yes, it most definitely has vehicle speed. Among other things, coolant temperature, rpm, O2 sensor values, etc. Varies by car but for the most part, lots of fun stuff to look at.

Calvin

I ordered a complete shop manual for my Yukon Denali. I'm hoping it has a lot of info on OBD-II. I'll keep my fingers crossed. (I wanted it anyway for schematics etc. so no loss either way)

OBD 2 protocol information is incredible hard to find. If you know a place where the spec is located then point it out.

Calvin

I've been searching but have found nothing yet. I have a friend who works at a GM dealer looking into it (but again nothing yet)

I've been looking, and does anyone have plans to build (or knows where to buy) an ODB-II to RS232 interface for a GM(VPW) car.

Check out this link.

http://www.elmelectronics.com/Products/theHome/theHome.htm

lynn

I think he was asking about OBD-II, not OBD.

Try http://www.obd2.com or http://www.obd-2.com. The latter is the one I use. It's a cable that converts the obd 2 plug to rs232, comes with software that runs under windows. Software is a little buggy but the cable works fine.

Calvin

I think these Elm parts are OBD-II compatable. You need more than a cable adapter to connect because the OBD-II interface is at 10.4 Kbaud and the signal lines are differently defined that RS-232 or 422. Take a look at the Elm .pdf data sheets for more detail.

Lynn

yeah,
the last page of the pdf sheets give examples of how these interfaces have to be modified.

Both of those look good(and in my price range ), thanks for the info.

mmmmmmmmm, Why can't I learn to read properly. I've already ordered a couple of those chips in the belief that it was for OBD-II.

Well, good think they're not that expensive. Anyone who want one??

TommyE

Your not the only one who can't read.

Hehe, nice to hear

TommyE

Ok. That's good to know. It did seem like these guys were asking for a simple cable that plugs into the OBD2 port and the other end plugs into the serial port on a computer. I dont think they're looking for a project....

Calvin

I too have ordered one hoping to hook it to an OBD-II vehicle.

However, the data sheets opens with:

"Since the 1996 model year, North American automobiles have been required to provide an OBD, or On Board Diagnostics, port for the connection of test equipment."

Now PLEASE correct me if I'm wrong here, but wasn't 1996 the year OBD-II became a requirement, not just OBD?

Does it even matter at the electrical interface layer?

The data sheet sounds like the right thing. Assuming it works it will make talking OBD much easier for our applications.

Cheers,

Rex.

Right. 1996+ is OBD2. You'll find some vehicles from 1995 equipped with OBD2 as well, as typically manufacturers produce the stated year car one year back.

Calvin

Hmm, interesting. Those ELM parts look an awful lot like the Microchip PIC16C505. I imagine that is all they are.. It is nice they do the handshaking for you. Look at www.opendiag.org for a simple level translator for RS232. They have info on the protocol and a Yahoo group too.

Speedy

What about OBD1 can we hook up to the empeg given the right software. By the way OBD1 is better.........its alot easier to work with the 94-95 acura integra GSRs are a bit faster than the 96-01 GSRs because of OBD1

I don't doubt these are PIC based, nothing wrong with that.

That's hardly "all they are" though. One hopes that ELM is putting some software on them!

I agree that it's not hard to handle this protocol directly but this ~US$10 part saves some work. In my case I won't have a hardware UART driving this thing so outputting both 5 and 104xx (?) baud is a headache I don't want. (This will be hooked up to a serial multiplexor -- another PIC -- not the empeg.)

We need a level converter with either design.

I guess you misunderstood what I meant. I meant it's not a special ASIC, and something that could be reproduced with some elbow grease. Not "Gee look a $1 PIC is the same thing as this $10 part, what a RIP!" Couldn't your PIC output pretty much any BPS you want, with the right xtal selection?

Speedy

OBD1 suffered from being non-standard. Every car had a different protocol that suited the make and model. Definitely, OBD1 is better for diagnostic, datalogging and tuning because it included important information specific to the engine of the specific car. For example, in a turbo car it might include knock detection and turbine speed. The drawback is for each make of car you need a different diagnostic box, and as you can imagine, the ordinary mechanic would not have been able to afford all the boxes unless they were specialized or a dealer.

OBD2 suffered from being rushed through design to solve this problem, and impose a strict standard for *all* cars... as a result a lot of specialty data channels like knock, etc, that are not consistent for all cars (NA cars..etc) are dropped. So it effectively is a lowest common denominator standard that works for all but is useless for many. Too bad the protocol committee didn't actually have more time or knowhow to design it correctly. But if there's any chance of a standard way to talk to the engine computer then it would have to be OBD2 as it is the most generic

Calvin

Yes, I misunderstood.

My mux is quite complicated. The hardware UART is off talking to the empeg. In software it has to emulate another two UARTs as well as take accelerometer measurements and some other house keeping, all running at once.

Multi-rate could be done but this code is already very complex. (Not that it's finished yet...) Not even sure I have the CPU power to pull all this off, it'll be tighter than I would like. Might end up with something other than a PIC.

There are other timing/latency issues that this ELM device should resolve in this case.

I have an ELM323 hooked up to my 2001 Mitsubishi Eclipse (OBD-II.) Works like a champ so far!

My other cars are Fords and my bike doesn't even have a computer so I haven't tested it on anything else yet.

There's some good info on the base PIDs on this page:

http://www.abcwc.net/accounts/quanta/obdinfo/pids1-2.html

Anyone know a good source of manufacturer specific PIDs?

Cheers,

Rex.