Quote:
Originally Posted by svxistentialist
Your breaking down of the software inside the TCU may well lead to better or less complicated permanent switching, which would be great!
|
That's the plan.
Quote:
Originally Posted by svxistentialist
If you think the OZ WSM for the gearbox might be useful, I'd be happy to post it to you, and collect at JAE.
|
Thanks for the offer. I'll let you know if I need it.
Quote:
Originally Posted by svxistentialist
As regards your point above with the timer, the complication could be the speed signal, as Power mode shift map is put in place by two variables, throttle position and road speed. The following is how the WSM describes the drop back to Normal:
The power pattern is shifted to the normal pattern depending on car speed. Shifting to the normal pattern is determined by the throttle position as shown in the figure on the right. Time lag in shifting [from power tonormal] is also determined by car speed. The maximum time lag is 3 seconds.
The diagram is a simple Venn diagram. Judging by the relative areas shown it would be reasonable to presume that Power will drop off [on cutting back throttle opening] after 3 seconds at lower speeds, after 2 seconds at mid speeds, and after 1 second at high speeds. I expect low, mid and high speeds are preset atspecified ranges within the firmware.
|
That is exactly right. My US manual says the same word for word, and I found the code that implements it in the TCU firmware. I was planning not to post code here because it's a bit too nerdy for a car forum
. But in this case I think it's relevant and it gives a taste of what I'm working with.
Code:
e796 ce c9 04 ldx 0xC904 // Vehicle speed table for power to normal switching
e799 96 18 ldaa (0x0018) // Vehicle Speed (don't know how to convert to mph)
e79b 5f clrb // b=0
e79c a1 00 cmpa (X+0x00) // Compare speed to first entry in table (1E)
e79e 23 0b bls [0xE7AB] // if speed <= 1E goto e7ab
e7a0 5c incb // b=b+1
e7a1 a1 01 cmpa (X+0x01) // Compare speed to 2nd entry in table (3C)
e7a3 23 06 bls [0xE7AB] // if speed <= 3C goto e7ab
e7a5 5c incb // b=b+1
e7a6 a1 02 cmpa (X+0x02) // Compare speed to 3rd entry in table (5A)
e7a8 23 01 bls [0xE7AB] // if speed <= 5A goto e7ab
e7aa 5c incb // b=b+1
The section of code above compares the vehicle speed against a table of values in the firmware. It calculates an index "b" which relates to the X axis on your diagram. b=0 for the first section is 0, 1 for the second, 2 for the third, 3 for the last.
Code:
e7af 58 aslb // b=b*2 (each item in the table is two bytes)
e7b0 ce c9 17 ldx 0xC917 // Throttle opening table
e7b3 3a abx // add b to x (ie. add index to start of table)
e7b4 96 4c ldaa (0x004C) // Throttle opening
e7b6 a1 00 cmpa (X+0x00) // compare to threshold from table (02,02,03,04)
e7b8 25 05 bcs [0xE7BF] // if throttle < threshold goto e7bf
e7ba a6 01 ldaa (X+0x01) // get timeout from table (4B,4B,32,19)
e7bc 97 c1 staa (0x00C1) // Set power mode timer to timeout from table
e7be 39 rts // exit
The code above uses the index "b" calculated earlier to lookup a threshold and a timeout from a table of values in the firmware. This is the Y axis on your diagram. If the throttle opening is greater than the threshold, the timer is reset to the timeout value. Remember, this code is running several times a second, so the timer is constantly being reset. The timeout values correspond to 3 seconds, 3 seconds, 2 seconds, 1 second.
Code:
e7bf 5f clrb // b=0
e7c0 96 c1 ldaa (0x00C1) // power mode timer
e7c2 26 17 bne [0xE7DB] // if timer >0 goto e7db
e7c4 d7 5a stab (0x005A) // set current map=b
e7c6 39 rts // exit
<snip>
e7db 5c incb // b=b+1
e7dc d7 5a stab (0x005A) // set current map=b
e7de 39 rts // exit
The code above gets executed if the throttle is less than the threshold. If the timer has reached 0 then it sets the current map to 0 (normal) otherwise it sets it to 1 (power).
Quote:
Originally Posted by svxistentialist
This in turn leads me to believe that you may have more success holding power mode in the software by "fooling" it into seeing an open throttle all the time in the TCU software, rather than changing the timed drop-off interval.
|
The problem is that the raw inputs from the sensors like the TPS can't be overwritten. The variables that the TCU calculates from those sensors, can be overwritten. But it must be remembered that the TCU is constantly reading its sensors, recalculating these variables and overwriting whatever dodgy value I put in there with the correct one. Thats why frigging the timer is appealing, because it isn't calculated from any external source. All the TCU does is subtract 1 from whatever value is in there until it reaches 0.