CHAPTER 15 VEHICLE TELEMETRY PLATFORM generated by the system is a regular CSV file using the fields specified in Table 15-13, so you can open it with a text editor or spreadsheet program. Table 15-13. Fields stored in CSV logfile Column Field Description 1 GPS_LAT GPS latitude 2 GPS_LON GPS longitude 3 GPS_ALT GPS altitude in meters above sea level 4 GPS_SPEED GPS speed in km/h 5 LOAD_VALUE Engine load in % 6 COOLANT_TEMP ECU coolant temperature in C 7 ENGINE_RPM Engine RPM 8 VEHICLE_SPEED Vehicle speed in selected units 9 TIMING_ADV Timing advance in degrees 10 INT_AIR_TEMP Intake air temperature 11 MAF_AIR_FLOW Mass air flow 12 THROTTLE_POS Throttle position in % 13 FUEL_RAIL_P Fuel rail pressure in kPa 14 FUEL_LEVEL Fuel level in % 15 BARO_PRESSURE Barometric pressure 16 AMBIENT_TEMP Ambient temperature 17 FUEL_CONS Fuel consumption rate 18 BATT_VOLTAGE Battery voltage 379 CHAPTER 15 VEHICLE TELEMETRY PLATFORM Generate Google Earth Track Included with the project source code is a directory called OBDtoKML that contains a simple PHP script called obd-to-kml.php. This script takes a logfile and extracts the latitude, longitude, and vehicle speed, and then uses them to generate a KML file that can be opened in Google Earth. Note, though, that it’s not intended to run on a web server: even though it’s written in PHP it’s designed to be executed directly like a shell script. You need to have the CLI (command-line interface) version of PHP installed and also set execute permissions on the script. Then you can launch it just like any other script. The script takes a single argument, which is simply the name of the logfile to convert, and then creates a new file in the same location but with a .kml extension tacked on the end. For example, on a Linux or Mac OS machine with a logfile sitting on the desktop, you could open a terminal and execute. ./OBDtoKML/obd-to-kml.php ~/Desktop/OBDUINO.CSV You’ll then end up with a file at ~/Desktop/OBDUINO.CSV.kml that you can open in Google Earth. For Linux users, we’ve also included an obd-to-kml.desktop file that allows you to drag and drop your logfile onto the icon and have it converted in one easy action. If Google Earth is associated with the .kml extension and everything is set up correctly, generating a track of a logged trip is as simple as the following steps: 1. Insert the memory stick into the computer. It should open automatically. 2. Drag the logfile onto the obd-to-kml icon. 3. Double-click the resulting .kml file to launch Google Earth and open the track. Inside the script, you can see it extracts the values for all the data fields even if it doesn’t use them, so changing it to plot a different parameter, such as RPM against location, is trivial. Just change the parameter near the end of the script where the output line is generated and run it again. If the resulting .kml file doesn’t seem to work, it’s quite likely that the original data included invalid lines such as GPS coordinates returned as “0.000”. If you open the generated .kml file in a text editor and scroll through it, you may see obviously bogus lines. Simply delete them, save the file, and reload it in Google Earth. Generate Charts of Parameters To plot parameters, start by opening the logfile in a spreadsheet program, and delete the columns you don’t care about. Most spreadsheet software includes charting tools that let you select data ranges and generate various charts from them. If you don’t have a spreadsheet program installed on your computer, you can also use free online services such as Google Docs, importing the logfile into an online spreadsheet and then generating a chart from there. Variations Keep in mind that modifying a car is potentially hazardous to yourself and also to other drivers, passengers, and pedestrians, and some of the suggestions here may not even be legal in some parts of the world. Please use your own common sense and obey any relevant local regulations. 380 CHAPTER 15 VEHICLE TELEMETRY PLATFORM Mobile Internet Connection Mobile broadband modems that use 3G networks to provide high-speed Internet access while mobile are now commonly available, and some providers such as Three in Australia also have available a mobile broadband router that uses a 3G modem to provide wired Ethernet connectivity. By adding an Ethernet shield to the Vehicle Telemetry Platform, you could have your car connected to the Internet and potentially accessible from anywhere in the world. One trap to be careful of, though, is to use a provider who doesn’t use private, nonroutable IP addresses or you won’t be able to connect to your car. Vehicle Control In this project we used the Arduino to collect and report on data from the car, but you could also extend it to control the car itself. The Mega has plenty of spare I/O lines, so by adding some relays and modifying the wiring loom of your car, you could set it up so the Arduino can lock, unlock, start, and stop the car. One of the authors has even combined this with a constant mobile Internet connection via 3G broadband so that his car can be started, stopped, and tracked, and the engine-management data interrogated live from anywhere in the world using nothing more than a web browser. You can learn more about it at www.geekmyride.org/wiki/index.php/Jon’s_RX-8. Speech Synthesizer Output Ever since Kitt appeared in “Knight Rider” in the early 1980s, every teenage boy has wanted a car that can talk. Extending the Vehicle Telemetry Platform to include a speech synthesizer would be relatively simple using the design of the speech synthesizer shield described in Chapter 9. The output of the synthesizer could be fed into the vehicle sound system to have voice prompts played through it. 3D Accelerometer By integrating the speed data from the OBD-II interface, you can calculate linear acceleration, and by doing the same to the positional data returned by the GPS, you can generate acceleration in other axes as well, but at fairly low accuracy. Using an I2C connection, you could add a Wii Nunchuck controller and read X, Y, and Z axis accelerometer values to be stored along with the other data. Digital Compass The GPS module can approximate heading based on successive position fixes, but you could add a simple magnetic compass module with an I2C interface to allow the system to display an accurate heading value. “Knight Rider”–Style Alarm Status If the carAlarmScreen option was enabled at build time, the displayAlarmScreen() function is invoked when the engine isn’t running. It simply displays a scanning asterisk on the LCD, but because the Mega has plenty of spare I/O pins, it would be easy to connect up a row of LEDs and have this function drive a “Knight Rider”–style scanner as well, if you wanted something a bit more attention-grabbing. 381 CHAPTER 15 VEHICLE TELEMETRY PLATFORM 382 Battery Condition Check The ELM327 provides a battery voltage reading even when the car isn’t running because it’s permanently connected to an unswitched battery line. Periodically reading the battery voltage when the car isn’t running could allow the Vehicle Telemetry System to turn off other devices in the car if necessary—or even turn itself off! Resources This project is very heavily based on the OBDuino project at www.ecomodder.com. Make sure you check out the EcoModder site for lots more information about OBDuino, MPGuino, and ways to improve the fuel economy of your car. The VDIP1 module and all its commands are very well documented on the Vinculum site at www.vinculum.com. C H A P T E R 16 Resources In the project chapters of Practical Arduino we covered a range of electronics topics using real-world examples. In this chapter, we provide a little grab bag of additional electronics techniques and topics that you might find useful. On the Practical Arduino web site, you’ll find a complementary set of hints and tips on the software side of Arduino development. We elected to split things in this manner, as the software side of Arduino is moving relatively faster than the electronics topics we wanted to cover. Simple Voltage Regulators Often your project will need regulated power beyond what can be tapped from the Arduino board itself. One of the simplest ways to achieve this is through the use of a three-terminal regulator. The most common of these are the 78xx series parts where xx is the output voltage—05, 06, 08, 12, 15 for 5V, 6V, 8V, 12V and 15V outputs, respectively. Figure 16-1 shows a simple 5V supply based on a 7805. Most of the components other than the regulator and 0.1µF capacitor are optional. We include them because it represents good design practice. The capacitors all serve to help the circuit deal with transient demands from the connected circuitry. The 0.1µF part helps the regulator remain stable, so it’s good practice to install it and have it as close as reasonably possible to the regulator itself. The diode back across the regulator limits how much current will flow back into the regulator from the capacitors on the output side when the input power is removed. Figure 16-1. Simple 5V regulator circuit 383 CHAPTER 16 RESOURCES The attraction of the 78xx series regulators is that they are pretty much built-in and they come preset to the voltage required and can cope with an input voltage of 10V or 20V above the output voltage. However, there are a few catches to be aware of, chief among them being power dissipation and dropout voltage. Power Dissipation In a so-called “linear regulator” circuit such as this, the voltage regulator device itself is effectively acting like a resistor in which the value changes as required to maintain the desired output voltage. Thus, if the input of the regulator is at 12V and the output at 5V, the regulator circuitry acts like a resistor of the value required for the 7V difference to be absorbed by the regulator. Therefore, the power that “disappears” in the regulator is converted into heat. The more current that is flowing through the regulator, the more power (heat) that 7V will amount to. The regulator must dissipate this heat safely; otherwise it will shut down or, in extreme cases, be damaged. For example, at a 100mA current draw the regulator must dissipate 0.7W into the environment. For the most common package type 7805, a TO-220 pack that has a metal tab at the rear of the device and dissipation up to about 0.5W without a heatsink is usually fine. Anything beyond this and the tab should be attached to a heatsink or a metal chassis. It’s important to note that the tab is connected to ground, so it’s usually desirable to electrically insulate the regulator from the heatsink or chassis. Thermally conductive washers that do this are readily available. Dropout Voltage The second characteristic to consider is dropout voltage—the difference between input and output voltage, below which the regulator isn’t guaranteed to operate correctly. For 7805 parts, this voltage is 2V, so ideally you should ensure that the input voltage is always above 7—tricky if you’re using a 6V battery pack. Low dropout (LDO) regulators exist that minimize this value down to 0.5V or less. Parts to investigate include the LH117, LM2940, and LM3940 series. Being readily available, there’s a good argument to standardize on these instead of the 78xx parts. Efficiency Linear regulators are quite inefficient, as by design they convert all the excess power into heat. In many applications this is outweighed by their design simplicity, but for battery-powered applications, as well as the growing focus on energy efficiency, this might not be an acceptable trade-off. In these circumstances, we suggest you investigate switch-mode regulators, which while more complex to design with, have far greater flexibility and efficiency. We leave this as an exercise to the reader, however! Driving LEDs LEDs have been used in a number of projects in Practical Arduino to provide a simple indication of status. These previous examples have used LEDs in quite straightforward applications. In this section, we discuss LEDs in more detail and introduce a few ways of driving them. LEDs are diodes that emit light. Like diodes, they have a forward voltage drop (V f ) as well as maximum and peak forward current ratings (I max and I peak , respectively). These values vary among LEDs 384 CHAPTER 16 RESOURCES and can be found on the datasheet for the specific LED you have chosen. In the absence of a datasheet, some rules of thumb are as follows: • Modern red LEDs have a forward voltage drop (V f ) of 1.5–2.2V. • Green LEDs have a V f of 2–3V. • Blue LEDs have a V f in of 2.5–3.5V or more. • Yellow LEDs have a V f of 1.5–2.5V. • White LEDs have a V f of 3.5–4V. LEDs have a fairly sharp cutoff voltage below which they don’t produce any light at all. Typically, this is a few tenths of a volt below V f . Maximum continuous forward current for 5mm LEDs will be in the range 15–70mA, and exceeding this will likely damage the LED over time. Peak currents are usually of the order of three to five times the continuous rating for 5mm LEDs, but can be considerably higher for larger LEDs—amps in some instances. Like most devices, LEDs are susceptible to damage when they overheat, which will occur if the average power dissipation is too high. This damage can be subtle, such as a reduction in lifetime and slowly decreasing output, or more rapid if you operate far outside the ratings. Higher power LEDs (in the 1–3W plus range) are normally designed to have some sort of heatsink attached. If you’re using an LED as a simple status indicator as we have in many of the Practical Arduino projects, put a 200–300Ω in series with it and move on. The exact figures previously given aren’t going to come in to play! However, if you’re dimming LEDs using PWM or are multiplexing/charlieplexing them, a little more nuance is required in your design. Multiplexing Multiplexing is a very common way of driving LEDs, particularly when they are assembled as either a dot matrix display or a number of seven-segment/numeric displays. Multiplexing relies on the fact that if a light source is switched on and off fast enough, the human eye perceives it as being continuously lit even though it is in fact only on for a brief period. Figure 16-2 shows a two-digit seven-segment display connected to an Arduino. Note that the seven segments are connected directly to the Arduino output pins and the “common cathode” of the display (all the LED cathodes) are connected through a transistor to ground. These bases of the transistors are, in turn, connected to an output pin on the Arduino. 385 CHAPTER 16 RESOURCES Figure 16-2. Schematic for a two-digit seven-segment multiplexed display In order to display two different numbers on each display, we use a procedure much like the following: repeat { Set Outputs 3 to 9 as required for first digit; Turn Output 1 On; Delay; Turn Output 1 Off; Set Outputs 3 to 9 as required for second digit; Turn Output 2 On; Delay; Turn Output 2 Off; } If we repeat this rapidly enough, our eye will perceive both displays as being continually lit showing the digits we want. The general idea can, of course, be expanded to more digits—four or six for a clock, for example, and this is precisely how most LED clocks work. Multiplexing doesn’t come entirely free. Because the LEDs aren’t on all the time, they appear dimmer. In our example, the duty cycle (ratio of “on” time to “off” time) for each display is 50%. For a four-digit display, it would be 25%, and so on. To get around this, we can increase the current being sent to each display, this being where the peak current rating of the display becomes important. For a typical seven-segment display, it’s likely to be acceptable to increase the current to 50mA per segment. Higher than that, start checking datasheets and doing some calculations to ensure you don’t overstress the devices. By driving the LEDs with a higher 386 CHAPTER 16 RESOURCES peak current, they output more LED for the time they are on so they appear brighter. They also have time to cool during the off time, hence avoiding damage. There is a caveat with driving LEDs at their peak, rather than constant, current rating: it’s very important that your software doesn’t inadvertently leave them on too long, or the device can be damaged. This can be problematic during development/debugging if your code crashes with the LEDs in an on state. It is prudent to do initial coding with the LED or display run with resistors chosen to keep it at its constant current rating. The next issue with multiplexing is that, of course, the ATMega must update the state of the LED or display at regular intervals. This reduces the amount of processor time available for other tasks. With careful design, the impact of this can be minimized, but should be taken into account. Consider using a periodic interrupt to do the display updates. Charlieplexing Charlieplexing is a technique that can be used to maximize the number of LEDs or switches that a microcontroller can address with a limited number of pins. It makes use of the fact that a modern microcontroller (ATMega/Arduino obviously included) can actually set its pins to one of three states: High, Low, or Input (“Hi-Z” as it is sometimes called). We’ll confine our remarks here to driving LEDs. The Practical Arduino web site has links for references on this topic, if you wish to read up on more exotic setups, as well as links to the original articles on the topic. Figure 16-3 shows two LEDs connected between a pair of Arduino output pins through a dropping resistor. Note that the LEDs are connected with opposite polarity. Two pins to drive two LEDs is hardly remarkable, but bear with us a moment and we’ll illustrate the basic principle. Figure 16-3. A two-pin charlieplexed LED display To turn LED1 on, we would make Output1 High, and Output2 Low. For LED2 we’d do the opposite: Output1 Low and Output2 High. To turn the LEDs off, we can either set the pins to be inputs or the outputs to be the same state (both Low or both High) Figure 16-4 shows a more interesting arrangement. Here we drive six LEDs from just three pins by making use of the Arduino’s ability to set a pin to be an input or an output in a high or low state. Referring to the diagram, to turn LED1 on, we’d set DIO1 to be an output and to be high, DIO2 to be an output and low, and DIO3 to be an input. LED2 would be turned on by DIO1 being an output and set low, DIO2 being an output and set high, DIO3 still being an input. Jumping around, LED4 you’d set DIO1 to be an input, DIO2 to be low, and DIO3 to be high. LED6 would call for DIO1 to be low, DIO2 to be an input, and DIO3 to be high, and so on. A bit of thought and careful programming will allow you to create a general-case piece of code that can turn on any LED required. 387 CHAPTER 16 RESOURCES Figure 16-4. A three-pin six-LED charlieplexed display You’d be correct to wonder why when LED6 is on, LED1 and LED3 aren’t. They’re connected between the same pins, after all, and with the correct polarity. The answer here is the forward voltage drop—there isn’t a high enough voltage across the two LEDs when connected in series to allow them to light because it’s below the threshold or V f level. If, as is often the case, you want to have more than one LED on at a time, you can use a multiplexing arrangement, switching to each LED in turn in rapid succession. Avoid the temptation to simply skip an LED that is off. If you do so, then the brightness of any LED that is on will change depending on how many LEDs are on at any one time. Of course, if the number of LEDs that are on is constant—as would be the case for hands on a clock, say—that would be acceptable. LEDs that are off can be skipped completely in such a case. As noted in the previously, you’ll need to consider running the LEDs at higher currents to keep the brightness up, and the same caveats about duty cycle come into play. Finally, note that the current-limiting resistors are half the value you’d normally expect to use. This because the LED being driven is always being powered by the Arduino through two pins and, hence, two dropping resistors. If you’re curious, the general case for the number of LEDs that you can drive from n pins is n 2 – n. For example, eight DIOs yield 56 LEDs; 12 DIOs yield 132 LEDs; and so on. That’s a lotta LEDs! Output Circuitry and Isolation The ATMega168, like all microcontrollers, is limited in its ability to provide current to external devices. When the internal drive capabilities are insufficient, it is necessary to employ additional circuitry to correctly and safely switch the load in question. Before considering the type of device that best suits your application, you need to consider four parameters: current, voltage, switching frequency, and isolation. The first three are, in a sense, hard numbers; the final is more of an engineering decision. Current and voltage are interrelated (as we discussed in Chapter 1), so switching high currents at low voltages is a different engineering problem than low currents at very high voltages, for example. For the purposes of this discussion, we can consider high voltages to be anything over 24V, and high currents as anything over a few hundred mA. Switching frequency will vary enormously with application. Isolation, as the name suggests, is the practice of having electrical and/or physical separation between two parts of a circuit, typically the “low” and “high” power sections. Isolation is necessary for safety reasons when high voltages are involved and/or mains switching is the task at hand. It can also be 388 . LEDs have been used in a number of projects in Practical Arduino to provide a simple indication of status. These previous examples have used LEDs in quite straightforward applications. In this section,. the Vinculum site at www.vinculum.com. C H A P T E R 16 Resources In the project chapters of Practical Arduino we covered a range of electronics topics using real-world examples and topics that you might find useful. On the Practical Arduino web site, you’ll find a complementary set of hints and tips on the software side of Arduino development. We elected to split things