I recently got a ScanTool OBDII to USB/Bluetooth tool, I can't call it a 
scanner because it is much more than a basic scanner. Connected to a 
Nettop (small laptop) computer, the amount of information is huge. For 
my 2002 Mercury Cougar, there are703 supported PID's (data items). From 
very basic like RPM and Coolant temperature to voltages and other 
parameters of both sensors and commands to action items. I have been 
using it to track down a slightly out of tolerance sensor (I think) that 
is causing pinging at idle with a slight load (air conditioner and/ or 
in gear). With the help of the vehicle's shop manual including the 
emissions book it has been a learning experience.

The setup provides readings to a few tenths of seconds, that are easily 
converted to a CSV file and imported to Excel for review. Other computer 
screens look like a car dashboard with speed, RPM, and other items 
displayed. To see these numbers by the fraction of a second is necessary 
to catch an intermittent or short term event, in my case it seems to 
change in less than 2 minutes after a cold start. Some of the neat 
things including 0-60 mph and drag race scenes to determine your 
vehicles performance. :)

On 7/14/2010 7:27 PM, Vitaliy wrote:
> I received an off-line response to the "[AD] microOBD 200 article" post:
>
> "I find the concept of publishing an article on a project to be interesting.
> The problem is that I never got my hands on an on board diagnostic system.
> It is all greek and latin to me."
>
> Wikipedia has an article on OBD:
>
> http://en.wikipedia.org/wiki/On-board_diagnostics
>
> You can think of OBD as a gateway to the vehicle's computer system. Most
> cars have a network of electronic control modules (ECUs), each one of which
> performs a specific function such as controlling the engine, transmission,
> ABS, airbags, power windows, locks, seats, et cetera.
>
> With the introduction of OBD-2 in 1994, the physical, data, and application
> layers were standardized and made available to third party manufacturers. A
> lot of this information is now available on the internet, and there is a
> number of OBD to UART converters on the market.
>
> The most common use of OBD is diagnostics, any decent scan tool nowadays can
> pull trouble codes and display vehicle parameters (some cars support
> hundreds of parameters). Another use involves controlling actuators, for
> example you could send a message to start the vehicle, or control the volume
> of the radio, or even control the throttle position.
>
> While some of the information may be had by intercepting messages that
> modules send to each other (for instance, instrument dashboard could be
> periodically requesting fuel level status), most of the time you have to
> specifically request it. For example, if you wanted to know the RPM, this is
> what a typical exchange would look like:
>
>      01 0C    // Mode 1, parameter ID 0C = RPM
>      41 0C 01 23    // Response to Mode 1, PID 0C
>
> The last two bytes are the RPM, encoded as 1/4 RPM per bit. You can find
> more generic PIDs here:
>
> http://en.wikipedia.org/wiki/OBD-II_PIDs
>
> I would be happy to try to answer any OBD related questions that you may
> have.
>
> Best regards,
>
> Vitaliy Maksimov
> ScanTool.net LLC
> http://www.scantool.net
>
>    
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist