can't understand basics.. how the scan tools work?

**slushieken** · 08-22-2004, 04:12 AM

Originally Posted by DavidL

The federal OBD2 generic specification was to make it easier for a non OEM scan tool manufacturer a way to produce tools that could be sold to the service aftermarket. It covers the spec that the vehicle should respond to. This is what the scan tool hardware needs to know to communicate with the vehicle. The communication between scan tool hardware and PC is not specified and can be proprietary to the scan tool hardware company. Many aftermarket and hobbyiest scan tool companies post their API so that other software developers can use the scan tool hardware. Some do not, because the market is not very big or lucrative yet to support the API and all the support calls that can come in by hobbiests trying to use the hardware.

OK wanted to point this out as pretty reasonable. Then are you saying that I could buy one the packages that comes with the source etc. and possibly (possibly - like an inifinite number of monkeys and trypewriters could possibly write the collected works of Shakespeare) write an app that would give me all available computer data? Even the chassis subsystem messages?

And not to muddy the waters further but does this work the same for systems that you can use to provide input to the ODBii system?

**DavidL** · 08-22-2004, 11:29 AM

Well, like noted in several prior posts, there are multiple layers of data that is accesible to/from the vehicle. OBD2 covers the set that is useful for diagnostics, enhanced data is for rest of information that is not specified by the government regulation. Enhanced is vehicle specific. The OEMs usually publish the access methodology even to enhanced, but are not required to. The best source for this data (if you are a hardware / software developer) is via ETI industry group. This is not a trivial support matter. It takes much effort to maintain the support for just one vehicle, never mind the large variety of vehicles that are common or exist.

The best way is to use a commercial product and program to that product's API and let the scan tool program deal with the issues of communicating and translating the data into human speak.

There are also multiple modules on each vehicle that provide other services. Transmission, then Body, then Antilock, then Airbag, then key /entry modules, etc. from most popular data to less popular (from a diagnostic support perspective).

Most of the controllers also have bi-directional support to aid in diagnostics. For example, turn the fan relay on, move the idle up/down (AIS motor), turn the A/C compressor relay on, etc.

Native programming of the ECU (the "Flash") is where settings like ignition timing, fuel control (including limiter functions) are programmed and are not resettable via the diagnostic connector without changing the core coding. This is usually encrypted for security and requires significant expertise to modify.

**slushieken** · 08-22-2004, 04:35 PM

DavidL-

Thanks for the explanation! You must have read my mind...

**RogerWilco** · 08-22-2004, 08:52 PM

DaivdL
Thanks, that was very helpful, one more question though.
So your saying that the ODBII, is bi-direcional? everyone else i've spoken to has said that its simply for taking readings. please correct me if i've misread something.

**gospeed.racer** · 08-22-2004, 08:58 PM

Depends on the car. For example, Ford will allow you to "active command" certain features, like the cooling fan, imrc, evap solenoids, solenoids in the trans, ect. It is used for diagnostic, so only those features needed are allowed. Also, the PCM is reflashable when over 15 volts is applied to a pin on the dlc connector. I wont go into which one cause if you dont have the right tool (WDS is the proper scan tool) you can really let the smoke out of the box.