OBD1, and obdsim plugins

chunkyks · 06-18-2009, 12:21 PM

All,

I was talking to cgalpin this morning, and he pointed out that my OBD II Simulator can be used to do some interesting things. Of particular interest is that it's pluggable; you can write different data generator plugins for it that can proxy data from differing sources.

Currently I have two plugins for it. One, called "logger", that reports [through 0x00, 0x20, etc] that it is capable of outputting values based on what columns are in the database, then it draws values from that database, interpolating as it goes.

The second plugin is called "random"; it reports that it's capable of responding to all PIDs 0x01->0x19, and then supplies numbers generously provided by random() whenever it's queried.

cgalpin raised the interesting point that this is a clean way to function as a proxy for OBD1 <-> OBD2. Specifically, if I knew how to talk to an OBD1 car, then I could write a plugin that talks to the car, then have obdsim feed OBD2 data back to the client application. So now I'm curious; how does OBD1 work? Can anyone point me to some decent docs? I googled a bit, but mostly what turns up is a bunch of stuff about GM and a bunch of stuff about how OBD2 is better.

Presumably there's other interesting things you could do with this pluggable OBD2 proxy thing; does anyone have any ideas?

Have fun,
Gary (-;

cgalpin · 06-18-2009, 12:36 PM

Other than codes I am not sure OBDI exposes the data. I *think* you have to tap into the sensor inputs yourself (or add sensors) and then us something like the FB to convert to a form that would feed the plugin.

I have an OBDI vehicle which has at least VSS, MAF, Temp, O2 sensors that feed data to the ECU. I figured I'd tap into those, feed them to the FB, and read that data, do a little math on it, and pass to obdsim via a custom plugin. Then any software I use just thinks it's dealing with OBDII from that point. We should be able to share a lot of our work this way.

For example on my vehicle with no ECU, as long as I can add sensors or generate the same data, I get to reuse everything else

chunkyks · 06-18-2009, 12:52 PM

Yeah. I think the core point is that loads of awesome software exists that does interesting things with OBD2, and very little [even less that's free as in beer] that works with OBD1. By proxying one onto the other, you get a great corpus of tools that work with OBD1.

Gary (-;

cgalpin · 06-18-2009, 12:56 PM

You got it!

chunkyks · 06-18-2009, 01:29 PM

OK, I finally got around to trying to figure out what you mean by FB; Fusion Brain, right?

Looking at the fusion brain website, it seems like it'd be pretty easy, and more general, to write a fusion brain plugin rather than an OBDI plugin. If you were to document how you connect your OBDI car's sensors to a fusion brain, then end users would have all the pieces they need to service OBDII from their aging car for a grand total of sixty five dollars.

Am I on the right track, here? Going a little further, you could butcher up a sheevaplug and an FB and a seven dollar radio shack project enclosure, and end up with your old car throwing out OBDII, all from one tidy box. [Although obdsim is still a software-only toy, so other software would need to be running on the sheevaplug itself, too ...]

Sadly, I don't own any cars appropriate to such a project, but I'm stoked at the potential of helping out...

Gary (-;

cgalpin · 06-18-2009, 01:34 PM

Yes it would be a FB plugin, but at a minimum it would need configuration for each user, if not modifications. But most of it will be reusable. My point is that OBDI users should have an easier time getting access to the data than a non-obd vehicle since most of the inputs are already there.

I have much loftier goals for my Sheeva when it arrives. Exposing OBDII is one of many things it will do, but yes it will do this just fine.

chunkyks · 06-18-2009, 01:39 PM

Huh. someone already did the hard work on this, too

You'd just have to document what *you* did; that's good enough, I'd think. As I understand it from a brief glance at the documentation, the only difference in software between your implementation and someone else's would be a mapping of {analog input ID on the FB} <-> {OBD II PID} for each input. Easily done with a config file...

Gary (-;

cgalpin · 06-18-2009, 01:46 PM

Yes malcom2073 has written a linux driver for the FB. Tripzero added dbus support already (fbd). It's only a partial implementation (for example reading analog inputs isn't working for me yet) but once complete it's going to be very easy to tie it all together.

My idea for a obdsim plugin is to register for the dbus signals coming from fbd and cache the latest value for the stuff you care about. Done!

charles

chunkyks · 06-18-2009, 01:48 PM

:boggle:

If you already have a decent fbd daemon, then you're even better off; just create a dbus plugin, and obdsim works with fb, and anything else.

Erm, a dbus plugin certain sounds within my grasp, since I don't have a FB. tripzero will be pleased

Gary (-;

cgalpin · 06-18-2009, 01:52 PM

haha. yes. I believe this (dbus plugin) was one of my first comments to you when you said you were making a sim. lol

malcom2073 · 06-18-2009, 02:02 PM

I have an aldl based obd1 car as my second car. If I may lend more code to this I may be able to provide aldl support for you

Bugbyte · 06-18-2009, 02:04 PM

You know about this thread, right? http://www.mp3car.com/vbulletin/fusi...ram-linux.html

cgalpin · 06-18-2009, 02:09 PM

Bugbyte, yup thats the linux driver and fbd we are talking about.

Mal, I don't know what if any protocol mine speaks. It's a rover 14CUX system. The site below shows the pin in/outs and it has a primitive code displayer but other than that I am unaware of any protocol it supports. So my plan is to tap into the wires and use the FB to grab the data I need.

http://www.britishv8.org/Articles/Rover-14CUX-EFI.htm

malcom2073 · 06-18-2009, 02:13 PM

cgalpin: ALDL is a mid 80's to early 90's protcol that a good number of GM vehicles used. The reader for it is about $80, and most vehicles support a very large range of information being broadcast back at a rather insane data rate. Mine sends 70 values (a 70 byte string) 10 times per second.

Be careful when hooking in the FB to read analog voltages, as reading voltage can change the voltage that the ECU reads. I'm not entirely sure on the logistics of that.

cgalpin · 06-18-2009, 02:19 PM

Good point on altering the voltage levels. Mmh. Short of adding additional sensors (which I am not sure you can do for a lot of them) I don't know how to avoid that.

User Name		Remember Me?
Password