Silicon ChipLogging Your Every Driving Moment - November 2003 SILICON CHIP
  1. Outer Front Cover
  2. Contents
  3. Publisher's Letter: The valve circuit we said we would never publish
  4. Feature: Electronic Noses Smell A Big Future by Peter Holtham
  5. Order Form
  6. Feature: Logging Your Every Driving Moment by Julian Edgar
  7. Project: A 12AX7 Valve Audio Preamplifier by Jim Rowe
  8. Project: Our Best LED Torch EVER! by John Clarke
  9. Product Showcase
  10. Weblink
  11. Project: Smart Radio Modem For Microcontrollers by Nenad Stojadinovic
  12. Project: The PICAXE, Pt.8: The 18X Series by Stan Swan
  13. Project: A Programmable PIC-Powered Timer by Trent Jackson
  14. Feature: PC Board Design Tutorial, Pt.2 by David L. Jones
  15. Vintage Radio: The 1953 4-Valve Precedent Mantel Receiver by Rodney Champness
  16. Notes & Errata
  17. Market Centre
  18. Advertising Index
  19. Back Issues
  20. Book Store
  21. Outer Back Cover

This is only a preview of the November 2003 issue of Silicon Chip.

You can view 27 of the 104 pages in the full issue, including the advertisments.

For full access, purchase the issue for $10.00 or subscribe for access to the latest issues.

Items relevant to "A 12AX7 Valve Audio Preamplifier":
  • 12AX7 Valve Audio Preamplifier Main PCB [01111031] (AUD $7.50)
  • 12AX7 Valve Audio Preamplifier Power Supply PCB [01111032] (AUD $10.00)
  • ETD29 transformer components (AUD $15.00)
  • 12AX7 Valve Preamplifier PCB patterns (PDF download) [01111031/2] (Free)
Articles in this series:
  • A 12AX7 Valve Audio Preamplifier (November 2003)
  • A 12AX7 Valve Audio Preamplifier (November 2003)
  • Using The Valve Preamp In A Hifi System (February 2004)
  • Using The Valve Preamp In A Hifi System (February 2004)
Items relevant to "Our Best LED Torch EVER!":
  • 1W Star LED Torch PCB pattern (PDF download) [11211031] (Free)
Items relevant to "Smart Radio Modem For Microcontrollers":
  • Smart Radio Modem PCB patterns (PDF download) [06111031/2/3] (Free)
Items relevant to "The PICAXE, Pt.8: The 18X Series":
  • PICAXE-18A Temperature Logger source code (Software, Free)
Articles in this series:
  • PICAXE: The New Millennium 555? (February 2003)
  • PICAXE: The New Millennium 555? (February 2003)
  • The PICAXE: Pt.2: A Shop Door Minder (March 2003)
  • The PICAXE: Pt.2: A Shop Door Minder (March 2003)
  • The PICAXE, Pt.3: Heartbeat Simulator (April 2003)
  • The PICAXE, Pt.3: Heartbeat Simulator (April 2003)
  • The PICAXE, Pt.4: Motor Controller (May 2003)
  • The PICAXE, Pt.4: Motor Controller (May 2003)
  • The PICAXE, Pt.5: A Chookhouse Door Controller (June 2003)
  • The PICAXE, Pt.5: A Chookhouse Door Controller (June 2003)
  • The PICAXE, Pt.6: Data Communications (July 2003)
  • The PICAXE, Pt.6: Data Communications (July 2003)
  • The PICAXE, Pt.7: Get That Clever Code Purring (August 2003)
  • The PICAXE, Pt.7: Get That Clever Code Purring (August 2003)
  • The PICAXE, Pt.8: A Datalogger & Sending It To Sleep (September 2003)
  • The PICAXE, Pt.8: A Datalogger & Sending It To Sleep (September 2003)
  • The PICAXE, Pt.8: The 18X Series (November 2003)
  • The PICAXE, Pt.8: The 18X Series (November 2003)
  • The PICAXE, Pt.9: Keyboards 101 (December 2003)
  • The PICAXE, Pt.9: Keyboards 101 (December 2003)
Items relevant to "A Programmable PIC-Powered Timer":
  • PIC16F628A-I/P programmed for the "Master of Time" PIC-based Programmable Timer [MOT.HEX] (Programmed Microcontroller, AUD $15.00)
  • PIC16F628A firmware for the "Master of Time" Programmable Timer [MOT.HEX] (Software, Free)
  • Programmable PIC-Powered Timer PCB pattern (PDF download) [04111031] (Free)
Articles in this series:
  • PC Board Design Tutorial, Pt.1 (October 2003)
  • PC Board Design Tutorial, Pt.1 (October 2003)
  • PC Board Design Tutorial, Pt.2 (November 2003)
  • PC Board Design Tutorial, Pt.2 (November 2003)
  • PC Board Design Tutorial, Pt.3 (December 2003)
  • PC Board Design Tutorial, Pt.3 (December 2003)

Purchase a printed copy of this issue for $10.00.

Logging your every driving moment Some airbag controllers do more than just trigger the bags! – by Julian Edgar Did you know that the airbag control module in your car could be constantly logging a range of driving factors – includ­ing your speed? If the proliferation of speed cameras and red-light cameras isn’t enough to make you drive carefully, perhaps that piece of news just might! 14  Silicon Chip C ONSIDER THIS SCENARIO – you’ve just collided with the back of another car because you weren’t paying attention. However, you won’t be able to claim that you were braking hard if an electron­ ic record shows that you didn’t begin to slow down until the moment of impact. Or perhaps you were speeding? Once again, the electronic record will reveal all to crash investigators. Convicted by your car? – it’s more than just a possibility, with one such case having already occurred in the US. There, a driver involved in a double fatality claimed he had been travell­ing at about 100km/h. However, the electronic record logged by his vehicle’s airbag showed that his speed just five seconds before impact was, in fact, 184km/h! So what data is logged and why is it recorded? Do all air­bag-equipped cars have this facility? How can you read it? And who owns the information? The implications – not only for drivers but also for in­surance companies, the police, car rental companies and fleet owners – are profound. But if the thought of your car logging your driving behaviour horrifies you, here’s a let-off – at least for the time being. At this stage, General Motors in the US appears to be the only car company that’s wholeheartedly embrac­ing the technology. www.siliconchip.com.au In fact, GM is publicly releasing details on their systems and also working with a third party provider to make available a dedicated data reader for general purchase. The potential benefits of Event Data Logging (EDL) has also resulted in strong US Government support for adopting universal standards for such systems. In other words, due to the influence of US legislation on car makers, it’s probably only a matter of time before all cars have Event Data Logging recorded in a stan­dard format that can be easily read. Airbags have saved many lives since they were first introduced. [DaimlerChrysler] Automotive logging About 20 years ago, the fuel and ignition control in cars started a move from mechanical systems (carburettors and points) to electronic systems (EFI and electronically con­ trolled ignition). These electronic systems rely on sensors to measure various parameters, such an engine airflow, engine speed and throttle position, with an Electronic Control Unit (ECU) then making decisions about the fuel injection pulse width and igni­ tion timing. Most of these systems have the ability to detect and store faults in memory so that they can be later read out and diagnosed. It comes as no surprise then that the airbag control system not only has the ability to store data but also uses a wide variety of sensors as part of its decision making process. Howev­ er, the use of the controller as an Event Data Recorder (EDR) goes a step further – not only are fault codes stored but in some systems, the outputs from a variety of sensors are also continu­ ally logged. Early development So how did this come about? The story goes back to the early 1970s, when the US National Transportation Safety Board recommended that vehicle manufacturers gather information on vehicle crashes using on-board collision sensing and recording devices. As a result, since 1974, General Motors (GM) systems have recorded data for impacts that resulted in the triggering of the airbag (a “deployment event”), while other systems were also introduced that could additionally record “near deployment” events. Subsequently, in 1999, GM introduced a system that could also record pre-crash data – ie, data is recorded www.siliconchip.com.au to a buffer on a continuous basis and overwriting ceases immediately if a crash occurs. Ford in the US started installing EDRs in one model in 1997 and by 1999 nearly all its US models were so equipped. A range of other manufacturers either admit to some data recording or are looking to implement such strategies. Rather than use airbag control systems to record crash and pre-crash data, some US-manufactured heavy trucks use the engi­ne’s ECU instead. For example, Cummins, Detroit Die- sel and Cater­pillar all use electronic control systems on their diesel engines which also log driving data. The GM airbag system The information recorded by GM airbag systems includes data for both deployment and near deployment events. A near deployment event (ie, one where the airbag doesn’t inflate) is defined as an event that’s severe enough to “wake up” the algorithm within the control unit (an algorithm Airbag control systems read the crash deceleration pulse and decide whether to inflate the airbag(s). However, it is easy for a manufacturer to also implement logging of vehicle speed, the change in speed and other aspects such as whether the brakes are applied. [Bosch] November 2003  15 This GM airbag controller contains a full Event Data Recorder. The data logged just before and during the crash can be read either directly from the module or if the wiring is intact, from the car’s diagnostic port. [Vetronix] is used to analyse the severity of the crash pulse; ie, the control unit uses the shape and magnitude of the deceleration pulse it is undergoing before deciding whether or not to fire the airbag). Two different systems are used by GM; one stores data on the near deployment event which had the greatest change in road speed, while the other stores the most recent near deployment event. In both cases, the following data is recorded: • Driver’s Seat Belt: this is recorded as buckled or unbuckled. However, this may be recorded incorrectly if power to the unit is lost during the crash. • SIR Warning Lamp: the on/off status of the Supplemental In­flatable Restraint warning lamp is recorded. • Change in Forward Velocity: this is determined by integrating the average of four 312μs acceleration samples and is recorded in RAM every 10ms. Depending on the module, either 300ms or 150ms of this data is available. • Time To Deployment: the time in milliseconds between the start of the event (ie, enabling of the algorithm which requires two consecutive acceleration samples of over 2g) and the command for the airbag deployment. • Time Between Events – the time in seconds between a deployment event and a near deployment event, if that time is less than five seconds. • Vehicle Speed: the pre-crash speed, recorded every second for five seconds prior to any event. This information is derived from the vehicle speed sensor. • Engine RPM: engine speed, as derived from the engine manage­ ment system. As with vehicle speed, it is The BMW airbag module. The extent to which various manufacturers are logging real-time data is largely unknown but it’s possible that this unit already has this capability built in. [BMW] 16  Silicon Chip recorded every second for five seconds prior to any event. • Throttle Opening: the percentage that the throttle is open, where 100% is wide open. This information is sent by the engine management system along with engine and vehicle speeds and is again recorded every second for 5s prior to any event. • Brake Status: brakes on/off, as derived from the ABS or engine management unit every second for 5s prior to any event. Braking intensity is not recorded. • Data Validity: a check that none of the four pre-crash parame­ters (vehicle speed, engine rpm, throttle opening or brake sta­tus) is out of range or has logged faults. In addition, the number of ignition key cycles at the time of the events and at the time of download is logged, as is wheth­er or not the passenger-side front airbag has been manually switched off. One of the two GM EDR units is designed so that 150ms after the deployment algorithm has been enabled, all the data stored in the memory is permanently written to EEPROM. It then cannot be erased, cleared or altered, so this type of device must be re­placed after an airbag deployment. As a matter of interest, the Ford system records both longitudinal and lateral acceleration, the deployment strategy for the dual-stage airbag, The same control module that's used to deploy the airbags can also be used to log vehicle data before, after and during a crash. Such systems could be in widespread use in just a few years. [DaimlerChrysler] www.siliconchip.com.au seat-belt use, pretensioner operation and the fore-aft position of the driver’s seat. One reason that data from the GM system is being widely used in crash research is that the company licensed the Vetronix Corporation to build a data retrieval tool for their EDR as far back as 1999. Ford subsequently followed suit for their own EDR system. The Vetronix Crash Data Retrieval (CDR) tool consists of both hardware and software. The hardware component comprises an interface between the vehicle’s diagnostic connector (or the EDR itself where the vehicle wiring has been damaged) and a PC. In operation, the CDR system reads the hexadecimal code stored in the EDR and converts it to engineering units, making it available in both tabular and graphical forms. And the cost of this unit? – about $US2500. Data usefulness EDRs improve crash analyses, both by simplifying and im­proving the accuracy of the reconstruction process. This results in more detailed and more accurate conclusions. Table 1 summar­is­es the information available to crash investigators with and without EDRs. Before EDR, crash investigators could only rely on vehicle damage and other obvious physical signs like skid marks (less likely with ABS) in order to make major judgements. So logged data on vehicle speed and other parameters can be enormously useful. Data validity So how good is the data collected via an EDR? The answers to that question are surprisingly broad; certainly there is plenty of information available for someone who wants to fight EDR evidence in a court of law. However, on the other side of the fence, if used carefully, the data gained from an EDR is invaluable when it comes to determining the events that oc­curred before and during the crash. So just what are the potential problems? They are as fol­lows: • Problem 1: vehicle speed, engine rpm, throttle opening and brake status are logged only once per second – a sampling fre­quency that’s much too low when analysing many types of crashes. For example, did the driver brake at 3.1 or 3.9 seconds before www.siliconchip.com.au Table 1: Information Available without EDR Human Vehicle Pre-Crash Skid marks Crash Calculate change in velocity Post-Crash Crash damage Environment Environment after crash Table 2: Information Available with EDR Human Vehicle Environment Pre-Crash Seatbelt use; Throttle input; Braking Road speed; Engine speed Conditions during crash Crash Airbag data; Seatbelt pretensioners Crash pulse; Measured change in velocity; Airbag inflation time Location Post-Crash Automatic crash notification* Automatic crash notification Automatic crash notification* *Automatic crash notification refers to systems which can automatically alert authorities (eg, by mobile phone) when an accident occurs and give the location. impact? The difference is major. Additionally, this data is not synchronised with the start of the crash data and is potentially offset from the crash data by up to one second. • Problem 2: the recorded data goes back only five seconds before the algorithm enable event occurs. There is no record of vehicle behaviour earlier than this – behaviour which might show erratic driver inputs, for example. • Problem 3: the use of only five data points for each of the speed, rpm, throttle opening and brake status parameters can give a false impression; eg, if the data is plotted on a graph, with the various points connected by a straight line. In reality, the true values of any of these parameters might have been quite different between the discrete points, compared to the values indicated by the graphs. • Problem 4: most EDRs record Potential Benefits of Event Data Recorders (1). Real Time Assistance: the use of EDR data in conjunction with Automatic Collision Notification systems would aid in quick­ly locating crashes and despatching emergency personnel with better crash information in advance. (2). Law Enforcement: obtaining impartial EDR data from a colli­sion would help in more accurately determining the facts sur­rounding the incident. (3). Government Initiatives: the collection of EDR data would enable governments to introduce effective initiatives to help reduce fatalities, injuries and property loss. (4). Vehicle Design: EDRs allow manufacturers to collect accu­rate data to monitor system performance and improve vehicle design. (5). Highway Design: the use of EDR data can assist in assessing highway roadside safety and managing road systems. (6). Insurance/Legal: Additional objective data provided by EDRs advance quicker and fairer resolution of insurance and liability issues (7). Research: EDR data could provide objective data for re­searching driver behaviour and performance, as well as other research related topics. (8) Owners/Drivers: EDRs can help fleet owners and drivers monitor vehicle and driver performance, to ensure the safe and efficient movement of people and cargo. Canadian Multidisciplinary Road Safety Conference, 2001. November 2003  17 Pre-Crash Graph GM Airbag Module This dedicated reader is designed to work with GM and Ford EDR systems. It costs US$2500, putting it within easy reach of pro­fessional crash investigators and researchers. [Vetronix] Fig.1: this is a sample of the pre-crash data that is logged by the GM system, as read out using the Vetronix Crash Data Retrieval tool. Throttle opening, engine and road speed, and the on/off status of the brake switch are logged at 1-second intervals for the five seconds before the crash. [Vetronix] Post-Crash Graph GM Airbag Module Fig.2: during the crash, the change in speed is logged every 10ms, to allow a detailed examination of the impact behaviour. The airbag system’s acc­el­erometer is used in this process. [Vetronix] speed only in a longitudinal direc­ tion. However, many accidents also involve lateral as well longitudinal movement and so the speed recording may give a false impression of the events that occurred. No current original equipment EDRs record vertical accelerations. • Problem 5: where the crash does 18  Silicon Chip not involve a major decelera­tion – eg, when a large truck hits a small car or when a pedes­trian is run over – the EDR may not record the event at all. • Problem 6: vehicle speed, engine rpm, throttle opening and brake status all depend for their accuracy on sensors and/or switches. However, vehicle speed and throttle position sensors can vary by up to 10% in accuracy, a point that seems to have been overlooked by some researchers. Other research A great deal of work has gone into testing the relationship between the data gathered from EDRs and that gained through other logging techniques. One approach is to measure the vehicle’s change of velocity using the EDR and compare that figure with the crash test impact speed. A series of Canadian tests has shown that there is usually fairly good agreement between the calculated and actual speeds – eg, an actual impact speed of 40.3km/h and an EDR-calculated speed of 42.4km/h. Typically, the EDR showed a slightly higher speed because it was affected by the car bouncing back off the barrier after the collision. However, one test involving a 2000 Ford Taurus had a sig­nificantly greater difference between the actual (47.8km/h) and EDR (53.6km/h) speeds. The testers suggested that this discrepan­cy had been caused by a spike in the acceleration/time curve, caused by structural deformation in the area where the EDR was mounted. A major discrepancy also occurred in another test, where a 1988 Chevrolet Cavalier’s EDR lost power during the crash. The independently measured test speed was 64.8km/h but the EDR showed 56.8km/h. Away from the laboratory, the usefulness of the data – even with these reported inaccuracies – can be clearly demonstrated. In one case, an 83-year-old male driver of a 2000 www.siliconchip.com.au Analysing An Accident Table 3: System Status At Deployment SIR Warni ng Lamp Status Off Driver's Bel t Swi tch C i rcui t Status Passenger Front Ai r Bag Suppressi on Swi tch C i rcui t Status Igni ti on Cycl es At Depl oyment Unbuckl ed Ai r Bag N ot Suppressed 187 Igni ti on Cycl es At Investi gati on Time From Al gori thm Enabl e To Depl oyment Command C ri teri a Met (ms) Time From Al gori thm Enabl e To Pretensi oner Depl oyment Command C ri teri a Met (mil liseconds) Time Between Near Depl oyment and Depl oyment Events (seconds) Time (millisceonds) Recorded Velocity Change (MPH) Time (millisceonds) Recorded Velocity Change (MPH) 213 18.75 18.75 N/A 10 20 30 40 50 -1.54 -3.07 -3.51 -5.27 -7.68 160 170 180 190 200 60 70 80 90 100 110 120 130 140 150 -10.09 -12.29 -16.24 -21.50 -27.86 -32.69 -39.93 -42.78 -43.44 -44.32 210 220 230 240 250 260 270 280 290 300 -44.98 -45.42 -46.07 -46.95 -47.17 -47.17 -47.17 -47.17 -47.17 -47.17 -47.17 -47.17 -47.17 -47.17 -47.17 Pre-Crash Data - Electronic Data Validity Check Status = Valid Time Before A lgorithm Enable -5s Vehicle Speed (MPH) Engine Speed (RPM) Throttle Position (%) B rake Switch Status 57 4032 100 Off -4s 65 4160 70 Off -3s 62 2304 2 On -2s 55 1088 2 On -1s 47 896 2 On Buick Century was negotiating a righthand curve when he ran off the road, travelled down an embankment into brush and tall grass, then crossed a level section of lawn and a gravel driveway before finally colliding with two large rocks. The car came to rest approximately 140 metres from where it left the road. Pre-crash data obtained from the EDR indicated that the driver wasn’t operating the throttle or the brakes for at least five seconds prior to the impact with the rocks. At the crash scene, the driver was lethargic and he subse­quently died in hospital. An autopsy showed that he had died from the results of a brain haemorrhage that had occurred while he was driving – a diagnosis well supported by the EDR data. Conclusion If the US success at implementing onboard diagnostics in cars is repeated with EDR, it’s very likely that all new www.siliconchip.com.au cars will have accident crash logging in 5-10 years. So if you are ever involved in a car crash and there’s some debate about Table 3: this is a summary of the data that can be gained from GM’s EDR. Note that the driver’s seatbelt was undone and that the vehicle was travelling at 47mph (76km/h) at impact. This can be seen both in the vehicle speed and also the Recorded Velocity Change figures. [Vetronix] the circumstances, think about the implications of an EDR. It may only be a matter of time before authorities SC can access such data. Who Owns The Logged Data? While the potential benefits of EDRs are highlighted by road safety researchers, many drivers and some vehicle manufac­turers are concerned about the privacy implications. In fact, the US Federal Motor Carrier Safety Administration has stated that the following standards should apply to control­ling access to EDR data: • The vehicle’s owner should also own the EDR data. • Only the vehicle’s owner, or another party having the owner’s permission, may access the EDR data. Exceptions would include instances where a law enforcement official has a warrant for a crash investigation. • One method of assuring that only owners have access is through the use of an EDR password. • The storage and retrieval of EDR data must protect the privacy rights of the individual in accordance with law. At this stage, none of those points has been implemented, although truck owners can deactivate the EDR by setting the deceleration threshold inappropriately, giving them some measure of control over the data being collected. Certainly, there needs to be more public debate about the privacy issues involved with EDR. November 2003  19