jcsbanks

No, I'm saying that if you need to keep knock sum DISABLED above 159 you can't at present. So if you had false knock at 180 load and only wanted knock control at 200+ we would have to recode.

All loads above those in the table have full knock control.

I suggest the loads are increased to just above those at which people get false knock and no higher than necessary, since you want knock control at high load.

What load/RPM do the false knockers have problems? If is is 70-140 at 3000-4000 RPM then I think this is a likely fix.

mfr122887

iTrader: (14)

I seem to get knock at around 3500 RPMs and about 80-100 load. Just accelerating smoothly in 2nd or 3rd gear. Should I try to raise 4000 and lower on the table to like 120 load? I have the 94170015 rom and can help testing with this. Will the KnockCEL still work if you are under the load in the table?

jcsbanks

If you are sure it is false knock (ie doesn't respond to changes in timing and you've sorted it any noises etc), I would set your load to 120 from 3000-4000 RPM then and see if that works.

You are reducing or stopping knock sums in the loads below what are in this table, so Knock CEL (and the knock sums in your logs) should reduce or stop accordingly. The changes made are at the heart of the knock control system which calculates knock sum. The Knock CEL stuff just displays the result.

honki24

iTrader: (23)

gotcha

cossie1

John have you worked out what the 2nd table is yet, the 1 with the 3x 120 load area's at the end, as I have a stock E7 RA rom here (AV GAS version for rallying) and that table is 159.4 all the way along and I know it's definded correctly in the xml as I checked it against 90550001.

jcsbanks

The second table that Eric posted is the one that sets the loads at which the octane value can be updated.

I would forget about adjusting anything to do with octane. It works fine out the box and there is no reason to change it.

Adjusting knock control parameters is what is important to make knock sums reflect knock rather than noise.

I've been doing more work on the noise filtering stuff, the routine checks lots of flags which I'm hunting down, some of them are obscure.

At some point when I know what I'm really wanting to test, I will collect a high speed DMA log of the relevant knock related variables. The MUT logging isn't fast enough to be useful for this. I hope to be able to show knock sums in the log and validate the algorithms used from the code.

I have still to work on a section of code that establishes the background noise level, I think this will be the key area for the false knockers.

There is also potential to put in background noise tables with which the present knock ADC value is compared - like some aftermarket ECUs - if we can't fix the OEM ECU's background noise level so it works on noisy engines. It is obviously configured for quiet engines and works brilliantly on those, if you are lucky at nearly double stock power outputs. If you are unlucky it falls apart with a noisy clutch.

3geclipse

iTrader: (2)

im using 94170008 rom and the load adress is the same as the 94170015,but the rpm adress is different,can someone please look up the real rpm adress for the 94170008 rom? i know most of you dont used this rom but im using it for a long time and it been working fine for me,i have most of the patches in it,if no one could help with the rpm adress then i will swap the roms

Jorge T

iTrader: (18)

6106

burgers22

From my logs taken on the ECU+ you can see the voltage from the knock sensor and compare it to the MUT knock. Though some of the correlations between the voltage and the MUT knock are easy to see others are not. It would seem likely that there are more complex waveforms that can't be seen on a a simple peak voltage trace, and these are analyzed when the system decides if knock is present.

Has the knock sensor input been traced through the ECU circuit board to see if it's pre processed by a DSP? If it is done via the main ECU processor then there is more chance to influence the behavior of the knock system.

MB

Mattjin

My investigation of the maps at 4a40 and 4a50 found them to be load axis (40 to 160) and not rpm. I could hold the engine at a certain load and by varying the map could change the rate at which octane adds for one map, and subtracts from the other. I could be wrong though, as I started out with them being exactly as you have them, rpm with load being adjustable. What made me change was 4a50, where I could drop the map from 255/176 to all 176, and from that make octane increase at the lightest of throttle, well below a Load8 setting if mapped the other way. Playing similarly with 4a40 I could turn off octane control at certain load points by setting it at 255 for that load. It would still show knock sum, just not effect the octane.

One of my biggest false knock problems has been with octane. I do still get knock sums of 30+ too so I am also eager to find the right maps to control. With the car being an auto, it sits alot of the time around 2500 to 3500rpm at low boost areas. This cause it to constantly false knock and wind its way down the octane. It was from this I found the boost control functions with octane and these can be adjusted down if required.

The boost control maps for octane are at 1a5e and 1a60 for my rom if you want to have a look. I have not yet tried setting them to zero and see if boost control still works with the knock control turned off.

I will go over the info you have given and see how I go.

jcsbanks

Marcel, I've not traced the knock circuit, but from looking at the evolution of Mitsubishi knock control, they have brought more into the ECU in the Evo 7-9 than earlier models, eg the average knock sensor noise is now calculated from the knock sensor ADC input. I think it will have a bandpass filter, and is then gated through interrupts. Earlier models used an external chip that did the lot and fed in a fairly well processed knock signal. No evidence of any DSP activity.

Matt, there are some differences between the JDM 9 for knock control and other models. I think sometimes I underuse empirical testing which would speed things up by allowing us to log certain things to show there are areas of disassembly we don't need to worry about. On the other hand, from disassembly you can quickly become pretty definite about what variables are involved in what table. I do believe if your knock sums were always below 6 you would always stay on 100% octane and have no issue with octane ever again, so finding/sorting the noise control stuff is I think the way forward for your and every other false knocker. With high knock sums and their decay it will be very difficult to make much sense of how octane behaves as it is never stable as the update interval is much slower than it is for knock sum. I can be certain that the tables at 4a40 and 4a50 in your ROM are the load values for knock and octane adjustment, although with the stock settings in your ROM I think you'll still have knock control below the load value for knock but just less sensitive. However, that sensitivity is adjustable and able to be clipped by different amounts below and above the load thresholds.

I've been breaking down the disassembly of the noise routines into elements, and trying to identify the constants and unknown variables so I can see a typical path the code would take during normal (non-error) operation. I can see the outcome of the noise detection routine that sometimes sets the knock sum to zero. Following that there are complex routines that establish the baseline noise level. I think the key to the false knocking cars lies in one or both of these areas. I suspect that an engine that just likes to be noisy will have a sudden increase in noise at certain operating points that makes the stock calibration see knock. I don't think that once the ECU registers severe knock it will let go of the idea of it quickly due to two features - 1. On previous Mitsubishi ECUs the base noise estimation is not updated when the ECU believes there is knock and 2. the knock decay is slow. So it is a potentially clever self adapting system, but it needs some work on the constants and assumptions it starts with to suit the noisier engines yet still detect knock.

3geclipse

iTrader: (2)

thanks alot! i appreciated

Mattjin

I too am most interested in getting the knock sum under control, but when I also daily drive the car I needed to get things under control. So for me the octane was prime target number one, with the knock sum issue easier to prevent temporarily by just dropping the max knock sum value to a usable but safe level. As you know, this stuff takes up alot of time (my darling wife gives me daggers when I open up the laptop at home these days) but hopefully when enough people combine their information we will see the bigger picture.

It really is one complicated thing, the knock control, like a huge spider web. Some maps are in the same subroutines with other maps that you would think have nothing to do with each other. So I have full appreciation for your efforts.

One thing, I am confident that there will be a simple map or two to get the knock sum under control. Surely the tuners at Mitsubishi are not the code writers, and as such would need things to be easy to work with in the field. They too would need simple adjustment for sensitivity without having to spend hours reworking everything.

jcsbanks

What a lot of disassembly - all over the place. I'm still working on it, but a few things I've found:

The odd knock filter that Bez posted actually makes sense because there are two parts of it that are used - one has three times the gradient of the other, and depending on the background level of the noise the ECU switches an output to presumably a knock amplifier. Depending on this switch the ECU multiplies or divides the knock noise data by 3 each time the switch is flicked!

The noise filter has a timer that probably runs for about 100 engine cycles and cancels persistent knock of 1,2 or 3. Not very significant overall though.

The final piece of the puzzle that I really need to do more work on is the routine that establishes the background level that the present knock sensor reading is compared with. There are some RPM tables that are checked to determine multipliers that I think will set the rate of change of the background level. If these were modified it might allow for noisy engines to have a more sudden change in knock sensor activity at certain RPM and it not be interpreted as knock.

There is a lot to put together, I need to organise it in my own mind at least as I have lots of scrappy notes.

It was obvious to many already, but the "knock filter" tables originally in Ecuflash are nothing of the sort. I've found no 3d maps at all related to knock control, lots of 1d values, and not many 2d tables. This actually makes it more complex to decipher!

acamus

Same here. I was about to think I am doing something wrong when I do not see the connection to 3D tables.

Actually it seems to be downcounter masked by h'F.

According to patents issued by Mitsu, the real knock is assumed only in case the is a "spark period", it means in time real combustion takes place. It seems to be connected with MUT_72 bits.