By accessing this website, you acknowledge that Edmunds and its third party business partners may use cookies, pixels, and similar technologies to collect information about you and your interactions with the website as described in our
Privacy Statement, and you agree that your use of the website is subject to our
Visitor Agreement.
Comments
that was an exciting landing for sure, but some of that software and hardware could only be tested in-situ. talk about mission critical though.
in contrast, for vehicle manufacturers, they have much better development tools than there was 4 decades ago, and a lot less time pressure (remember we were in a race with the Soviet Union with a deadline proposed by Kennedy) than NASA had to deal with.
the environment with which to test vehicle controls is much more human-friendly and safe than for spacecraft back then, so there is both time and other luxuries available to engineers on the ground which we didn't have in space to "get it right" back in the mid-60s.
---
i think people buy certain manufacturer's products because of perceived reliability and low-cost of maintenance. with increased complexity will come increased visits to the dealership, increased bizzare and "non-repeatible behaviors" experienced by the customer, and an errosion of perceived quality if left unchecked.
i'm not talking just engine / transmission controls... environment (lighting, heating, cooling), navigation, safety (abs, trac, stability), suspension and steering, etc etc.
i think we will get more and more reports from end users that new-product introductions have increasing number of non-conformities requiring SW patches.
how much of this automation do we actually need, and how much of it is being pushed upon us by the companies developing it? we need to ask ourselves what we should really value, and force the manufacturer's to provide that.
do we want a future where as we drive, the automobile receives updates via satellite download which we can choose to install or not?
i 4 1 think not.
Lexus is a pretty "hi tech" automobile and the state of the art features must be part of the attraction. But how much multiplexing and complexity layers can you pile on before you reach diminishing returns?
At some point, doesn't complexity REDUCE reliability? Maybe Toyota has hit the wall here. with other manufacturers soon to follow.
or perhaps Toyota had a longer run than most other manufacturers and finally got bitten too.
hard to tell.
If it's good for a Lexus ( maybe?) then why is it not being touted for a Camry V6, which I thought had the same 5 speed?
And I am still a little confused why, if this has been a peristent probelm for several years, it is not fixed as of yet.
It is really hard for me to believe that Toyota is sitting on a problem this long, hoping everybody will go away?? Or am I just 'wet behind the ears??
We have speculated in the forum why Toyota has not done something sooner. I side with the theory that the real fix would result in violations of EPA and other standards, which could subject Toyota to huge fines.
Sounds like it isn't even available to all Lexus ES330 owners yet.
Looking forward to hearing your impressions. By the way, what yr/model/engine are you driving? And does your vehicle have a special Cali emission system?
Also you might ask the dealer's service manager to check and see if the factory is over-filling the transaxles intentionally. There seems to be too many owners reporting ATF overfill for it to be an accident.
I am NOT questioning whether or not a fill to the low mark for cool or the hot mark when hot would or would not provide an adequate level of ATF for normal operation. What I am trying to say is that NONE of us have any way of knowing how much of an overfill would create a problem.
How much of an overfill would you need to have the dynamic, running, fluid level high enough to be frothed, whipped, by the spinning gears?
35290-45010 SOLENOID ASSY, LINE
35168-21010 GASKET, TRANSAXLE OI
00279-000T4-01 ATF T-IV QUART
00289-2BCOO NON-CHLOR BRAKE CLNR
369991 R&R TRANS MOUNT, PAN, VALVE BDY TO CLEAN & REPLACE SOLENOID, GASKET, RESET ECM MEMORY & ROAD TEST
Note: "Fluid was drained and refilled during repair to correct level"
As most posters know, I have been very aggressive in finding a solution to our hesitation, indecisive shifting etc. issue. A few weeks ago, I had the ECU reset which did little or nothing to improve the shifting. A month ago, I disconnected the negative terminal for 10 minutes, which did little or nothing. I will not be premature in informing all posters by saying that my car is "FIXED". I am aware that the car may relearn my driving pattern and revert back to the awful shifting, shuttering, hesitating, lurching, etc. HOWEVER, I must report that while I have only driven it about 30 miles, it feels like a completely different car. So far, it upshifts and downshifts absolutely seamlessly, with no hesitation whatsoever. I must reitterate that I know that is very, very early in the process of absolute determination, but for some reason, I feel I have reason for a little more than cautious optimism. So, for now I want to say HOORAY!
Many people who monitor this forum wish you complete contentment with your reworked transmission. Will we ever know if it was the solenoid or the ATF level ?? Keep us posted.
BetterSafe (thanSorry)
I have been on record stating that my 05 Highlander V6 5spd automatic doesn't seem to have the hesitation that others here have experienced. Perhaps it is my driving style, I dunno, but I now have almost 4,000 miles on it, and so far so good. I did say early on, that it shifts differently than my 03 Highlander (4 spd autoimatic). This "difference" is not enough that I am willing to take any action, posssibly making things worse. ("if it ain't broken, don't fix it"). ....altho, if this fix you had will make "difference" go away, who knows, maybe I will consider it.
With that said, I know you will continue to keep this forum appraised of your thoughts as you drive your "new" Camry over the next few weeks, so others can benefit from your experiences....
NICE WORK!
Thank you for your level head.
Jeff
Four THICK volumes.
The torque converter can or may be locked up in 3rd, 4th, or 5th gears, provided the throttle opening is only about 5%. I take this 5% to mean the vehicle is not accelerating.
It will upshift from 4th to 5th if you transition to closed throttle at speed.
The only tests, verification, for engine compression braking is in 1st or 2nd.
The lock up clutch is ALWAYS released with brake application. This last says if the brake switch is "on" (brake applied) along with the gas pedal being depressed the ECU will activate the MIL, Malfunction Indicator Light.
Buried within each section of the documents is a note regarding how c-best options work and will affect the technicians testing.
More to come.
Any helpful sugestions?
Traveler4
Thank you for contacting Toyota Motor Sales, U.S.A., Inc.
We apologize for your dissatisfaction with the driving response of your 2005 Camry V6.
The hesitation you described typically surfaces either when the accelerator is depressed fully to the floor or when depressed an aggressive fashion. The newer version of the Camry has transitioned from a manual throttle linkage to an electronic throttle control system. The electronic throttle control continually monitors the position of the accelerator and then electronically relays this information so the transmission can make a smooth and efficient gear change.
When the pedal is depressed aggressively, the accelerator bypasses several intermediary throttle positions and the transmission receives less throttle position data. As a result of this lack of data, the transmission may experience a slight delay when trying to find a gear that will deliver the power asked of the vehicle.
At this time Toyota does not have a modification for the shift characteristics or acceleration of the driveline. To minimize this condition, we recommend trying a firm yet gradual application of the accelerator. This allows the vehicle to gather the data it needs to provide smooth, un-interrupted acceleration.
Your feedback is appreciated. It is through communications such as yours that we become aware of our customers' expectations and reactions. It also provides us with valuable insight when planning and developing future products and services to increase our customers' satisfaction.
Your email has been documented at our National Headquarters under file XXXXXXXXXXXX. If we can be of further assistance, please feel free to contact us.
Toyota Customer Experience
>>
When the pedal is depressed aggressively, the accelerator bypasses several intermediary throttle positions and the transmission receives less throttle position data. As a result of this lack of data, the transmission may experience a slight delay when trying to find a gear that will deliver the power asked of the vehicle.
>>
Hmm. wwest - no mention of any sort of time-rate-of-change calculation or detection for throttle position in that mass of documentation you have is there?
In theory, sampling the throttle position (and other actuators / signals) happens at a prescribed interval which doesn't deviate much. So "transmission receives less throttle position data" doesn't ring true for me since per given unit of time, the same number of samples of these variables would be available to the control system program as a whole.
I hope that makes some sense.
Now then, if you were as a designer, attempting in software to anticipate driving conditions or demand or characterise driving habit for example by calculating the time-based derivative of throttle position (i.e. dX/dT) for some reason - and perhaps applying that derived variable/signal in your control system logic in some way, then rapid changes in throttle position vs. time *might* trigger other events that impact how the TCM responds.
Then again perhaps rapid changes outside some allowable band might be initially rejected as potentially erroneous (say to guard against throttle position noise or momentary fault), and replaced with the last-known-valid position until the derivative fell back within a programmed allowable band.
"When the pedal is depressed aggressively, the accelerator bypasses several intermediary throttle positions and the transmission receives less throttle position data."
So..............why not have the accelerator NOT bypass the intermediary throttle positions when the pedal is "aggressively depressed" (sounds like it needs a psychiatrist)? I mean, we're talking computers here that can make incredibly fast calculations. It would seem to me that the computer should be able to handle ANY quick human-initiated interface/movement with ease! Whatever. Wierd letter.
1: Call and register a complaint with Toyota "Customer Experience"
2: Call and register a complaint with NHSTA (very important for all owners)
3: Check your transmission fluid level (when hot) and drain some if necessary.
4: Have your ECU re-set
5: Contact your Toyota District Manager and arrange a test drive
6: Keep complete records of every phone conversation and dealer visit
7. Park in front of the dealer with a sign that reads: "DONT BUY A TOYOTA !"
8. Keep us posted
Somewhere on the internet I came across an engineering white paper that indicated that Toyota refused to use DBW, e-throttle, e-gas, until a failsafe system could be developed.
Keep in mind that the very last thing any automotive manufacturer wishes to encounter or be forced to address is....
UNINTENDED ACCELERATION.
To that end the Toyota drive by wire e-gas system has a redundant, failsafe, design. For gas pedal position sensing they use 2 non-contact hall effect sensors. The first sensor's output, VPA, is used to control the engine and the second, VPA2, is used to cross check, validate, the position signal of the first. The two sensors are designed such that their separate output position feedback voltages always differ by ~0.8 volts for the exact same pedal position.
When checking the second output, VPA2, against the first, VPA, if the difference, ~0.8 volts, is not in the correct range (less than threshold) the VPA signal is considered invalid and the throttle position servomotor is "ordered" into a "limp home" mode.
Since both sensor outputs cannot be "measured" by the ECU strictly simultaneously it appears possible that with RAPID gas pedal movement could result in a reading of the VPA signal and a later (10 milliseconds??) CHANGED reading of the VPA2 signal that invalidates the VPA reading.
It appears that the OBD-II Readiness Monitor, running as a "background" task in the same ECU, executes the gas pedal position validation software routines, actually doing the checking of VPA signal against the CPA2 signal for validity. In that case the time lapse between measuring the two signals could be on the order of hundreds of milliseconds.
Dithering the gas pedal..
Back and forth movement of the gas pedal through driver (warranted) indecisiveness might exacerbate the problem. Suppose one of these "dithers" results in a quick release of the gas pedal? The Readiness Monitor sees an invalid pedal position temporarily and files it away in memory for the next 0.5 seconds. Now, within the 0.5 second "window" the driver suddenly goes WOT.
Oops, second invalidation within the 0.5 second window...put the throttle in "limp home" position. And now within the next 1 to 2 seconds the Readiness Monitor has seen enough continuous VALID gas pedal position reading that it goes back into NORMAL mode.
See:
Lexus 2004 Repair Manual RX330 Volume I, Pub. No. RM1027U1, Page 05-25, 05-250 and on.
Methinks a good programmer with some hard real time programming experience could do it but as new as the automotive industry is to all this I doubt they have such programmers on board or even know they exist.
amf1932, "Transmission problems with Lexus ES-300 ?" #726, 25 May 2005 8:39 pm
>>
Since both sensor outputs cannot be "measured" by the ECU strictly simultaneously it appears possible that with RAPID gas pedal movement could result in a reading of the VPA signal and a later (10 milliseconds??) CHANGED reading of the VPA2 signal that invalidates the VPA reading.
>>
how do you know they cannot be read simultaneously (or virtually so?).
generalizing: most control systems that are real-time critical perform phases of input, processing, output and other housekeeping on a *very* strict timetable, typically marching to the beat of a clock which can trigger the associated tasks. tasks must complete their processing within prescribed time limits, or the whole unit detects a fault, and takes some action (TBD).
one would think, and I could be wrong about this, VPA1 and VPA2 analog signals would be acquired at the same time (or practically the same time, within a finite and acceptable number of clock cycles which BTW wouldn't be significant enough to represent significant error), and make their values following conversion to digital representation available to the embedded controller signal space at virtually the same time.
even if the control algorithm using VPA1 and the validation algorithm using VPA1 and VPA2 occurs at different rates than the fundamental I/O, there is no issue.
inotherwords, a good design puts the acquisition of the raw signals in-phase or coherent. you don't want to be acquiring the signals you use for control and for validation at differing times, for the very reasons you mention later in your post.
you also write:
>>
It appears that the OBD-II Readiness Monitor, running as a "background" task in the same ECU, executes the gas pedal position validation software routines, actually doing the checking of VPA signal against the CPA2 signal for validity. In that case the time lapse between measuring the two signals could be on the order of hundreds of milliseconds.
>>
like I said, i have trouble believing the embedded control system would be designed to acquire these inputs in a non-coherent or out-of-phase manner.
one would think the inputs occur at a regular basis / time interval.
control happens at another regular but not necessarily identical time interval.
validation happens at another regular but not necessarily identical time interval.
output happens...
housekeeping happens...
you do not acquire VPA1 and VPA2 at different time intervals, unless they multiplexed the sensors and use the same analog to digital convertor circuitry and on a given pass, can't possibly convert both virtually simultaneously.
even if that were the case, you'd hope their system would do a sample and hold of the analog values for conversion.
even barring that, they'd probably design the system so they were converted with a delta time, such that the validation couldn't be negatively impacted by a quickly changing demand.
otherwise they'd be shooting themselves in the foot wouldn't they?
does your set of reference manuals address those sorts of low-level implementation details?
.
I have been in constant communication with my Lexus dealership in Los Angeles as I have been aggressively pursuing this issue too... they called me this week to tell me that a software upgrade for the RX330 just came out, which addresses the hesitation. I took my car into the dealership this morning and dropped it off to have the upgrade installed.
My paperwork states: "Customer reports hard shift concern."
I asked to get a copy of the TSIB, but they said they'll give me it when I pick up the car. They state that the TSIB is the same one as the last upgrade, only this one has a current date with the UPDATED software. But otherwise it's identical.
Okay, I'll report in on what happens, how the car performs immediately, what the TSIB is, and of course, keep reading this excellent forum and updating after 1K miles to see if this fix sticks.
There is only ONE (FAST, but how fast?) ECU that controls the engine and transmission. Does that one ECU have complete responsibility for all engine timing functions, ignition timing, fuel injector open/close duty-cycle, transaxle SLT solenoid PWM duty-cycle?
Granted the block labelled "Engine Control Module" in the shop manuals might contain more than one processor, but for this purpose I will assume not.
A single processor would dictate a very tight real-time inner execution "loop", but probably written in a high level lanuage rather than assembly
And the manuals do indicate that the "Readiness Monitor", responsible for sensor validity checking and verification of proper response to parametric inputs (did the oxygen sensor output indicate a reduced exhaust oxygen content when the fuel mixture ratio was decreased?, etc.) is run in the background only when extra processing time is available.
And yes, any experienced(***) real-time programmer would A/D sample the VPA1 signal immediately after the VPA signal and with the interrupts off, saving the VPA1 result for later use of the readiness monitor.
But then we have the matter of foreseeability of the actual events that are the causative factors. And remember that very high on the chart would be a requirement, an absolute requirement, to NEVER allow the gas pedal sensors to show a WOT or near WOT inadvertently.
*** I once encountered a mal-functioning prototype positioning system that used high power/torque stepper motors wherein the individual step pulses were software generated. In order to keep the motor from overheating the power was significantly reduced to just enough to maintain postion "lock" during the long periods that no positioning was required. The high/low power control was also via software and it was the responsibility of the programmer to assure that the power was turned to "high" before issuing any step pulses and then return to "low" to reduce the heating load.
The programmer had asked the hardware design engineer how long it would take to get "high power" once the output bit was set and the engineer had responded, "oh, right away".
Wrong.
The programmer was asking the question in the context of sub-microseconds and the engineer was answering in a separate context, frame of mind/thought.
The real answer turned out to be several hundred milliseconds. Many 60Hz charge cycles of the power supply's capacitor storage "bank".
In the case above, Toyota, we likely have an engine design specialist engineer talking to a "coder", probably a really good coder.
Garage in, garage out, even unintentionally.
bkinblk, here is the info on my paperwork, and that's all I have right now:
"A customer reports hard shift concern.
Cause: Hard shift confirmed condition, performed TSIB TC00503
TC3001 recalibrate ECM engine & transmission
700 W
FC: 26,99"
That's all the info. I have right now. I'll make a call on your behalf about the recalibration code...just tell me why I'm asking, as in, if they're different or the same, it means X.
personally, I wouldn't let the issue of high-level language vs. low-level language muddy the water too much. you can get pretty decent code using high-level compiled languages, and you can hand-optimize the result if need be.
also, i think the processors used for the application have plenty of spare cpu cycles, code and signal space including other architecture features (like prioritized interrupts) to do the job up right.
i highly doubt the design team goofed on the validation and control signal not being time coherent. if they did, they should be taken outside and shot.
i feel its a matter of time before an automotive control system engineer happens upon this forum and drops some breadcrumbs to the masses searching for enlightenment.
Duh!
When you activate the defrost/defog/demist mode of your automatic climate control during the winter the system should take the utmost measures to clear the windshield.
It doesn't, not even close!
There is no way the designers can, or could know, how serious the windshield fogging condition is, might be. You may have just driven up to the snow ski area and picked up a couple of cold, sweaty and wet, clothes SOAKED, skiiers and now the cabin atmosphere is super saturated with moisture.
When I activate the windshield defrost/defog/demist mode I expect nothing less than the highest volume of HOT and DRY airflow to the interior windshield surface the system can provide. Sure, activate the A/C, it may be helpful. Then leave it to me to moderate the system as needed, or if my discomfort level overcomes my desire to see clearly through the windshield.
ABS doesn't always result in shorter stopping distances, but it does always allow some level of directional control during severe braking.
Why doesn't the industry use VSC to disable ABS unless the VSC system detects that loss of directional control is threatened?
From the most recent posts it is beginning to appear that a reflash, new firmware, is the final fix.
Software "bug" or poor software design specification.
Who do we take out and shoot??
if it were a firmware (embedded software) issue inside the ECU or TCM, why wouldn't everyone, i mean large N be experiencing the problem.
(and maybe they do to a more or lesser extent....that's old territory anyway)
for me, my money has been riding on hardware at root cause all along.
if it were strictly software, then i cannot believe a manufacturer with so many complaints across a number of vehicle models wouldn't have solved this sooner.
frankly, i wouldn't believe a product tester would allow this sort of behavior to go un-noticed before the vehicles were even introduced. i cannot imagine toyota fielding a vehicle with this behavior as a design artifact.
i just have to believe they are dealing with a 2nd source parts quality or assembly or failure issue.
granted, software design might exacerbate a problem that is based in hardware, but I personally just can't believe myself that a reflash / new firmware is the golden bullet.
Hardware or software?
Additionally when you discover that a fix can be supplied by revising the software where do you lay the blame?
At the feet of the original design team.
Solved sooner...
How long do you think it might take the CARB to rule that the reflash is benign insofar as their interests are concerned?
And I know of many instances of recalls wherein the flaw was discovered at the manufacturing QA level and was never reported from the field.
perhaps the hesitation is hardware related, and the indecisiveness in shifting is software, and that it too might be possible to correct with a reflash specific to your vehicle.
good reporting!