Rob, a question that is never been discussed relatively the deceleration map:

how do the ACD lockage is related to Y axis accelerometer? (and also X axies too...) Logging ACD prop valve current (mA) we can see how in hard brake (staight wheels) the current rise as the deceleration increases, no tps and no wheels spin...




This could be a very important map to tuning for godd handling during hard braking to avoid rear or front locking wheels or help front brake too.

 

I'm yet to find a solid link to a map for Longitudinal g-force. Nothing enough to convince me anyway. I thought the B Map did this, and makes sense in an acceleration form, but as you said the prop valve current varies, so yes there is something else boosting it that isn't throttle.

For an Evo 9 rom, the axies I have confirmed are:
Vehicle speed (axis reference address F208)
Throttle (F172)
Steering Angle (F23E)
Steering velocity (F24A).

There are 32 other axis reference addresses that I'm yet to get to. At this point im just trying to see if I can come to the same conclusion others have.

 

Sabin, I had a bit of a look last night at this, as and I suggested above, there are a considerable amount of decision points where bit #5 @F080 is tested. Some of them quite complex. But but but...now that I know exactly what map sets are used and how they are used, I can't think of any reason we couldn't just change the bit number being tested before the map(s) that you would want to use as Accel/Decel. Brake pedal input triggers bit #2 @F080, so it would be a very easy change to make in the hex before the map you'd want to use as a Accel/Decel config. C Map (Steering Angle v's Speed) would be a prime target for this off the top of my head. A Map is a possibility too if people out there are left foot breakers (essentially you could nul throttle ACD lockup without lifting). This would be much easier and much more targeted/maps specific than strapping pins (or wires to brake pedal inputs).

 

Just a bit of an update on this...kind of hit a bit of a wall because of my ability to actually understand CPU commands and processes. Reading the info in the programming manual only gets you so far when you don't fully understand it. So again....any help with this would be awesome.

But anyway, I've been trying to work to this block diagram and try to work out what tables fit where. I'm still at a loss as to where the longitudinal G-force is fed into the ACD control block. Looking at the map arrangements and values, it makes sense for it to be the B-map (currently defined as Gforce), but directly before processing the B-map, the axis data address (F13C) has the data from address F23E moved to it. F23E is the same data address used for the P map (9x36 table - note, not AYC) as well as the C-map which I have found within the code to be Steering Angle.

 

That light bulb moment when everything starts to make sense!

I found a link to Longitudinal G into the ACD control section. It eventually gets assigned to address F016. The two tables in the ACD control section that use this address as axis data is F and G tables.

Merlin had a long time ago posted the mathematical process the ROM goes through with different tables within the ACD section. For most part he has been correct and essentially it comes down to (and these are in order as they are processed within the ROM):
P x J (J tables aren't present in Evo 7 roms. Also note, the P table is the big 9x36 table which was thought to be AYC)
D x E
F
A x B
G x C (H table is also tacked on here, but there's quite a bit of constant data manipulated with it. Given that the values are 1, i'm going to ignore it as it has no effect on the result).

The only map I'm still not sure exactly what it does is the P map. The values don't make sense as a lockup adder. When reading the design concept documentation and looking at the block diagram above, I think it has the possibility of being:
- sets the target value of the target body posture
- varies the ratio between the Target and Actual body postures, or
- varies the ratio between the Feedback and Feedforward control sections.
It's worth noting that there are a number of things that could do any of the above, and are specific to T,G or S modes too (P map is not).

Anyway, back on track....lets add some names to the equations.
P = ACD Main Map
J = ACD Main Map coefficient (reduces the effect of the main map with reference to vehicle speed)

D = Front to Rear wheel speed delta (ACD lockup adder)
E = D map coefficient (reduces the amount of ACD lock because of F/R speed difference with reference to vehicle speed)

F = Acceleration G-force (ACD lockup adder)

A = Throttle lockup adder (3D table which can be adjusted with reference to vehicle speed)
B = Throttle coefficient (reduces the amount of ACD lock because of throttle input with reference to steering angle)

G = Braking G-force (ACD lockup adder)
C = Braking coefficient (reduces the amount of ACD lock because of braking g-force with reference to steering angle).

H = Steering angle velocity coefficient (reduces the amount of ACD lock with reference to steering wheel speed...values are 1 in 8/9 ROMS, so this has NIL effect).

Sabin, based on this...there's your Accel/Decel tables.

 

Great stuff!
It would be wonderfull to update the xml def now...

 

Very Nice summary; The Best I have seen.

So I presume the Axis scaling of the maps F and G are still regarded in units of Volts, as per EvoScan's LongitutudeG (Accel/Brake) g-force sensor voltage?
and the Steering Angle Speed in map H is still represented in Degrees/Sec ?
and I assume these maps are only applicable to Evo 7/8/9 ACD units... Do Evo5 and Evo6 have ACD? I know Evo4 only has AYC.

 

I have also updated the Master EvoScan ACD tech info webpage with your nice summary and diagram from the manual... With a special mention to yourself thanks.
https://www.evoscan.com/technical-ve...cd-ayc-sayc-at

 

Thank you Hamish...greatly appreciated!

Evo 4, 5 and 6 only have AYC, and the ECU's are not flashable. So yes mate, all the theory only applies to Evo 7, 8 and 9.

Steering angle representations are unchanged.

Personally, i like to work in G-force. I added additional lines in EvoScan so I could see both G-force and voltage for these sensors. It's the same equation with -2.5 on end (Eval="5/255*x-2.5" Unit="G"). Within ECUflash I've also decided to go with G-force for tables F and G. The reason for that is within the ROM, the value moves around 0x8000 (this is used as an initialization setting (same as 0x80 in other tables) on the axis which usually results in a neutral/do nothing. So given that G-force is moved from zero to positive or negative, i figure this is the best fit. Working out the scale is a different story. There are 3x axis that use address F016, and at this stage I've gone with the axis i found with the largest variance from 0x8000 to gave it the max G value of 1.5G (as per the AYC/ACD desciption).


Using this scaling for G-force, this is what I get across the tables:
<scaling name="G-Force" units="G" toexpr="(x-32768)/426.6667" frexpr="(x+32768)*426.6667" format="%.1f" min="-1.5" max="1.5" inc="0.05" storagetype="uint16"/>


I'll do some more real world (ie go and do logging) testing to try and figure out if this scaling value is correct before I lock anything in for certain. I'll also be looking for the Lateral G force tables (I'm assuming they will be within the AYC block) and that might also help me confirm an axis scaling.



XML's are a constant work in progress. While I'm still working this all out I'll be reluctant to release anything yet.

But here's a quick view of how I've started to lay mine out:

Accel/Decel tables have been renamed into their own separate categories. (w/ AYC = Pin 50 N/C, ACD only = Pin 50 grounded)

Some of these tables I have had to duplicate within the XML so that they appear in both w/ AYC and ACD only configurations (same ROM address, but appear twice with a different name and category).

Within each category, I've now arranged the maps in order that they get processed in the ROM. This also give a better idea of the relationships between the tables.


Some of these tables I have had to duplicate within the XML so that they appear in both w/ AYC and ACD only configurations (same ROM address, but appear twice with a different name and category). This allows me to concentrate on a specific mode and configuration. ie, no point modifying tables I don't have to. Also worthwhile noting that these are all the tables/values that are processed depending on the mode. If you copy the contents of all these tables from one mode to another, then those two modes will be EXACTLY the same.

 

Looking at the axis in ecuflash, I see 0.1 0.1 0.4 0.4. therefore, to get an extra decimal point, I wonder if going for format="%.2f" is better.

Yeah good call on the -2.5 to bring it in line with actual G's.

 

What addresses are you looking at there Hamish?

This images shows the results I get for the tables that use F016 as data and one decimal point.

 

Rob, i'm still working my hear around your summary...

S.

 

Wow, i go away for 6 months and look at you guys go ! This sounds like the disassembly / characterization has really taken off and there is much better knowledge now. Wish i had my MR back now :-(

 

Bit of an update...

I've been doing some testing with a big focus on the F and G tables. 100% certain that G table is braking G-force. Based on that, the "axis" for use of a better word is inverted compared to what you log. Ie, logged values when braking are positive, but the axis values go negative (less than 0x8000). So I'm assuming there's some sort of inversion in the signal into the CPU...which is very possible (I'll show the circuit to Merlin at some point and maybe he can confirm.

As far as the F table goes, I'm still confident that this is acceleration G-force, but I think my scale is off. My car pulls about 0.7G under acceleration, and although I did see changes in the values, they weren't as dramatic in change compared to logged values for braking. So I think where I added large valves (0.6 and 1.2G on the current scale) might actually be expecting a bigger G than my car was giving it. So yeah, when I get time, I'll test this one again. But as I said, the F and G tables use the same input for the axis, so it's just a matter of me figuring out the actual scale for the axis.

 

Nice job! Are you uploading your XML or Rom anywhere to play along with the changes you're finding? At least in definition that would be a great update to what we already have.