This doesnt line up with your big post above. Here you say

" B map is a steering angle lockup reduction"

Which I think you mean C? Above and in the XML it has C as "Steering Angle Slip Adder" and B as "G-force Lockup Reduction"

 

Firstly, how old is your XML and who wrote it? XML is only as good as the person's idea at the time. As you've read, i've recently done a whole re-evaluation of inputs and process of the ACD block, and combined with the specific testing I've done, I'm very confidant of my theory posted.

as for my statement of B map, here is what I said in my big post above.
----------------------------------------------------------------------------------------------------

A tables - Throttle lockup adder (self explanatory). Can be specifically tuned around Throttle % and Speed.

B Tables - Steering angle coefficient. A value of 1 has no effect on the A table result. A value of 0 will nullify it. Can be specifically tuned around Steering Angle and Speed. (ie AxB = lockup value)

----------------------------------------------------------------------------------------------------

Personally i dont like the term "slip adder" as the rom is not adding slip. It adds lock and the coefficient maps reduce lockup. Yes it's kinda same same, but it's simpler to understand Adding lock with one table based on an input, and reducing lock with another table with another input. C maps are deceleration g-force coefficient. G table being decel g-force lockup. B and C tables both have the same input which is Steering Angle. The rom is very clear on this. Off memory I posted a pic of where it does this just before the B map.

Recap,
A x B
G x C.

 

Ahh, ok. So the XML I have is whatever Merlin's latest was but I suppose that doesnt line up with what you've found. But you also havent given us an XML to start from, sooo how can we get what you have now?

In lieu of that, I guess we can just edit our own XML to change the definitions to as you have them stated in your great and thorough post earlier.

When we are talking G-force in the various maps, are we talking long (accel/decel) or lateral (left/right)?

 

someone give me the explain like i'm five - what tools do i need to start adjusting the acd myself?

 

Yep exactly, it won't. But also correct, I haven't given out my XML (based on the months and months of time I've put in). But yes, based on all the info above, you can edit your own.

For ACD, it only uses longitudinal g-force (Accel/Decel). To be honest, I haven't found at all where the ROM uses lateral G...that's not saying it's not there...i just haven't found the connection (i'd say it's in AYC block somewhere).

Oh, and I also just posted this in the tuning thread to give a better idea of how to improve turn in and throttle out.
https://www.evolutionm.net/forums/ec...l#post11889195

 

So looking at the difference of the screen shots you've posted and the definitions we have from Merlin and whoever else worked on it, things just seem to be quite different in what we're seeing. I don't know if its a setup in the XML for the scaling of things or something fundamentally different. Like our "B" maps X axis are G-Force with a 0 to 1.5 scale where yours are steering angle with 0 to 360. Values in the cells also are dramatically different in shape.

Also on the "P" maps or what merlin has labeled "AYC Map" the magnitude of the values in the cells of OEM vs yours seem to be a completely different scale as well.

I dont know how the maps are created and what makes the scale or labels. If its you defining the "A" "B"... etc as that or if thats part of the code.

 

Hi Dallas, I haven't reassigned any table letters. The table letters I continue to use are those "assigned" by the original A-team. But no, the code doesn't define the table letter, it was just given to the tables as a method of ID, sort of in the order at which they were found.

Yep, things are quite different when you (me) let the code tell you what input is used for each axis. A bit of background on how I set out in this process was that I wanted to validate what inputs where at each axis. Having an idea of what might have been there helped, but, in cases like the B map, the theory (G-force) isn't in fact the reality.

Bellow is from a post from me above in regards to the code surrounding the B map.

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.

So based on this, I have changed in my XML the X axis scaling from G-Force to SteeringAngle. Also with B map, because the math within the code shows that B is a multiplier to A map, I changed the scaling from Lockfactor to SlipFactor.

In terms of tuning now (as seen in my screen shots), when you apply throttle lock up (A map) accelerating out of a corner, if the steering wheel is turned, you can reduce the amount of throttle lockup using the B map. It will be a balance finding the ideal point of ACD throttle lockup v's Steering angle. The goal is to reduce understeer.

Merlin in the early days (along with everyone else) labeled the P map as AYC. It's not...it has nothing to do with AYC within the code and everything to do ACD. Merlin was actually the first to try and convince me of this before I started the disassembly. But to answer what you're getting at here, I have tried to think of the best scaling to use for this table. I know Merlin works with CF255 as he prefers to see the raw bit values between 0-255. Other scalings used here (and one that I stuck with for a long time) was LockFactor, as it was simple to work with a percentage of lock...but neither really give an accurate representation of how i think this map really works. So in the end I've used CF128 (basically the same as SlipFactor just with a different description) as it gives a slightly better idea of what's going on. I would have loved to have positive and negative values here, but I don't think ECUflash will let me do that. So I've settled with the theory of SlipFactor in that a value of 1 is having no effect.
My theory on this table is:
- a value from 1-0 is an expected wheel speed difference, and at 0, do nothing to try and correct it if it exceeds the expectation.
- a value from 1-1.99 is an expected wheel speed difference, and at 1.99 do everything to try and correct it if it exceeds the expectation. The problem here with the high OEM values is that the expectation is so high, that the wheel speed differences are just never reached in most situations (liken it to the OEM auto I/C spray settings in the EFI ECU). That is why reducing the high values works so well to improve stability.

From what I just said above, you probably now have the same question as me, and that's "Why did Ralliart effectively zero out this table for the RS (non ayc) ECUs?". And this I can't answer. Only thing I can come up with is that by doing this, the ECU will only give an output based on every other table. That is, it's left more up to the driver.

Hope that helps!

 

any chance i can get ahold of this map also?

 

So Ive been reading, thinking, re-reading, re-thinking a bunch about the things you've said a couple things are making a little more sense now.

The XML files we have with definitions for "B Map" being "G-force Reduction" is one that was confusing me. We dont have a G-force sensor, its labeled wrong and should be Steering Reduction thats linked with Throttle Adder (A Map) in the AxB part of the equation. Seems we set this at higher "g-force" values to be zero so the Ecu is more likely to be dominated by the GxCxH table and P table.

Another thing Ive been looking at and thinking about is the P table. Where if I understand right the values are a slip level you expect to see with 100% (whatever the scale is) being no slip and 0 being no ACD correction. This probably uses a bunch of other timing and scaling values from the other tables but I think we can adjust this to cater more to our modified cars. Like for instance I expect my car to slip around 30-40mph at 90-180 deg steering angle and want it to be more stable by 60mph. Well looking at the P-map it doesnt line up with what "I" am trying to make the car do. So I think it might be interesting to stretch the P-map values above 90deg steering down to transition that high slip island to match the speeds I expect it. It almost looks like its defined around handbrake turns and hairpins more than low speed yaw rotation.

I also have all the available XMLs and the "401404_E9_ACD_Tuned" file seem to have the most maps defined even if they are largely unknown maps. I'm starting to come up with my test plan for next year, really hoping I can get the ACD working for me instead of feeling its working against me.

 

So you know how to copy/paste my figures into your P with 2 bins loaded ?
If I was to email you say a std 7 gsr bin with a modded P in it.
I have several modded Ps I made.
Is this for daily, tight circuit or longer sweeping circuit ?

 

Honestly im just getting into it so im going to say i dont yet. but i will be able to figure it out i know my way around 2d/3d engine maps etc already.

I do circuit racing mostly more open circuit stuff. No AYC just ACD with a wavetrac in it.

 

Same here ACD w a Wavetrac and RS rear no AYC. But I'm auto. PM me your email

 

We do have a longitudinal G-force input. It's axis input is on the F (accel) and G (decel) tables.

The same theory kinda worked with the B table being G-force, because as you said, it works better when the values are zero at high lateral g-force (turning) or now that I know the axis data, steering angles. Knowing it's steering angle allows for finer tuning control.

The P map helps the ECU know that when the steering wheel is turned, there is going to be a wheel speed difference. I tend to think of the P table as "what amount of wheel speed difference do I want, and how much do I want it try and maintain that difference. It's similar to the E table, but E doesn't factor in steering angle. But yes, you can fine tune the P map to adjust how the car reacts to steering input and stability through corners.

On the P table too, I've made a scaling that works on a -100 to +100 variance. Seem a little easier for me to understand.

 

Email recieved thank you sir! I will give it a go!

 

Hey all, does someone have a copy of the Ralliart Evo 7 K2 bin?