Practical Arduino Cool Projects for Open Source Hardware- P33 ppsx

4 680R resistors 2 10K resistors 3 1K resistors 4 12-pin female PCB headers optional 2 12-pin male PCB headers optional 10cm ribbon cable optional OBD-II: 1 ELM327-based OBD2-to-USB or

4 680R resistors

2 10K resistors

3 1K resistors

4 12-pin female PCB headers (optional)

2 12-pin male PCB headers (optional)

10cm ribbon cable (optional)

OBD-II:

1 ELM327-based OBD2-to-USB (or OBD2-to-RS232) interface adapter

1 4-pin PCB-mount oriented male header

1 4-pin oriented female header

1 8-pin oriented female header

10cm ribbon cable

1 DB9 panel mount socket (female)

1 DB9 line plug (male)

1 to 2 meters 8-core flexible cable

GPS:

1 Locosys LS20031 GPS module (GPS-08975 from SparkFun)

1 4-pin PCB-mount oriented male header

1 4-pin oriented female header

10cm ribbon cable

1 3.3V FTDI adapter and matching cable (only required during setup of GPS)

Source code available from

www.practicalarduino.com/projects/vehicle-telemetry-platform

Figure 15-4 Parts required for vehicle telemetry platform

Figure 15-5 Modular structure of vehicle telemetry platform Schematics of individual modules are

included later in the project

Instructions

Check the Vehicle Interface

Important: Before you order any of the parts, it‘s best to make sure your car actually has an OBD-II–

compatible interface The OBD-II standard specifies that the connector must be located within three feet

of the driver and must not require any tools to access it, so the most common locations are just under

the dash near the steering column, behind the ashtray or glovebox, or behind a clip-open panel in the

center console What you‘re looking for is a connector like the one shown in Figure 15-6

Figure 15-6 Location of OBD-II socket under the dash of a Mazda RX-8

If your car has that physical connector in place you‘re probably safe, but it‘s still not an absolute

guarantee that it supports OBD-II, and it doesn‘t tell you which of the several OBD-II communications protocols it uses Your vehicle‘s owner manual might tell you (unlikely) or your local mechanic might be able to help, but it‘s most likely that you‘ll have to figure it out for yourself

One of the really annoying things about OBD-II is that it encompasses several different

communications protocols, and different cars can use any one of them The historical reason is that at the time OBD-II was being designed each of the major car manufacturers already had their own systems for communicating with their engine-management systems and they couldn‘t agree on switching to a

single common standard The result was that for political expediency, the OBD-II standard simply

incorporated all of them onto different pins of a single connector and let the individual manufacturers decide which one they wanted to use

So, different vehicles might all have the same OBD-II connector under the dash, but that doesn‘t

mean they all speak the same language Ford vehicles generally communicate using a PWM (pulse-width

modulation) version of the SAE J1850 standard, while GM vehicles typically use a VPW (variable pulse width) version of the same standard Many non-U.S manufacturers use an ISO protocol called 9141-2, which itself can be implemented in several different ways To make it even worse, there‘s yet another standard called ISO 14230 KWP2000, which uses the same physical communications layer as 9141-2 and shares the same pins but uses a different message format

The result is that if you look at the pinout of an OBD-II connecter, you‘ll see pairs of pins for CAN, J1850, and ISO9141-2/ISO14230 To add to the confusion, because OBD-II doesn‘t use all the pins in the standard connector, some car manufacturers have used other pins in that same connector for their own proprietary interfaces, so it might be physically installed in your car even if it doesn‘t actually support any of the OBD-II variants In a stunningly short-sighted move, some manufacturers even installed OBD-II in all cars on the production line, but then deliberately disabled it in cars sold in countries that didn‘t require it by law Infuriating!

Thankfully, sanity has prevailed and by about 2004 most manufacturers had started switching to a common standard they could all agree on called CAN, or Controller-Area Network CAN has now been mandated for all future vehicles and since 2008 all cars sold in the U.S have been required to use CAN for their OBD-II interface

If you can‘t figure out whether your car supports OBD-II, you can get more information from a number of places online:

• www.geekmyride.org

• www.mp3car.com (check in “Forums” under “Engine management”or “OBD-II,”

etc.)

• en.wikipedia.org/wiki/On-Board_Diagnostics

Generic OBD-II adapters, therefore, have to support not just one protocol but a whole bunch of them at once Luckily, they do that remarkably well, presenting the OBD-II connection to you in a generic way (usually as a USB serial device) and hiding the details of the various communications protocols In the vast majority of cases, you can plug a generic OBD-II adapter into a car and it will simply work, no matter what model of car you have Behind the scenes, the adapter checks all the pins

on the OBD-II port and negotiates with the car to establish a connection, then uses whatever protocol is most appropriate for that model

While poking around and looking for the OBD-II connector in your car, it‘s an ideal time to think ahead and consider how you‘ll mount the Vehicle Telemetry System, taking into consideration the route for the connecting cable

Obtain a USB/OBD-II or RS-232 Adapter

If you know exactly what communications protocol your car uses, it‘s possible to build a hardware interface to suit just that specific protocol and ignore all the others The OBDuino project page includes details for building interfaces specifically for several of the common systems in use, and if you know exactly what your car uses, you can save a bit of money by building just that interface More information

is available online at code.google.com/p/opengauge/wiki/OBDuino

However, for this project we took the easy way out and used a readily available generic USB/OBD-II adapter that should work with pretty much any car from 1996 onward Taking this approach means the device should be able to plug in to just about any modern car and simply work, no matter what type of car it is

Most commercial USB/OBD-II adapters are based on a chip called the ELM327 from ELM

Electronics One solution to connecting an Arduino to your car is to buy one of the chips and fit it to a prototyping shield along with the required supporting components The ELM327 chip is available

directly from www.elmelectronics.com in single quantities for around $31 The OBDuino project has

documentation showing how to connect it, if you want to go that way

It‘s often possible to buy a complete USB/OBD-II adapter containing the ELM327 chip and all the supporting components on eBay for less than the single-unit price of the chip alone Considering that

you would also need to buy one of the special OBD-II plugs if you wanted to build an interface yourself from scratch, the prebuilt adapters are an absolute bargain because they come with just about

everything you could possibly need to connect an Arduino to your car‘s engine-management system

USB/OBD-II adaptors are commonly listed on auction sites with a title such as “Car Scanner AUTO Scan Tool CAN BUS OBD2 OBD USB V1.3.”

What you‘re specifically looking for is a so-called “scan tool” using the ELM327 chip Even if the ad doesn‘t list what chip is used in the adapter, you can probably guess just by looking at the packaging If the case looks like the one in the parts picture shown in Figure 15-4 (most likely with a different sticker),

or has “v1.3” in the product title then it‘s almost certainly based on an ELM327 The v1.3 designation

refers to the current firmware version in the ELM327 Some older interfaces might be labeled v1.2a if

they use a previous generation of the chip However, v1.2a was missing a feature to easily read

multivalue parameters as well as a few other minor differences Get a v1.3 interface if possible, but a

v1.2a interface will do the job if that‘s all you have available

One thing to be wary of, though, is cheap cables listed as “RS232 OBD adapter cable” or similar,

because they might look tempting but they‘re probably just a plain cable with an OBD connector on one end and a DB-9 connector on the other They don‘t include the vital ELM327 chip that provides the

actual intelligence to convert the raw OBD-II interface into something we can communicate with

Another thing to be careful of is cheap adapters built using a ripped-off clone of an early version of the ELM327 firmware Some of these units offered for sale on auction sites are based on copies of the

v1.0 firmware that were cloned from genuine ELM327 adapters and don‘t use official ELM chips

themselves There have been a lot of improvements to the firmware since v1.0, so try to avoid the

nongenuine clones if you can

Test the USB/OBD-II Adapter

Most USB/OBD-II adapters ship with a mini-CD containing Windows-compatible diagnostics software that displays a range of engine parameters, so before doing anything else, it‘s a good idea to load it on a laptop, plug the adapter into your car, and make sure it works as advertised If your adapter didn‘t come with software, or you want to try out some alternatives, you can check out the resources listed on

www.geekmyride.org

If you don‘t have access to a Windows laptop, you can test the adapter using a serial console

program on any operating system The ELM327 provides a very simple serial interface, so all you need to

do is plug the adapter into your car, plug the USB cable into your laptop, launch a serial console such as GTKTerm or Minicom (Linux), Cornflake (Mac OS X), or HyperTerm (Windows), and set the serial port to 38400bps 8N1 (8-bit data, no stop bit, 1 parity bit) You can then communicate with the OBD-II adapter

by typing commands into the console and seeing the response

In addition to all the normal OBD-II parameters that we‘ll explain in the moment, the ELM327

supports a number of additional AT-style commands that it responds to directly These aren‘t part of the OBD-II standard itself but are implemented internally by the ELM327 For example, if you type “ATRV” (short for “ATtention: Read Voltage”) and hit return, the adapter will echo back the car‘s current battery voltage whether the car is running or not If you type “010C” (that‘s a hexadecimal value, so it‘s

“Zero-One-Zero-Cee,” which is the OBD-II parameter for engine RPM), it will query the engine-management system on your behalf and return the current RPM as an unscaled hex value if the engine is currently

running The value won‘t mean anything to you just yet because most response values need to be

processed in order to convert them to something meaningful, but at least it proves the adapter is

working

Understanding OBD-II Modes and Parameters

The full specifications relating to OBD-II are quite long and can be purchased from the SAE standards body However, automotive hackers have collected extensive information about how it works and you can find lots of the gory details documented on sites such as www.geekmyride.org For our simple case,

we only care about a subset of the parameters accessible through the interface The ELM327 chip does most of the hard work for us, so all we really need to understand are “modes” and “parameters.”

OBD-II modes are really just ways to group together the types of information that the vehicle can report Some modes are mandatory while others are optional, and any one vehicle model will only support a subset of them

OBD-II modes are broken up into a number of “basic” and “additional” modes There are nine basic modes of operation described in the OBD-II standard SAE J1979, as follows:

1 Show current data

2 Show freeze-frame data

3 Show stored Diagnostic Trouble Codes (DTCs)

4 Clear Diagnostic Trouble Codes and stored values

5 Test results, oxygen sensor monitoring

6 Test results, other component/system monitoring (e.g., Catalyst, EVAP)

7 Show pending Diagnostic Trouble Codes detected during current or last

driving cycle

8 Control operation of on-board component/system

9 Request vehicle information

Manufacturers may also define extra modes, called “additional” modes, for their own custom parameters For example, mode 21 is an additional mode used by Toyota, and mode 22 is defined by SAE J2190 for Ford/GM use

Each mode contains a number of parameters that are generally referred to as “PIDs” (Parameter IDs) or sometimes “p-codes.” Manufacturers are not required to support all PIDs even if they support the mode that contains that PID A typical car provides access to most parameters in a few of the basic modes plus one or more additional modes for manufacturer extensions

Because the value returned by the car can only be an unsigned hexadecimal value, the PIDs often don‘t return the literal reading value Many PIDs require a formula to be applied to convert the raw value returned by the car into something that makes sense For example, PID 0x0105 (mode 01, parameter 05, which is engine coolant temperature) needs to be able to represent a negative value, so it has a +40 offset applied before being sent The value returned is, therefore, always 40 degrees Celsius higher than the actual value, so to determine the real reading you have to convert from hexadecimal to decimal and then subtract 40

There are hundreds of PIDs, but we‘ll focus on the ones listed in Table 15-1

The formula listed against some PIDs includes references to “A,” “B,” “C,” or “D.” These variables represent the bytes returned by the interface, so in the case of the first PID (0x0100) the return value will

be 4 bytes of data and those 4 bytes are referred to as A, B, C, and D Another good example is PID 0x0104, the calculated engine load value It only returns a single byte (A), so the formula A * 100 / 255 means the system needs to take the byte returned and convert it to a percentage of 255

The most common formula is (A * 256) + B, which is simply a two-byte value that can range from 0

to 65535 Many PIDs are even simpler, using the raw A value to represent a reading from 0 to 255

Note that modes and PIDs are always referred to as hex values, and parameter values are always

given in SI (metric) units If you want Imperial units for parameters, such as 0105 (engine coolant

temperature), you‘ll need to take the value returned by the listed formula and then apply your own

conversion to switch it from degrees C to degrees F

Some PIDs are bitmaps representing flags that show multiple boolean results combined into a

single byte For these PIDs, the individual bits are specified after the letter, so, for example, “A7” is the

most-significant bit of the first byte, while “D0” is the least significant bit of the last byte

Table 15-1 Commonly supported parameter IDs

01 00 4 PIDs supported Bit encoded [A7 D0] == [PID 0x01 PID 0x20]

01 01 4 Monitor status

since DTCs (Diagnostic Trouble Codes) cleared Includes malfunction indicator lamp (MIL) status and number of DTCs

http://www.geekmyride.org/wiki/index.php/OB D-II_PIDs - Bitwise_encoded_PIDs

01 02 8 Freeze DTC

01 03 2 Fuel system

status

http://www.geekmyride.org/wiki/index.php/OB D-II_PIDs - Bitwise_encoded_PIDs

01 04 1 Calculated

engine load value

0 100 % A * 100 / 255

01 05 1 Engine coolant

temperature

–40 215 °C A – 40

01 0A 1 Fuel pressure 0 765 kPa

(gauge)

A * 3

01 0B 1 Intake manifold

pressure

0 255 kPa

(absolu te)

A

3.75

rpm ((A * 256) + B) / 4

01 0D 1 Vehicle speed 0 255 km/h A

01 0E 1 Timing advance –64 63.5 °

relative

to #1 cylinde

r

A / 2 – 64

01 0F 1 Intake air

temperature

–40 215 °C A – 40

01 10 2 MAF air flow rate 0 655.3

5

g/s ((256 * A) + B) / 100

01 11 1 Throttle position 0 100 % A * 100 / 255

secondary air status

http://www.geekmyride.org/wiki/index.php/OB D-II_PIDs - Bitwise_encoded_PIDs

01 13 1 Oxygen sensors

present

[A0 A3] == Bank 1, Sensors 1–4 [A4 A7] == Bank 2

99.2

volts

%

A * 0.005 (B – 128) * 100 / 128 (if B==0xFF, sensor is not used in trim calc)

01 14 2 Bank 1, Sensor 1:

Oxygen sensor voltage, short-term fuel trim

0

01 1F 2 Run time since

engine start

5

second

s

(A * 256) + B

01 20 4 PIDs supported

21–40

Bit encoded [A7 D0] == [PID 0x21 PID 0x40]

5

km (A * 256) + B

01 21 2 Distance traveled

with malfunction indicator lamp (MIL) on

265

kPa ((A * 256) + B) * 0.079

01 22 2 Fuel rail pressure

(relative to manifold vacuum)

01 23 2 Fuel rail pressure

(diesel)

0

kPa (gauge)

((A * 256) + B) * 10

01 2F 1 Fuel level input 0 100 % 100 * A / 255

01 30 1 Number of

warm-ups since codes cleared

01 31 2 Distance traveled

since codes cleared

5

km (A * 256) + B

01 32 2 Evap system

vapor pressure

– 8,192

8,192 Pa ((A * 256) + B) / 4 – 8,192

01 33 1 Barometric

pressure

0 255 kPa

(absolu te)

A

01 3C 2 Catalyst

temperature Bank 1, Sensor 1

–40 6,513

5

°C ((A * 256) + B) / 10 – 40

01 40 4 PIDs supported

41–60

Bit encoded [A7 D0] == [PID 0x41 PID 0x60]

01 42 2 Control module

voltage

5

V ((A * 256) + B) / 1000

01 43 2 Absolute load

value

0

% ((A * 256) + B) * 100 / 255

equivalence ratio

0 2 N/A ((A * 256) + B) * 0.0000305

01 45 1 Relative throttle

position

0 100 % A * 100 / 255

01 46 1 Ambient air

temperature

–40 215 °C A – 40

01 4D 2 Time run with

MIL on

5

minute

s

(A * 256) + B

01 4E 2 Time since

trouble codes cleared

5

minute

s

(A * 256) + B

http://www.geekmyride.org/wiki/index.php/OB D-II_PIDs - Fuel_Type_Coding

01 52 1 Ethanol fuel

percentage

0 100 % A * 100 / 255

03 N/A n*6 Request trouble

codes

Three codes per message frame, BCD encoded http://www.geekmyride.org/wiki/index.php/OB D-II_PIDs - Bitwise_encoded_PIDs

Clears all stored trouble codes and turns the MIL off

04 N/A 0 Clear trouble

codes/malfunctio

n indicator lamp (MIL)/check engine light

09 02 5x5 Vehicle

identification number (VIN)

Returns five lines, A is line ordering flag, B–E are ASCII-coded VIN digits

Have a look at parameters 0121, 014D, and 014E Yes, if you take your car to a mechanic after the

trouble light has been on for a while, they can tell exactly how long you‘ve been ignoring it Don‘t bother

trying to give them the old “it just came on yesterday” routine because they‘ll know if you‘re being

economical with the truth!

You‘ll notice that some of the parameters simply read “bit encoded” as the formula These

parameters are special cases that pack as much information as possible into only a few bytes of return

value, and special conversion rules need to be applied to interpret the values and turn them into

meaningful information Software that reads these PIDs has to know that it should treat each of these

results as a special case and have internal look-up tables that map the individual bits to specific flags

Note also the entries near the end of the table for modes 03 and 04 These are special modes that

don’t contain any parameters at all, and they need to be treated quite differently than any of the other

entries listed Mode 04, in particular, you need to be very careful of Simply by requesting that mode,

your engine-management system will immediately clear the CEL (check engine light) if it’s on, and also

any stored information about faults that might have occurred It won’t even ask for confirmation: if you

send “04” to the OBD-II adapter, it will simply execute it, no questions asked It’s generally a bad idea to

do this yourself because it means that if your car has developed a fault, any information stored about it

will be deleted and your mechanic could have a more difficult time tracking down what went wrong

This mode is normally only executed by mechanics after they’ve extracted all the diagnostic data from

your car and repaired any faults they find

Prepare the USB/OBD-II Adapter

Once you’re happy that your USB/OBD-II adapter is working as the manufacturer intended, it’s time to

open it up and locate the major components inside it

The first thing you’ll notice is that the ELM327 chip is actually a PIC microcontroller rather than a

custom IC This is an increasingly common approach to circuit design: rather than design and fabricate

a whole new IC just for one purpose, it’s often simpler and easier to use a general-purpose

microcontroller running some custom code to implement the required functionality This brings the

cost of special-purpose chips like the ELM327 way down and has the added bonus of allowing the

supplier to revise the chip design when required simply by changing the firmware No more expensive

retooling of a chip fabrication plant just because there’s a tiny bug in the design!