FIC2150 tuning notes
Dec 2, 2014, 07:07 AM
#17
Yea im interested how pump would turn out, im currently running 2150cc sd on pump but havent had a chance to mess with it much other then applying the minimum ipw and setting it to 1.088 and seemed to idle very well. Im gonna mess with it more tomorrow when i put in the new fuel pump.
Dec 2, 2014, 02:00 PM
#19
Evolved Member
No issue on pump for me on MAF or SD.
I had to pull a bit of cranking PW out though, they seem to fire on the key ALOT quicker than any other injector.
I had to pull a bit of cranking PW out though, they seem to fire on the key ALOT quicker than any other injector.
Dec 5, 2014, 03:28 AM
#24
Evolved Member
mrfred, I believe you have made an error with your Linearization Adder table.
there are 66 elements
the axis starts at 0uS, or 0.000mS
the axis ends at 2.080mS
the axis increments by 32uS
I realized this when I re-checked my own definition and found I had not included the whole table and had screwed the axis scaling.
So I am guessing your table values for the FIC2150 are a bit skewed. It certainly explains why I was getting weird tuning results on the ID2000s.
there are 66 elements
the axis starts at 0uS, or 0.000mS
the axis ends at 2.080mS
the axis increments by 32uS
I realized this when I re-checked my own definition and found I had not included the whole table and had screwed the axis scaling.
So I am guessing your table values for the FIC2150 are a bit skewed. It certainly explains why I was getting weird tuning results on the ID2000s.
Dec 5, 2014, 08:12 AM
#25
mrfred, I believe you have made an error with your Linearization Adder table.
there are 66 elements
the axis starts at 0uS, or 0.000mS
the axis ends at 2.080mS
the axis increments by 32uS
I realized this when I re-checked my own definition and found I had not included the whole table and had screwed the axis scaling.
So I am guessing your table values for the FIC2150 are a bit skewed. It certainly explains why I was getting weird tuning results on the ID2000s.
there are 66 elements
the axis starts at 0uS, or 0.000mS
the axis ends at 2.080mS
the axis increments by 32uS
I realized this when I re-checked my own definition and found I had not included the whole table and had screwed the axis scaling.
So I am guessing your table values for the FIC2150 are a bit skewed. It certainly explains why I was getting weird tuning results on the ID2000s.
I am in full agreement with you except on one aspect, and its more of a point of personal interpretation than being right or wrong. That item is starting value for the x-axis. As you know, the PW linearization table is parsed differently than most other tables. The distance down the data stack that is traversed to select the appropriate PW linearization value is FPW/4. (FPW = linear fuel pulse width calculated by the ECU.) This table lookup mechanism does not use interpolation between values like the normal lookup mechanism, so the PW linearization values used by the ECU are exactly the ones in the y-axis column. If the FPW calls for a value in between two PW linearization values in the table, it will take the lower of the two values.
The minimum pulse width of 0.008 ms is the integer value of 1. The step size of 0.032 ms in the x-axis of the PW linearization table represents an integer value of 4 (hence the use of FPW/4 to produce the step size to traverse the data stack). When the ECU divides by 4, a pulse width of less than 4 (less then 0.032 ms) will be rounded down to 0. So the three lowest possible non-zero pulse width values of 0.008, 0.016, and 0.024 ms all get rounded down to zero. Hence, the first value in the table effectively covers 0-0.031 ms. Rather than associating that first PW linearization value with a FPW of 0 ms, I prefer to associate the first x-axis value with the middle of the FPW step range that it covers, i.e. 0.032/2 = 0.016 ms. I then increment the x-axis by 0.032 ms. The only inconsistency is the final value. The ECU only uses the table for FPW request of up to 2.08 ms, so the final value only applies for 2.08 ms and not up to 2.011 ms.
Dec 5, 2014, 12:40 PM
#26
Evolved Member
Ah ha, now I see where you are with this.
I did not know about the rounding down operation, what you have done makes good sense to me now. I did not think it was interpolated, but did not consider the implications.
In any case, I doubt the ECU will ever use the first two or three entries, the real action will be around 1.5mS.
I have had this table in my xmls for years, but presented in a 6x11 3D format, which is fine if you are not going to tune it, but next to useless if you are. So it really has to be presented in 2D format, even if it is as long as your arm.
I am a little bemused with this table and the 32uS per step increment, knowing how sensitive the idle fuel trim is to shifting the IPW Minimum Pulse Width just 8uS, and here this table is making (giant) 32uS steps. Guess we will just have to live with that, but I am super encouraged with your results.
I did not know about the rounding down operation, what you have done makes good sense to me now. I did not think it was interpolated, but did not consider the implications.
In any case, I doubt the ECU will ever use the first two or three entries, the real action will be around 1.5mS.
I have had this table in my xmls for years, but presented in a 6x11 3D format, which is fine if you are not going to tune it, but next to useless if you are. So it really has to be presented in 2D format, even if it is as long as your arm.
I am a little bemused with this table and the 32uS per step increment, knowing how sensitive the idle fuel trim is to shifting the IPW Minimum Pulse Width just 8uS, and here this table is making (giant) 32uS steps. Guess we will just have to live with that, but I am super encouraged with your results.
Dec 5, 2014, 12:53 PM
#27
Evolved Member
One thing that I think will be difficult, the ID1300 data sheets show + and - values, meaning the compensation crosses the calculated IPW, not just rides under it. Our pet table wont accomodate that requirement.
The ID2000 is all adding though, so no problem there.
The ID2000 is all adding though, so no problem there.
Dec 5, 2014, 01:01 PM
#28
Ah ha, now I see where you are with this.
I did not know about the rounding down operation, what you have done makes good sense to me now. I did not think it was interpolated, but did not consider the implications.
In any case, I doubt the ECU will ever use the first two or three entries, the real action will be around 1.5mS.
I have had this table in my xmls for years, but presented in a 6x11 3D format, which is fine if you are not going to tune it, but next to useless if you are. So it really has to be presented in 2D format, even if it is as long as your arm.
I am a little bemused with this table and the 32uS per step increment, knowing how sensitive the idle fuel trim is to shifting the IPW Minimum Pulse Width just 8uS, and here this table is making (giant) 32uS steps. Guess we will just have to live with that, but I am super encouraged with your results.
I did not know about the rounding down operation, what you have done makes good sense to me now. I did not think it was interpolated, but did not consider the implications.
In any case, I doubt the ECU will ever use the first two or three entries, the real action will be around 1.5mS.
I have had this table in my xmls for years, but presented in a 6x11 3D format, which is fine if you are not going to tune it, but next to useless if you are. So it really has to be presented in 2D format, even if it is as long as your arm.
I am a little bemused with this table and the 32uS per step increment, knowing how sensitive the idle fuel trim is to shifting the IPW Minimum Pulse Width just 8uS, and here this table is making (giant) 32uS steps. Guess we will just have to live with that, but I am super encouraged with your results.
This reminds me of something that I should have mentioned in the first post. The MUT IPW is not the raw FPW request. It includes the linearization correction and the latency. I had to create a custom MUT call to log the raw FPW so that I could effectively tune the FPW linearization table. I didn't mention it before because I didn't think anyone would actually want to attempt to tune that table. Let me know if you want to try tuning it, and I'll edit this thread shortly with the info on how to log the raw FPW.
Dec 5, 2014, 01:28 PM
#29
Evolved Member
I will be back on the ID2000 evos tuning in a week or so, so you pleas with the MUT request info.
That 0.4mS minimum snippet of info might also prove to be a very useful thing to know.
It would be dictated by the minimum valid load point before injector shut off.
Located at address 1180 for the fuel cut load and 1182 for the fuel resumption load, I believe.
That 0.4mS minimum snippet of info might also prove to be a very useful thing to know.
It would be dictated by the minimum valid load point before injector shut off.
Located at address 1180 for the fuel cut load and 1182 for the fuel resumption load, I believe.
Dec 5, 2014, 01:53 PM
#30
Evolved Member
A curly idea for you to ponder mrfred:
Evo5-9 all use Lo-Z injectors, with a Latency base of 24uS, which limits the step increment / decrement to 24uS.
Most normally aspirated Mitsubishis use Hi-Z injectors, as do the EvoX and Ralliart, with a 15uS Latency base.
If we changed the 24uS down to 15uS on an Evo9 ( and revised the latency scaling to suite). thus giving us the smaller 15uS step size to work these big injectors, would we me mucking up some other part of the code?
Evo5-9 all use Lo-Z injectors, with a Latency base of 24uS, which limits the step increment / decrement to 24uS.
Most normally aspirated Mitsubishis use Hi-Z injectors, as do the EvoX and Ralliart, with a 15uS Latency base.
If we changed the 24uS down to 15uS on an Evo9 ( and revised the latency scaling to suite). thus giving us the smaller 15uS step size to work these big injectors, would we me mucking up some other part of the code?