Practical Arduino Cool Projects for Open Source Hardware- P33 ppsx

CHAPTER 15  VEHICLE TELEMETRY PLATFORM 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. 299 CHAPTER 15  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. 300 CHAPTER 15  VEHICLE TELEMETRY PLATFORM 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 301 CHAPTER 15  VEHICLE TELEMETRY PLATFORM 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 302 CHAPTER 15  VEHICLE TELEMETRY PLATFORM 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. 303 CHAPTER 15  VEHICLE TELEMETRY PLATFORM 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. 304 CHAPTER 15  VEHICLE TELEMETRY PLATFORM 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 Mode PID Bytes Description Min Max Units Formula 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. Bit encoded. 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. Bit encoded. 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 01 0C 2 Engine RPM. 0 16,38 3.75 rpm ((A * 256) + B) / 4 01 0D 1 Vehicle speed. 0 255 km/h A 305 CHAPTER 15  VEHICLE TELEMETRY PLATFORM 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 01 12 1 Commanded secondary air status. Bit encoded. 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 0 1.275 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. 0 65,53 5 second s (A * 256) + B 01 20 4 PIDs supported 21–40. Bit encoded [A7 D0] == [PID 0x21 PID 0x40] 0 65,53 5 km (A * 256) + B 01 21 2 Distance traveled with malfunction indicator lamp (MIL) on. 0 5177. 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 65535 0 kPa (gauge) ((A * 256) + B) * 10 01 2F 1 Fuel level input. 0 100 % 100 * A / 255 306 CHAPTER 15  VEHICLE TELEMETRY PLATFORM 01 30 1 Number of warm-ups since codes cleared. 0 255 N/A A 01 31 2 Distance traveled since codes cleared. 0 65,53 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. 0 65.53 5 V ((A * 256) + B) / 1000 01 43 2 Absolute load value. 0 25,70 0 % ((A * 256) + B) * 100 / 255 01 44 2 Command 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. 0 65,53 5 minute s (A * 256) + B 01 4E 2 Time since trouble codes cleared. 0 65,53 5 minute s (A * 256) + B 01 51 1 Fuel type. From fuel type table. http://www.geekmyride.org/wiki/index.php/OB D-II_PIDs - Fuel_Type_Coding 307 CHAPTER 15  VEHICLE TELEMETRY PLATFORM 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! 308 . setup of GPS) Source code available from www.practicalarduino.com /projects/ vehicle- telemetry-platform. 299 CHAPTER 15  VEHICLE TELEMETRY PLATFORM Figure 15-4. Parts required for vehicle. platform Figure 15-5. Modular structure of vehicle telemetry platform. Schematics of individual modules are included later in the project. 300 CHAPTER 15  VEHICLE TELEMETRY PLATFORM. 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