After playing with another free package, I've found it locks up more than mine does -- don't know why. So I'm making mine available in it's current form.



I'm also not totally happy with the data collection module of the other package as far as speed -- I think I can do better maybe. We'll see. I'll let you know and perhaps post some beta's.

This softwaer I'm giving away comes in two parts: a Palm-OS executable called OBDPALM.PRC and a database called Generic-3ELZ.PDB. I have registered the app with Palm and my developer ID for this project is 3ELZ. You may not sell this product (I don't know who'd buy it so far anyway, lol) but you can use it for yourself as you see fit.

It looks like this when it comes up. Tapping the "Check" button starts the code retrieval sequence. The codes show up in the list box on the right, which scrolls if there's a bunch of them. Tapping on the codes displays a pop up with the decoded text.


I compiled the database from a number of public domain sources and it's the most complete set of codes I've found for Fords. You can use the database for your own purposes if you like.

The software can be used even without a scantool to look up codes. There's a menu selection for that ("Search Codes") as shown here, and the second screen shot shows the screen with a code entered and decoded.





You need the type of interface based on the chip made by Elm Electronics of Canada ( http://www.elmelectronics.com ). Scantool ( http://www.scantool.net ) sells the interfaces and cables and gives away software for the PC.

Here's my software and database (right click and save, then sync to your Palm):

http://home.earthlink.net/~johngriggs/bin/OBDPALM.PRC

http://home.earthlink.net/~johngrigg...neric-3ELZ.PDB

It should run on all palms from an early Palm Professional to just about any newer Palm PROVIDED that the unit has a serial port. Keep in mind that you need a null-modem adaptor to use it with the Scantool interfaces, or you need a suitably fabricated serial cable.

Right now, the software only gets stored and not pending codes, and allows you to see the text message for that code when you click on the retrieved codes from a list. If you have a 2001 or later vehicle it will also tell you the VIN number of your vehicle.

You can turn off the MIL/CEL with it as well.

Have fun and post questions that come up in using it here.

 

Thanks, John! I looked on the Scantool website and didn't find any interfaces, just a lot of shop tools.

EDIT - found it at www.scantool.net

 

Maybe I used the wrong link. I'll find the right or a better one!!!

DOH!!! http://www.scantool.NET not .COM, sorry! :)

 

thats awesome John...have you ever seen those Tablet PC's? I think those are really cool...:D I want one...

 

Me too! (but I'm too cheap to spend the money...for now anyway, lol!)

 

i've got a handspring and i dont know what i'd need to connect it to the truck. please help el kabong!!!

 

Give me your model number or type. Most Handsprings will work fine for this.

 

Here's a link for everyone where you can look up the specs on your Palm, Handspring, etc. It must be a Palm compatible device like these to run my software, and it must be serial capable either from a dedicated serial hotsync port, or the Palm universal connector.

http://www.palmblvd.com/hardware.html

If you're still confused, I'll look it up for you. Some of the spec sheets are not complete -- but if they say "NO" for USB then they have a compatible serial port for sure. If they have USB, they may or may not. Many of the newest Palms like the base Zire and even some advanced ones have dropped the RS-232 serial port altogether in favor of a USB only approach.

My IBM C500 (a Palm 500 in IBM clothing) has both USB and an RS-232 serial port -- best of both worlds.

 

ive got the handspring visor and a layer of dust on it.

 

Okay. If you have that, and the "sync" cable to connect to a PC, then you have basically what you need. Look at the Scantool site, and you need the "PWM" style interface kit. With a nice case for the interface it's $99 and if you can find something to package the bare board in it's $79.

You also need a 9 or 25 pin "null modem" and gender changer to make the cable work. I believe that's all discussed in the FAQ on the scantool site.

The Scantool stuff was basically made to work with a PC, that's why the cable is not a direct connect and you need the adaptors. I made a cable for mine that is a combination 9 to 25 pin adaptor, gender changer and null modem. That way I don't have to use all those adaptors.

 

One other thing I forgot to mention: when you use this thing to check codes, it creates a file in memopad titled with the date and time. The file contains the serial number of the vehicle (if available), the status of the CEL/MIL and all stored codes uploaded. That way, if you have a few and need to review, they're all stored for you where you can get them easily. You can edit that file of course to add your own notes if desired.

 

If your tool is a generic scan tool, it should work with every vehicle sold in the United States since 1996, not just on Rangers. Have you tried to hook it up to anything else?

 

The scantool interface is designed only to work w/ PWM type OBD II systems. If you were to get a different interface, or a universal type, then it would probably work w/ any vehicle. Even w/ just the PWM interface, you should be able to interface to 98% of Ford/Lincoln/Mercury vehicles.

 

Yes, I've used the ISO version of the ELM interface as well. I had to modify the software since unlike the PWM (Ford) version, there is a special initialization the ISO interface goes through. I DO have the "generic" codes in there, but only the "manufacturer specific" codes from Ford.

I have not tested it with the VPWM interface that some GM vehicles use. If someone has an interface box based on the ELM chip for this, it would be nice if they did test it.

But for the ISO and PWM, my software works fine.

EDIT: To clarify: ELM makes three different chips, and Scantool sells the boxes in the three varieties. There is no "universal" version from ELM (unless they just came out with it). But the ELM stuff is dirt cheap if you don't need "universal" compatibility.

 

Other makers make 'universal' OBDII <-> RS232 interfaces that will work w/ all three types. I'm not sure if the interface would be compadible w/ the ELM type 'chips' (which is just a flashed PIC micro, BTW). But they are out there. Only a few bux more. Much cheaper then buying 3 scantool boxes..

 

It's not. I'd have to write another driver, but it's not big deal. I just don't feel like spending the money to buy the generic interfaces to test it with on software I'm giving away, lol! :)

Not cheaper though if you only need the one, that's for sure. I think you'll see the ELM based units dropping price before long anyway.

Since I built mine for less than $60, including the OBD-II cable, it doesn't get much cheaper than that.

 

Again, I wasn't suggesting that you write support for these other units as well. All I was doing is pointing out that they are out there and the ELM is not one of them. Although I'm a little surprised that the interface is all that different.

Yes the ELM chips are cheaper. This is why I have one too. I am not concerned w/ scanning other vehicles. At least not right now..

 

The whole purpose of OBD was to make the vehicles generic as far as monitoring emissions related equipment. If you sell a vehicle here you have to comply with the rules as far as codes and monitors go. Every manufacturer uses the same connector, and pretty much the same protocol (will be the same in a couple years), and they use the same terminology and codes. A 0102 code on a Ford means the same thing as a 0102 code on my Audi.

There are other manufacturer specific codes beyond the OBD stuff that you may not be able to get to with a generic scanner, but all the generic OBD information should be consistent between all the vehicles made since 1996.

There should be no difference between manufacturers as far as generic OBD scanning goes, other than protocols. Is that what you are talking about? In 2007 everyone will be required to use CAN so it should be really generic then. For our tools we have a box that takes whatever protocol the vehicle uses and converts it to USB. The same part is used with the NGS Plus if you've seen one of those.

 

Mine was free, but I don't own it.

 

I think we are talking about interfacing w/ the interface. The boxes John and I have are based on a chip made by ELM. These chips, along w/ some support electronics, convert the PWM OBDII interface into an RS-232 (standard serial) interface. The palm, pc, or whatever needs to then interface w/ the ELM. The ELM chip has some instructions for initializing and sending/receiving requests on the OBDII port. Presumably changing the ELM part for another, unversal part (universal in that it speaks PWM, ISO, and VPW) would require modifying the software. That being said it sounds like you couls swap the PWM ELM part for an ISO or VPW ELM part and still have it work w/ John's software..

 

This is true. General Motors worked closely with the EPA to develop the generic OBD codes. Naturally, the codes and part names were based on what General Motors was already using. That's why Ford (and almost everyone else) had to rename a lot of their emission components and renumber their DTCs to be OBD compliant.

 

Colin's got it. However some of the issues DO revolve around differences in the OBD-II implementations in the vehicles.

Really, to call OBD-II a "standard" to some extent is misleading. Connector is the same, basic frame structure for packets is the same -- but bus hardware standards, timing and arbitration are QUITE different between the various "flavors" of OBD-II.

The main issues are:

1. Signalling standards: although the basic protocol for requests is the same ON THE BUS OF THE VEHICLE, the bus itself is different in the way it encodes 1's and 0's. In addition, Ford actually uses TWO networks on their vehicles. One is the PWM OBD-II "compliant" bus (balanced line), and the other is an ISO-9141 bus ("one wire") that connects the auxilliary controllers like ABS and so forth. I know very little about this bus.

2. Bus arbitration and synchronization: the ISO style OBD-II interface requires the unit to "introduce" itself in a way that the PWM apparently does not. This initialization occurs between the ELM chip and the OBD-II bus in the ISO style vehicle. This means that for the ELM chip the first communication response when the interface is plugged in is delayed while this sequence is done. It's transparent to the user EXCEPT for the extra time -- which caused the driver I wrote to "time out".

To fix this, when the Palm software is told to read codes it resets the ELM chip with the ATZ command which causes it to set the comms back to default and to send a string identifying the type of chip. From this I then know to use an extra long timeout when I send the first request in order to allow time for the ELM chip to get "authorized" on the ISO OBD-II bus.

Since the basic command sequencing and code parsing is all done, it would be pretty easy to add another interface type, even if it was different from the ELM. If somebody has one, I can get the formats most likely and you can test the results on your system. I'm open to that if somebody wants it.

I very much like the idea of standardizing on the controller area network ("CAN") bus. It's robust and supports redundancy and is being considered along with some other specialty busses for all sorts of "fly by wire" applications in vehicles as well.