Unintended Acceleration: Toyota ECU code somewhat short of perfect
Unintended Acceleration: Toyota ECU code somewhat short of perfect
(OP)
Not loose floor mats, not a sticky pedal, not driver error.
http://www.eetimes.com/document.asp?doc_id=1319903...
http://www.eetimes.com/document.asp?doc_id=1319903...
Mike Halloran
Pembroke Pines, FL, USA





RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
but...not proven /not/ to be the above.
I think they've shown the software isn't robust against all errors, but that's a big step from saying that as a result it has actually caused any of these incidents.
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
TTFN

FAQ731-376: Eng-Tips.com Forum Policies
Need help writing a question or understanding a reply? forum1529: Translation Assistance for Engineers
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
http://www.eetimes.com/document.asp?doc_id=1319936...;
and gets into the details of "Task X" and sloppy programming construction.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
My Daily Driver for-several-years Volvo 240 automatic's pedals are at a nice height, spacing, and position relative to the seat so that every now and then I inadvertently press both when going from "accelerating"(8D) to braking by pivoting my foot. Their response curves are such that amazingly the willing but wimpy engine power far exceeds the braking power for the first portion of the curve, so the sensation of RUN AWAY upon an application of brake is quite attention getting. My reaction to reposition my right foot has become somewhat automatic, but it certainly adds a bunch of braking distance.
I think I must have developed laziness or slightly deteriorated leg twisting motion.
I have long resisted left foot braking to avoid possible brain fade problems when changing vehicles, but LFB seems worthy of a closer look these days.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
I guess the days of expecting a semi-mechanicly literate driver to simply reach down and turn off the ignition switch are gone. Even as a young, inexperienced driver 16 year old kid, I had enough sense to kill the ignition while driving a 389 tri-power (3 carb'd 389) Pontiac with the infamous GM broken motor mount, which the owner had not told me about, when I picked up the vehicle. With the left side broken motor mount, it allowed the engine to lift up from engine torque and the throttle linkage was a perfect design for that motion to pull the throttle wide open.
I guess that would be asking too much of today's drivers... let alone throwing the transmission in neutral. The Start/stop button systems I familiar with do have hold down override to kill the engine..
Software errors, corrupt memory are not new problems, neither are the independent hardware techniques in real time controllers (independent from the main processor core e.g. dead man timers) to kill wayward code.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Mike Halloran
Pembroke Pines, FL, USA
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Yes, a typical column lock engages about 15-30 degrees off centre, it could get ugly but in practice it seems OK.
Basically, if you have your wits about you, there is usually a solution, but if you have brain fade or panic then a stuck throttle can kill you.
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Dan - Owner
http://www.Hi-TecDesigns.com
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
All the cars I have had do not lock the steering column when the key is turned to the off position, but do it when the key is pulled out of the ignition switch.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Dan - Owner
http://www.Hi-TecDesigns.com
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
However these systems go in as a sales feature, not safety.
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
I had a 79 Mustang that the choke mechanism fell off the carb and jammed the throttle about 1/2 open. I managed to drive it the last couple of miles home turning the key on and off to modulate the power. Had to run a traffic light and parked it in the front yard. Fortunately it was past midnight and very little traffic.
I remember the car mag article mentioned above. Not only could every car easily stop from 60 with the engine at full throttle but the stopping distances were only increased by ~10 feet from the best possible stopping distance. They tested a wide range of cars, some quite powerful, the results were all very similar.
----------------------------------------
The Help for this program was created in Windows Help format, which depends on a feature that isn't included in this version of Windows.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
found the article.... http://www.caranddriver.com/features/how-to-deal-w...
even consumer reports has put out a no nonsense video on methods to stop the car...
http://www.consumerreports.org/cro/cars/Unintended...
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
- Steering by wire
- Throttle by wire
- Brake by wire
- Wireless ignition enable (no key, just a START button)
And, under development are self-driving cars!In a few years, "defensive driving" will mean you carry a gun and know where to shoot the vehicle to stop it.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
http://www.edn.com/design/automotive/4423428/Toyot...
Dan - Owner
http://www.Hi-TecDesigns.com
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
I though all the Toyota's in question are push to start but I believe they all still have a shifter you can whack into neutral.
I also believed that the US regulations on the anti-theft requirements were changed in the early 2000's to only require one anti-theft lock-out instead of two. My new truck doesn't have a column lock, just the shifter lock.
I was bored one day and read through a report entitled "Toyota Sudden Unintended Acceleration" released by Safety Research & Strategies, Inc.
The NHTSA complaint text for whole bunch of reported SUA incidences was included. The typical incidence text read along the lines of "I was driving in a parking lot and right went I pressed on the brake pedal to stop the car accelerated." My opinion of these incidences was that the people caught the gas pedal with the right side of their foot when they pressed on the brake.
If you don't think stepping on both pedals would catch you off guard then I suggest you try it in a vehicle where the gas and brake pedal are close together and at similar heights. You will likely find the engine easily over-powers the brakes when you step down on the brake pedal enough to get the amount of braking you have learned you need for the stopping condition at hand. Then, when you realize you're not stopping quite quick enough you will try to brake a little harder but the engine applies more power which defeats the extra braking effort.
With an automatic and the typical factory stall converter the engine only revs maybe 500-1000rpm before it stalls and the exhaust and sound damping makes the engine rather quiet so it's not like you'll hear this high rpm screaming engine to make you immediately realize your foot is depressing the throttle.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
In military systems, certain mission critical controls are not allowed to be passed through ANY software, or have at least one hardware-only redundant path. I haven't seen anything here that positively says that the power button has such a provision. If it doesn't, then turning off the ignition might not even be possible in a SUA.
TTFN

FAQ731-376: Eng-Tips.com Forum Policies
Need help writing a question or understanding a reply? forum1529: Translation Assistance for Engineers
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Dan - Owner
http://www.Hi-TecDesigns.com
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Did the throttle go to WOT? No.
Did it return to idle? No.
What did it do? Stayed at the same opening as it was.
Is proving the above enough to win a civil suit? More then enough.
They really didn't even require a tested example. They only needed software experts to testify that bugs in software and hardware always exist and also that there was a fail safe lacking in the Toyota system. Combine the possibility of bugs existing and a fail safe that won't catch every failure and the conclusion is that it's possible the ECM can lose control of the throttle blade position. Win.
Does Toyota have issues they need to fix? Yes.
Do other manufacturers have issues they need to fix? Probably.
Did Toyota get targeted during the recession because they were taking a large chunk of market share from the bankrupt N/A manufacturers? I suspect so.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
http://en.wikipedia.org/wiki/Pentium_fdiv_bug
The Toyota problem existed well before any lawsuit or any parties with vested interest got involved.
TTFN

FAQ731-376: Eng-Tips.com Forum Policies
Need help writing a question or understanding a reply? forum1529: Translation Assistance for Engineers
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
As someone who used to write software I found the transcripts of the Toyota case rather shocking. Some of the coding practices that are revealed within the court transcripts wouldn't even fly at Microsoft, and we know what kind of crap they sell.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
I particularly love how Toyota told the courts they used ECC memory (error correction, i.e., 9th-bit), but upon inspection of actual products they were not.
And the biggest cardinal sin for me (and any other respectable embedded programmer)? Completely underestimating the amount of stack space in use at any particular moment. This is a NO-NO of the highest degree. A stack growing beyond its bounds could very easily flip the wrong bit/byte and go WOT... and there would likely NOT be a record of such an event due to its storage in RAM.
Dan - Owner
http://www.Hi-TecDesigns.com
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
http://www.nhtsa.gov/staticfiles/nvs/pdf/NASA-UA_r...
I found some key discrepancies in what the EDN author has claimed, (at least according to the posts above) compared to the NASA analysis.
Has anyone else read the NASA report?
Does anyone have a link to detailed documentation citing the enginering analysis methodology and test findings that the EDN article is based on?
Maybe it is my skepticism brought about from my experience as an product development engineer working for another company that had many frivolous lawsuits brought against it, and were successfully defended, but I like to see all information be well supported by hard evidence and test findings. Conclusions stated without this supporting data questions credibility.
Here are just a few excerpts from the 177 page NASA report..
7.1 Findings
F-1. No TMC vehicle was identified that could naturally and repeatedly reproduce large throttle opening UA effects for evaluation by the NESC team.
F-2. Safety features are designed into the TMC ETCS-i to guard against large throttle opening UA from single and some double ETCS-i failures. Multiple independent safety features include detecting failures and initiating safe modes, such as limp home modes and fuel cut strategies.
F-3. The NESC study and testing did not identify any electrical failures in the ETCS-i that impacted the braking system as designed. a. At large throttle openings (35 degrees (absolute) or greater), if the driver pumps the brake, then the power brake assist is either partially or fully reduced due to loss of vacuum in the reservoir.
b. NHTSA demonstrated that a MY 2005 Camry with a 6 cylinder engine travelling at speeds up to 30 mph can decelerate at better than 0.25g with 112 lbf on the brake while the throttle is open up to 35 degrees (absolute), with a depleted vacuum assisted power brake system.
……………..
Fundamentally, the ETCS-i uses two sets of sensors and CPUs to control the throttle and disengage the throttle control function when the sensors or CPUs do not agree. The prime sensors (VPA1 and VTA1) and the Main CPU control the intended throttle opening. The second sensors, VPA2, VTA2, and the Sub-CPU are used to validate consistent sensor data and a properly operating Main CPU. Both CPUs must agree that the throttle motor should be engaged in order for the throttle motor to drive the throttle valve open.
While the second sensors and CPU do not directly provide a means for driving the throttle, both pedal sensors are needed to indicate off idle in order to open the throttle. Either pedal sensor, throttle sensor, or CPU can declare a fault and disable and/or disengage the throttle. These sensors and CPUs are in "series" to open the throttle.
The two sensors and two CPUs are functionally arranged in a series manner, as described above, providing for two methods for closing the throttle.
……………………..
The Main CPU and Sub-CPU must be functioning and must agree that the throttle motor can be driven. Each CPU has its own oscillator, memory error detect and correct along with a watchdog that can reset the processor. The CPUs also communicate with each other to assure that both receive consistent sensor data and are functioning properly. If either CPU fails, throttle motor drive is disabled. The system is redundant to preventing a failed Main CPU from controlling the throttle.
…………………………
Two throttle sensors need to agree that the throttle valve is positioned properly. If the throttle valve does not achieve its intended position, power to the throttle motor is shut off. When the throttle position sensors disagree, throttle control is disabled and the throttle valve is returned to a spring loaded detent position of 6.5 degrees opening which is about 3 degrees more open than typical warm idle. At this point the diverse fuel cut function controls engine speed. Multiple sensors and signal sources are used to identify if the throttle motor is having trouble driving the throttle to its intended position.
……………………………
Diverse backup controls utilizing the Electronic Fuel Injection (EFI) module limit engine speed and power through a power management function employing fuel cut and ignition timing to protect the system against the consequences of unintended throttle opening due to the failure of sensors, CPU, or a mechanically stuck open throttle valve or otherwise mechanically failed throttle valve. The diverse backup is the fuel cut function that will stop fuel flow to the engine if either VPA1 or VPA2 indicate idle and the engine speed is above 2500 rpms.
………………………
6.7.2.2 Heartbeat
The heartbeat pulse train signal from the Main CPU is provided to the power ASIC and also to the Sub-CPU. The Sub-CPU watchdog pulse train is provided to the Main CPU. The Main CPU can reset the Sub-CPU and the power ASIC can reset the Main CPU and Sub-CPU. The heartbeat pulse train is software generated and acts as an external indication of proper CPU hardware and software operation.
During any CPU reset, the CPU outputs to the H-Bridge that drive the throttle motor are pulled-low, disabling the motor drive.
………………..
6.7.2.3 Watch Dog Timer
Implemented in hardware, one watchdog timer exists in the sub CPU, and one exists in the Main CPU. Each watchdog timer is initiated at startup, and requires constant re-initiation by software. If a watchdog timer expires without being re-initiated by software, the CPU hardware is reset and restarts. The software function that re-initiates the watchdog timer executes in the lowest priority task. If this lowest priority task does not execute, it indicates abnormal processing or timing within either the software or hardware.
During watch dog timer reset, the CPU outputs to the H-Bridge that drive the throttle motor are pulled-low, disabling the motor drive.
6.7.2.6 Software Data Checks
A subset of software data is protected by implementing software data mirroring. When the data is written, a second location is written with the complement of the data. When the data is read, the second location is also read and checked. If the check fails, a default value is used.
When this software data mirroring is used, it protects data from being overwritten, such as by stack or buffer overflows.
6.7.2.7 Fuel Cut and Electronic Fuel Injection (EFI) and Ignition
When the pedal position sensors indicate the driver foot is off the pedal, a fuel cut function is used to limit maximum engine speed. An exception is when cruise control is engaged. When cruise control is engaged, this fuel cut function is disabled.
The moment the pedal is disengaged, the engine speed is sensed, and this level determines whether fuel cut is enabled. Fuel cut is enabled when this engine speed is above the fuel cut threshold. Following fuel removal from the engine, the speed decreases. When the engine speed reduces below the fuel cut recovery threshold, fuel is restored to the engine.
6.7.3 Software Study and Results
The software study applied analysis and modeling tools to the actual MY 2005 Camry source code. Models were developed of functional areas to achieve an integrated understanding of the system behavior and simulations were run on these models to explore areas of interest. These simulations were confirmed against vehicle hardware, and the models were further refined. Ultimately, the software study supported the development of specific vehicle hardware tests.
................
Major CPU and software failures are protected through Sub-CPU and Main CPU checks, watchdog, heartbeat, and voltage monitoring. Data corruption is protected through EDAC and software-implemented data mirroring. Data limits are applied to detect sensor and output failures.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Basically, NHTSA was outmaneuvered, and accepted a priori constraints, so NASA was tied to a chair and blindfolded, only allowed to inspect the source code and not allowed to test the binaries, stuff like that.
The exercise was a sham, and everyone knew it.
Mike Halloran
Pembroke Pines, FL, USA
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
I have yet to read anything that explained how the code caused the 100's of reported incidents where the car was idling through a parking lot and then took of when the driver pressed on the brake. Claims that "it could" but nothing beyond that.
I agree with Dan that underestimating the stack space being used was one of the big sins in the stuff I read.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
The EDN article is based on Barr's report. Mr Barr described it and the methodology behind it in court. I read the court transcript when it originally turned up on the net, but unfortunately it has since been pulled. His slides however, as still available if you poke around.
Barr make several references to his findings contradicting NASA's. He claimed two main reasons: NASA were misled by Toyota (eg. Toyota said they used ECC RAM, but on inspection they didn't); and NASA had very limited time and access to the code.
Mr Barr seems, based on the transcript, to be an excellent code reviewer. He's also an excellent communicator. He put together a very convincing case that the code was unsatisfactory. Not only was the quality of the code poor, their review and tracking procedures were sorely lacking. This is beneath what we would want to believe a car manufacturer adheres to.
At one point he says to the judge:
A. So ultimately my conclusion is that this Toyota electronic throttle control system is a cause of UA software malfunction in this electronic throttle module, can cause unintended acceleration.
Q. And I know we will get to it later, but ultimately you have a conclusion that it also was the cause of the wreck in this case?
A. I do.
He based that on an 18 month review of the code. He found that while many variables were mirrored, critical values weren't. There was no error detection and correction codes on those critical values. Stack overflow was possible. It had high complexity metrics (67 functions score >50 where 30 is considered the maximum releasable). There were many global variables (over 11000), at least one buffer overflow, an invalid pointer dereference (humorously reported as a "pointer D reference" in the court transcript), a race condition, it had lots of MISRA-C violations (in fact it violated about a third of their own internal cut-down version of MISRA-C), and they even had a hardware timer kicking the watchdog. He said indications are that Toyota lacks engineering discipline and rigor, their peer-review was inadequate and they have no bug-tracking system. He said the code looked fragile (ie. fixing one bug would likely create more), and resembled spaghetti code, probably due to its evolution (from assembly to C, adding an OS, adding major core functions).
They constructed a test with the 2005 Camry on a dynometer and the code running. They manually flipped a bit, causing a task to die. They then hit resume on the cruise control, which cause the throttle to open. But because this particular task was dead, the set point wasn't set and the car continued accelerating past the intended speed. They then hit the brake, the cruise control is cancelled and the car stops. No big deal (provided you noticed the speed was too high). However, if the brake is already depressed, even slightly, and this scenario occurs (bit flip, task death, cruise control resume, continuous acceleration) then the throttle stays open even if you press the brake harder - you actually have to lift off the brake and press it again to cancel the acceleration.
I wasn't present in the courtroom and it would take me days to read the whole transcript, but from what I have read it seems pretty clear to me that Mr Barr is an excellent embedded software engineer and in particular has a keen appreciation of safety critical review principles. He put together a strong case that Toyota's software methods were less than what we'd hope for a car manufacturer. Then, by virtue of some terrible cross-examination, he leads the jury to assume that the software bugs could have caused the accident. I remain unconvinced that the software had anything to do with the crashes. There's nothing to suggest that simply applying the brakes correctly would not have prevented the accidents. Ultimately some humans in cars screwed up, got injured, and the subsequent investigation has revealed some shoddy code.
I suspect, with no proof, that the code reached that state iteratively - I could well imagine it started with the best intentions and best practices. Then, as budgets dwindled, management got jumpy, and feature request/bug fixes got thrown in at the last minute, the code got messy and the review process fell away. The team probably consoled themselves by enormous system tests - in 1000's of km of testing, not one issue, so the crappy code works. It looks like rubbish, but it works.
I agree underestimating stack space usage is a fatal error, but I think there's an argument to be had here - if in all the system testing no more than, say 35% (I can't remember the actual number) of the stack is used, then provided you have good code coverage etc., you can have a high degree of confidence that the stack won't be exhausted. If you take the academic approach, as Barr does, and add up all the function calls, including calls by function pointer and other indirect methods, then you could get a value greater than 100% - even though it will never happen in practice!
I think similar arguments could be made for many of the other criticisms - sure, the end result is embarrassingly unsatisfactory in the cold light of day, but I can just imagine the engineers crying out during development, "we need to fix this, it looks like crap!", and management saying, "you'll just introduce new bugs, we'll have to re-do all the testing, we'll be six months behind and have no new features that the customer cares about!"
An epilogue to consider: suppose Joe Engineer designs a new brake system with superior wear characteristics. John Citizen then buys a car with Joe's brakes. John starts at the top of Lookout Road and rides the brakes all the way to the bottom, "to test them". At the bottom he approaches a stop sign, steps on the brake and finds them ineffective. He ploughs through the stop sign and kills a kid on a push bike. John takes Joe to court and brake expert witness Barb tells the court that all brakes are subject to brake fade. She then tells the court that in all Joe's drawings she couldn't find any reference to what would happen if someone tried to test the brake's wear characteristics by subjecting them to sustained heat from braking. The court realises that the superior wear characteristics encouraged John to try them out, possibly leading to the crash. Joe gets sued. Joe quits engineering, realising that being responsible for introducing superior technologies to the world is not enough reward for being liable for John Citizen's inability to operate a car correctly.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Dan - Owner
http://www.Hi-TecDesigns.com
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
From the reviews of the code, it sounds like TMC ignored (or were forced to ignore via mismanagement and feature creep) these design guidelines, then breathed a sigh of relief when it "worked."
How is this different from designing a structure by intuition instead of by code/standard?
Is there such a thing as a Software Engineering PE?
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Not specifically, just that an ECU is almost universally superior to a mechanical throttle.
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
It's one thing to make educated guesses on a cellphone stack, get it wrong, and add in more stack space when you get multiple reports of phones resetting during heavy usage. To make the same mistake on a safety critical system approaches the criminal... a programmer should KNOW how bad things can get and plan for it accordingly. Not knowing how deep your branch surfing will get you is simply poor code management.
Dan - Owner
http://www.Hi-TecDesigns.com
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
TTFN

FAQ731-376: Eng-Tips.com Forum Policies
Need help writing a question or understanding a reply? forum1529: Translation Assistance for Engineers
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Dan - Owner
http://www.Hi-TecDesigns.com
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Wasn't the only fubar, but it was a major one.
TTFN

FAQ731-376: Eng-Tips.com Forum Policies
Need help writing a question or understanding a reply? forum1529: Translation Assistance for Engineers
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Strictly speaking, the ECU only replaces the mechanical cable between its attachment points at the pedal and the throttle shaft's arm or sector. You still need mechanical devices to inform the ECU what's going on (at both ends, now) and ultimately accomplish the intended vehicle control. It has the potential to do some things better and do some things that a cable can't even do at all, but even that falls somewhat short of "almost universally superior".
Norm
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
In practice, some of the ones I've tried sucked greatly.
They tried to second guess me - the damned things didn't follow directions.
I ease into the gas, it ignores me. I ease some more, it still ignored me. I guess it thought I was doing it accidentally?
Finally I have to mash on the bastard, 'cause the event that I previously had plenty of time to avoid is now bearing down on me!
I've seen this on a Mazda ('08 or so?)several years ago, present but not as bad on a '13 Impala.
Our '04 Beetle isn't too bad.
Jay Maechtlen
http://www.laserpubs.com/techcomm
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
Norm
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
The Beetle is ours, and I notice the behavior a bit - but it doesn't manifest under my wife's driving pattern.
Maybe my driving pattern confuses the computer. (?!?)
cheers
Jay
Jay Maechtlen
http://www.laserpubs.com/techcomm
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
RE: Unintended Acceleration: Toyota ECU code somewhat short of perfect
And I really don't think it was dead band at the end of the sensor travel - because I was driving along, then asked for a wee bit more - and the SOB ignored me.
I am very accustomed to the subtle signals of an engine's varying load/output.
Not that the Mazda was particularly subtle.
Jay Maechtlen
http://www.laserpubs.com/techcomm