Advanced fuel control options
Oct 29, 2009, 01:27 AM
#78
Newbie
Join Date: Aug 2008
Location: IL
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
Looking at the formula for BFPW, I see that STFT and LTFT are used. Does this mean that fuel trims play a roll in open loop fueling? From what I have read, some people say yes and some people say no.
Oct 31, 2009, 06:56 AM
#81
has any1 noticed that when you disable FCA bit. 13, 14, 15,
(IX Rom 88590715) it changes periphery 2hex from EDDF, to 0DDF. Is this normal? I have disabled all the bits manually. I tried using 0x0001 (once al of the other bits were disabled manually, besides 13,14,15), and it disabled bits. 13, 14, and 15, and 11,10,8,7,6,4,3,2,1,0.
So my question is, should I leave it as 0DDF, or should I set it as 0001, and change the rest of the bits back, or leave the rest of the bits disabled?
(IX Rom 88590715) it changes periphery 2hex from EDDF, to 0DDF. Is this normal? I have disabled all the bits manually. I tried using 0x0001 (once al of the other bits were disabled manually, besides 13,14,15), and it disabled bits. 13, 14, and 15, and 11,10,8,7,6,4,3,2,1,0.
So my question is, should I leave it as 0DDF, or should I set it as 0001, and change the rest of the bits back, or leave the rest of the bits disabled?
Dec 4, 2009, 09:23 AM
#84
I'm trying to fix some start up issues on my IDC 1000s. I believe I know which direction I need to go on the pulsewidth. But I want to get a better understand on these tables and see if I can actually derive a method to adjust start up when changing injectors and not just blindly changing values until it works.
I'm using 9653XXX6.
Is that constant adjustable? It seems like it would be a great canidate for scaling the cranking enrichment for different injectors?
Everything else looks like a multiplier and should probably be scaled as percent 128 instead of the TimeTCOMPCrankingHack that is used on the TCOMP table. The intention behind this suggested change is that the curves could beleft constant and a simple single value change should correct any issues from an injector change.
Also, on the speed density patch, that baro dependency looks a little concerning, as baro is now fixed and this table looks like it is a direct IPW calculation that is dependent on air mass. Right now I have baro set to 101 kPa, where actual Baro is 85 kPa and when heading up in the mountains, it's not hard to reach the 70 kPa range. It's not the absolute value I'm worried about, as it would be easy to tune the car at 4500'. But then going up to the mountains, I could end up 20% rich. Last thing I want to do is return from a mountain hike at sun down in -10F weather and find I can't start my car. Not a good situation.
I'm using 9653XXX6.
2) Cranking fuel pulse width
This is fuel pulse width that controls sync IPW while the starter is cranking
Two different cranking FPWs are calculated. One is used while the starter is engaged, and the other appears to be momentarily used just after the starter is disengaged. I will only cover the value that is used while the starter is engaged. The formula for the cranking FPW while the starter is engaged is:
CFPW = constant*(TCOMP/128)*(CRANKINGTIMECOMP/128)*(UCOMP/128)*Baro + InjectorLatency
* TCOMP = 2D compensation table vs coolant temp
* CRANKINGTIMECOMP = 2D compensation table vs the length of time that the starter has been engaged
* UCOMP = 2D compensation vs an unknown time interval. A measure of the number of times a specific subroutine has been called. Probably shouldn't be adjusted, so I am not including a definition for this table.
* Baro = barometric pressure.
This is fuel pulse width that controls sync IPW while the starter is cranking
Two different cranking FPWs are calculated. One is used while the starter is engaged, and the other appears to be momentarily used just after the starter is disengaged. I will only cover the value that is used while the starter is engaged. The formula for the cranking FPW while the starter is engaged is:
CFPW = constant*(TCOMP/128)*(CRANKINGTIMECOMP/128)*(UCOMP/128)*Baro + InjectorLatency
* TCOMP = 2D compensation table vs coolant temp
* CRANKINGTIMECOMP = 2D compensation table vs the length of time that the starter has been engaged
* UCOMP = 2D compensation vs an unknown time interval. A measure of the number of times a specific subroutine has been called. Probably shouldn't be adjusted, so I am not including a definition for this table.
* Baro = barometric pressure.
Everything else looks like a multiplier and should probably be scaled as percent 128 instead of the TimeTCOMPCrankingHack that is used on the TCOMP table. The intention behind this suggested change is that the curves could beleft constant and a simple single value change should correct any issues from an injector change.
Also, on the speed density patch, that baro dependency looks a little concerning, as baro is now fixed and this table looks like it is a direct IPW calculation that is dependent on air mass. Right now I have baro set to 101 kPa, where actual Baro is 85 kPa and when heading up in the mountains, it's not hard to reach the 70 kPa range. It's not the absolute value I'm worried about, as it would be easy to tune the car at 4500'. But then going up to the mountains, I could end up 20% rich. Last thing I want to do is return from a mountain hike at sun down in -10F weather and find I can't start my car. Not a good situation.
Last edited by 03whitegsr; Dec 4, 2009 at 09:45 AM.
Dec 4, 2009, 10:50 AM
#85
I'm trying to fix some start up issues on my IDC 1000s. I believe I know which direction I need to go on the pulsewidth. But I want to get a better understand on these tables and see if I can actually derive a method to adjust start up when changing injectors and not just blindly changing values until it works.
I'm using 9653XXX6.
Is that constant adjustable? It seems like it would be a great canidate for scaling the cranking enrichment for different injectors?
Everything else looks like a multiplier and should probably be scaled as percent 128 instead of the TimeTCOMPCrankingHack that is used on the TCOMP table. The intention behind this suggested change is that the curves could beleft constant and a simple single value change should correct any issues from an injector change.
Also, on the speed density patch, that baro dependency looks a little concerning, as baro is now fixed and this table looks like it is a direct IPW calculation that is dependent on air mass. Right now I have baro set to 101 kPa, where actual Baro is 85 kPa and when heading up in the mountains, it's not hard to reach the 70 kPa range. It's not the absolute value I'm worried about, as it would be easy to tune the car at 4500'. But then going up to the mountains, I could end up 20% rich. Last thing I want to do is return from a mountain hike at sun down in -10F weather and find I can't start my car. Not a good situation.
I'm using 9653XXX6.
Is that constant adjustable? It seems like it would be a great canidate for scaling the cranking enrichment for different injectors?
Everything else looks like a multiplier and should probably be scaled as percent 128 instead of the TimeTCOMPCrankingHack that is used on the TCOMP table. The intention behind this suggested change is that the curves could beleft constant and a simple single value change should correct any issues from an injector change.
Also, on the speed density patch, that baro dependency looks a little concerning, as baro is now fixed and this table looks like it is a direct IPW calculation that is dependent on air mass. Right now I have baro set to 101 kPa, where actual Baro is 85 kPa and when heading up in the mountains, it's not hard to reach the 70 kPa range. It's not the absolute value I'm worried about, as it would be easy to tune the car at 4500'. But then going up to the mountains, I could end up 20% rich. Last thing I want to do is return from a mountain hike at sun down in -10F weather and find I can't start my car. Not a good situation.
I think there is value to using the time scaling for the IPW decay table because it is accurate and can be related to real world response.
There is nothing I can easily do about the baro dependency. Something has gotta give with the current SD conversion, and this is one of those things. The SD patch could be written to allow the baro sensor to stay connected, but it would take a ton of work to update the patch, and the MAF would have to stay in the engine compartment.
Last edited by mrfred; Dec 4, 2009 at 04:39 PM.
Dec 4, 2009, 11:30 AM
#86
I see your point on the time scaling stuff. It matches what you see in a standalone doing it as you have. Somebody mentioned that while trying to scale the IDC1000s, they got to the lowest value in the table and the next step was zero, which prvented the car from starting. I also noticed the scaling increment could still be reduced though and that may allow to get down to the desired value.
What about a patch that would grab the MAP sensor reading on inital key on and then use it in situations like this?
What about a patch that would grab the MAP sensor reading on inital key on and then use it in situations like this?
Last edited by 03whitegsr; Dec 4, 2009 at 11:33 AM.
Dec 4, 2009, 12:28 PM
#87
Evolved Member
iTrader: (26)
Join Date: Oct 2005
Location: Pittsburgh
Posts: 1,712
Likes: 0
Received 0 Likes
on
0 Posts
I see your point on the time scaling stuff. It matches what you see in a standalone doing it as you have. Somebody mentioned that while trying to scale the IDC1000s, they got to the lowest value in the table and the next step was zero, which prvented the car from starting. I also noticed the scaling increment could still be reduced though and that may allow to get down to the desired value.
What about a patch that would grab the MAP sensor reading on inital key on and then use it in situations like this?
What about a patch that would grab the MAP sensor reading on inital key on and then use it in situations like this?
My id1000 woes does not seem to be anything that can be tuned out - I have been trying to tune it out since April of this year and I have never had a change make me think I was onto something. Even with these new tables no changes seem to make a difference and I have made drastic changes just to get a reaction and its always the same or worse....
Dec 5, 2009, 01:08 AM
#90
I happened to see those tables that you posted before you removed them. 3810 is never called in the 9653 ROM, and 1659 (actually 1658) is a value related to tip-in accel. It is utilized in a section of code that is specifically not called when the starter is cranking. 3822 is the unknown compensation (UCOMP) for cranking IPW that I mentioned in the advanced fuel control options thread. Its not vs RPM, but fiddling with that table would have a similar effect as fiddling with the cranking IPW TCOMP table that I posted. Are you aware that logic translated most of the 8859 advanced fuel control tables over to 9653?