Speed Density IPW Drop Out on 96530006 Patch
Nov 26, 2009, 12:30 PM
#1
Speed Density IPW Drop Out on 96530006 Patch
To keep from cluttering up another section of the speed density thread, I thought it might be good to start a new thread to investigate the injector pulse width drop out issue L2r99gst and a few others noticed on the 96530006 speed density patch.
To start, I personally have not noticed this behavior, but I trust the logs posted up and I do believe it to be an issue that I just haven't noticed. I will leave it up to l2r99gst to post his most complete documentation of the issue, as I know he's tested a few different things to try and figure it out.
Looking through the manual, I noticed the MAF has a reset signal that is received from the ECU that controls the filter circuits within the MAF. My thinking is maybe the when the ECU changes from one filter to another, it expects a certain change to the MAFSOURCEMAIN variable. Now that we are calculating that variable with the SD tables, it may not match what the ECU wants under these transition conditions. The pulsewidth drop out then would be associated with the transition between these two filters and the conditions L2r99gst has found to be affected may just be in that transition region. I'm not claiming this is the solution though, just saying it might be worth looking into.
The FSM excerpt is in this post:
https://www.evolutionm.net/forums/7745481-post175.html
https://www.evolutionm.net/forums/at...-maf-reset.zip
I looked at the dissassembly and made a rough flow chart of the code. Please be easy on me, I'm not a software guy at all. I just have the superH manual and am trying to make sense out of everything as I go. I very likely could have got some instructions and conditionals wrong. Below is what I have found thus far. I haven't had a chance to look at the MUT table and see if any of the RAM addresses show up in it. I also just used the names on stuff that is defined in ECUFlash and left everything else unnamed. C0, C1, C2 etc. are constants. Also, I was running out of time and the loc_11484 section is unmarked on the conditionals.
The flow diagram and code is posted below. Hope this helps resolve the issues in the long run.
Thanks
Anyway, I'm off for turkey.
Happy Holidays.
To start, I personally have not noticed this behavior, but I trust the logs posted up and I do believe it to be an issue that I just haven't noticed. I will leave it up to l2r99gst to post his most complete documentation of the issue, as I know he's tested a few different things to try and figure it out.
Looking through the manual, I noticed the MAF has a reset signal that is received from the ECU that controls the filter circuits within the MAF. My thinking is maybe the when the ECU changes from one filter to another, it expects a certain change to the MAFSOURCEMAIN variable. Now that we are calculating that variable with the SD tables, it may not match what the ECU wants under these transition conditions. The pulsewidth drop out then would be associated with the transition between these two filters and the conditions L2r99gst has found to be affected may just be in that transition region. I'm not claiming this is the solution though, just saying it might be worth looking into.
The FSM excerpt is in this post:
https://www.evolutionm.net/forums/7745481-post175.html
https://www.evolutionm.net/forums/at...-maf-reset.zip
I looked at the dissassembly and made a rough flow chart of the code. Please be easy on me, I'm not a software guy at all. I just have the superH manual and am trying to make sense out of everything as I go. I very likely could have got some instructions and conditionals wrong. Below is what I have found thus far. I haven't had a chance to look at the MUT table and see if any of the RAM addresses show up in it. I also just used the names on stuff that is defined in ECUFlash and left everything else unnamed. C0, C1, C2 etc. are constants. Also, I was running out of time and the loc_11484 section is unmarked on the conditionals.
The flow diagram and code is posted below. Hope this helps resolve the issues in the long run.
Thanks
Anyway, I'm off for turkey.
Happy Holidays.
Last edited by 03whitegsr; Dec 27, 2009 at 09:37 PM.
Nov 26, 2009, 04:15 PM
#2
Evolving Member
Join Date: Apr 2008
Location: Reading, PA
Posts: 265
Likes: 0
Received 0 Likes
on
0 Posts
The older ecus also had MAF signal scaling.
At low airflow, both the rising and falling edge of the signal was counted.
At high airflow, only the falling edge was counted.
This allowed the ecu to keep up at high Karmen Hz, because only half of the signals where counted. And also have high resolution at low airflow.
I am unsure if the newer evo ecus have the MAF signal scaling, but if they do the scaling transition point could be another culprit for the IPW jitter.
Does the jitter always happen at specific Load or Hz?
At low airflow, both the rising and falling edge of the signal was counted.
At high airflow, only the falling edge was counted.
This allowed the ecu to keep up at high Karmen Hz, because only half of the signals where counted. And also have high resolution at low airflow.
I am unsure if the newer evo ecus have the MAF signal scaling, but if they do the scaling transition point could be another culprit for the IPW jitter.
Does the jitter always happen at specific Load or Hz?
Nov 26, 2009, 04:49 PM
#3
I'll have to look over some of my old posts and logs, but from what I remember, it was a very specific map and RPM range. Both had to be true for the IPW jiiter to happen. I think it was approx. 65-85kpa absolute and 1800-2400RPM.
For anyone who feels like reading, it starts here. It is discussed on and off for about 15 pages, but I think in those pages will be everything that I had tried as well as suggestions from John, mrfred, and others.
I'll go through that thread and post some screenshots of the logs in thread for reference, so that we can all see what the issue is.
Eric
For anyone who feels like reading, it starts here. It is discussed on and off for about 15 pages, but I think in those pages will be everything that I had tried as well as suggestions from John, mrfred, and others.
I'll go through that thread and post some screenshots of the logs in thread for reference, so that we can all see what the issue is.
Eric
Last edited by l2r99gst; Nov 26, 2009 at 05:18 PM.
Nov 26, 2009, 04:52 PM
#4
Here are my screenshots from page 4 of that thread:
OK, I think I have narrowed it down to 65-85 kpa/1800-2400RPM. Both of those have to be true for the issue to show itself.
Here are three areas of that log to illustrate what I mean. It may be hard to see with a lot of crap here, but the bottom half of the graphs are the area to look at. I have two markers for the RPM range, which are dotted red and blue horizontal lines. The IPW is a light blue, load is red, RPM is light purple, map is blue:
This is right after a shift, coming into the problem area. Even though I stay in the RPM range here, once the map drops below 65kpa, everything smooths out. Notice the jagged IPW in the trouble area.
The left side shows the trouble, the right side shows normal. Notice once I get over the RPM range, everything smooths out nicely.
This one shows a good example of a nice smooth IPW on the left side of the graph. Then, when I cruise through the trouble RPM zone at the right map, you can see the jagged IPW and even a couple areas of jagged RPM. It almost feels like very minute repeated fuel cuts.
Here are three areas of that log to illustrate what I mean. It may be hard to see with a lot of crap here, but the bottom half of the graphs are the area to look at. I have two markers for the RPM range, which are dotted red and blue horizontal lines. The IPW is a light blue, load is red, RPM is light purple, map is blue:
This is right after a shift, coming into the problem area. Even though I stay in the RPM range here, once the map drops below 65kpa, everything smooths out. Notice the jagged IPW in the trouble area.
The left side shows the trouble, the right side shows normal. Notice once I get over the RPM range, everything smooths out nicely.
This one shows a good example of a nice smooth IPW on the left side of the graph. Then, when I cruise through the trouble RPM zone at the right map, you can see the jagged IPW and even a couple areas of jagged RPM. It almost feels like very minute repeated fuel cuts.
Nov 26, 2009, 04:55 PM
#5
Cool, well let's start by trying to get some solid examples of what datalogs look like during these periods, try and track down what ecu routines might cause it (like the above mentioned maf reset), try and alter them, and then test it out. This is imho the only flaw in the current speed density implementation, but I am pretty green at using it. However, I plan on continuing to use it 
Nov 26, 2009, 05:02 PM
#6
Just quoting myself from the other thread to try to add pertinent data to this thread:
I appreciate the effort. Load is jittery as well, but again, not as much as the IPW. You can see the various screenshots that I have posted within the last few pages (starts on page 4).
The following are 'jittery' during the issue:
-load (I am just logging tephra's 1byte load right now)
-map
-Hz
-RPM (sometimes...this is what I can feel and I think is an effect of the IPW)
-IPW (seems to occur in the 2ms-4.5ms area)
It seems to happens only between 65-85 kpa and 1800-2400 RPM. Both have to be true for the problem to arise. Once outside either of those ranges, the IPW smooths out and no hesitation can be felt.
Of all of those, IPW has the biggest jumps, maybe a change of up to 80% (in some cases it appears to be a rapid drop down...say from 3.6ms to 1.99ms). The rest are miniscule in comparison. The curve that seems to follow the jittery IPW the closest is Hz, if zoomed in sufficiently for proper resolution. but, this is maybe a 10Hz swing in the 125-225 Hz range, so in the 5% range.
The following are 'jittery' during the issue:
-load (I am just logging tephra's 1byte load right now)
-map
-Hz
-RPM (sometimes...this is what I can feel and I think is an effect of the IPW)
-IPW (seems to occur in the 2ms-4.5ms area)
It seems to happens only between 65-85 kpa and 1800-2400 RPM. Both have to be true for the problem to arise. Once outside either of those ranges, the IPW smooths out and no hesitation can be felt.
Of all of those, IPW has the biggest jumps, maybe a change of up to 80% (in some cases it appears to be a rapid drop down...say from 3.6ms to 1.99ms). The rest are miniscule in comparison. The curve that seems to follow the jittery IPW the closest is Hz, if zoomed in sufficiently for proper resolution. but, this is maybe a 10Hz swing in the 125-225 Hz range, so in the 5% range.
Nov 26, 2009, 05:06 PM
#7
Things that I remember trying and gathering from the other thread that didn't sovle the issue as well as things that were eliminated as causes:
1. Running in full time open loop
2. Capping EGR nipples to take EGR out of the loop
3. Making maf scaling and smoothing a constant value in the culprit range
4. Lean spool
5. Spark plugs
6. Map sensor (never used a different map sensor...but map was within 1-2kpa variation at most during the issue)
7. Different version of 96530006...v5, v7t5, v7t6, etc
I think a few more...I will add them as I read through my old posts.
1. Running in full time open loop
2. Capping EGR nipples to take EGR out of the loop
3. Making maf scaling and smoothing a constant value in the culprit range
4. Lean spool
5. Spark plugs
6. Map sensor (never used a different map sensor...but map was within 1-2kpa variation at most during the issue)
7. Different version of 96530006...v5, v7t5, v7t6, etc
I think a few more...I will add them as I read through my old posts.
Last edited by l2r99gst; Nov 26, 2009 at 05:13 PM.
Trending Topics
Nov 26, 2009, 05:08 PM
#8
Quoting another post with logs that mrfred wanted me to do:
OK, here we go...here are some screenshots, followed by the two logs (way to the gym and way home). I have a lot of other things logged, but with DMA, it doesn't matter...just hide those.
This shows the jagged IPW, with the other curves labeled....IPW smooths out once past the 2500 RPM mark:
This shows another area while cruising in the trouble zone:
This shows cruising outside of the trouble zone (map too low), with a smoother IPW:
This shows idle with a nice flat IPW:
Ah crap...the .dif files are too big. Zipped up, they are about 150kb, too big to post. Let me know if you want me to email them to you.
I wonder maybe if this is some sort of misfire, since gear head mentioned he even got a P0300. My plugs are due for a change, but this doesn't happen with the MAF, only SD. I can flash back this weekend to double check again.
This shows the jagged IPW, with the other curves labeled....IPW smooths out once past the 2500 RPM mark:
This shows another area while cruising in the trouble zone:
This shows cruising outside of the trouble zone (map too low), with a smoother IPW:
This shows idle with a nice flat IPW:
Ah crap...the .dif files are too big. Zipped up, they are about 150kb, too big to post. Let me know if you want me to email them to you.
I wonder maybe if this is some sort of misfire, since gear head mentioned he even got a P0300. My plugs are due for a change, but this doesn't happen with the MAF, only SD. I can flash back this weekend to double check again.
Nov 26, 2009, 05:12 PM
#9
Another post of mine:
Here is a screenshot from the MAF log, showing a cruise right through the issue area while using the SD ROM:
Note the IPW is very smooth and tight. It only varies by one loggable step, rather than jumping between 2-4ms like with SD. This is the same exact range where the problem exists with SD.
Note the IPW is very smooth and tight. It only varies by one loggable step, rather than jumping between 2-4ms like with SD. This is the same exact range where the problem exists with SD.
Nov 26, 2009, 05:16 PM
#10
After reviewing some of logic's logs:
OK, I analyzed a few more logs from logic as well as used his ROM on my car, just to make sure nothing in my ROM was the culprit.
Even with his ROM, I still experienced the issue. The issue is definitely subtle and maybe some just don't feel it for some reason, but it's there and the jumpy IPW shows in the log to prove it.
Upon analyzing logic's logs (as one is shown in the screenshot two posts up), it appears that he actually is experiencing the same exact issue I am. His IPW jumps seems to be about 50% smaller in amplitude, but I believe that's because his injectors are about 50% bigger than mine. I'm still on stock injectors, but I'm about to install the Bluemax 1250s.
So, now the question is, why do I feel this issue and logic doesn't? Maybe I just cruise in the range more often and am more used to this particular area being smooth? Maybe the larger injectors help lessen the effect that I can feel in my car? I don't know...I'm a bit stumped. All I know is that the IPW seems way more jumpy using the SD patch in that specific map/rpm range on both my logs and logic logs, as well as gear head's log from a few pages back. Why I can feel it, I think gear head can feel it, and logic can't stumps me. Heck, the whole reason why the IPW is so jumpy in that range stumps me.
Even with his ROM, I still experienced the issue. The issue is definitely subtle and maybe some just don't feel it for some reason, but it's there and the jumpy IPW shows in the log to prove it.
Upon analyzing logic's logs (as one is shown in the screenshot two posts up), it appears that he actually is experiencing the same exact issue I am. His IPW jumps seems to be about 50% smaller in amplitude, but I believe that's because his injectors are about 50% bigger than mine. I'm still on stock injectors, but I'm about to install the Bluemax 1250s.
So, now the question is, why do I feel this issue and logic doesn't? Maybe I just cruise in the range more often and am more used to this particular area being smooth? Maybe the larger injectors help lessen the effect that I can feel in my car? I don't know...I'm a bit stumped. All I know is that the IPW seems way more jumpy using the SD patch in that specific map/rpm range on both my logs and logic logs, as well as gear head's log from a few pages back. Why I can feel it, I think gear head can feel it, and logic can't stumps me. Heck, the whole reason why the IPW is so jumpy in that range stumps me.
Nov 26, 2009, 05:21 PM
#11
Cool, well let's start by trying to get some solid examples of what datalogs look like during these periods, try and track down what ecu routines might cause it (like the above mentioned maf reset), try and alter them, and then test it out. This is imho the only flaw in the current speed density implementation, but I am pretty green at using it. However, I plan on continuing to use it
I'm not 100% sure that it is this Maf Sensor Filtering table that John and mrfred refer to as the smoothing routine, but if so, it may not do anything for the SD patch. I'd be more than happy to test it out, though, if it in fact still is in operation. From what 03whitegsr posted, it makes sense that it may be involved.
Last edited by l2r99gst; Nov 26, 2009 at 05:23 PM.
Nov 26, 2009, 09:08 PM
#12
The older ecus also had MAF signal scaling.
At low airflow, both the rising and falling edge of the signal was counted.
At high airflow, only the falling edge was counted.
This allowed the ecu to keep up at high Karmen Hz, because only half of the signals where counted. And also have high resolution at low airflow.
I am unsure if the newer evo ecus have the MAF signal scaling, but if they do the scaling transition point could be another culprit for the IPW jitter.
Does the jitter always happen at specific Load or Hz?
At low airflow, both the rising and falling edge of the signal was counted.
At high airflow, only the falling edge was counted.
This allowed the ecu to keep up at high Karmen Hz, because only half of the signals where counted. And also have high resolution at low airflow.
I am unsure if the newer evo ecus have the MAF signal scaling, but if they do the scaling transition point could be another culprit for the IPW jitter.
Does the jitter always happen at specific Load or Hz?
May be on to something here.
Considering the almost halving of the IPW that L2r99GST has been seeing. I have to wonder if even if the MAF filtering stuff is replaced, if a variable from that section of the calcs is used later in the main fuel routine to correct for the switch between the two.
Also, I may be way off, but instead of the the values at 1508 and 150A being filter factor values, I wonder if they are threshold values. Say like:
MAF Filter low -> High = 217 Hz
MAF Filter high -> low = 192 Hz
I posted up the flow chart in hopes that we could maybe identify the RAM addresses and somebody that has a good example of the issue could log the channels of interest and maybe see if there is a correlation.
L2r99gst, thanks a ton for posting up the great data. I knew I had seen a lot on it before, but I wasn't sure where it all was and thought you could probably make better order out of it.
Last edited by 03whitegsr; Nov 26, 2009 at 09:12 PM.
Nov 27, 2009, 12:16 AM
#13
I've been putting some time into trying to figure out this issue, and there are a couple of areas where I can provide some clarification:
1) You guys may already know this, but the name "MAF filter" is somewhat of a misnomer. This value is used to calculate a weighted running average between the old master load value and the newly calculated master load (from the MAF). The formula goes like:
MasterLoad = [MAFfilter*MasterLoadOld + (256-MAFfilter)*MasterLoadNew]/256
2) SD master load is inserted in place of MAF master load further down in the master load calculation subroutine, so SD master load is not affected by this running average calculation, and thus any changes in the "MAF filter" value have no effect on the SD master load.
However, in looking a little further just now, I do see that there is a flag that gets set at the end of the subroutine where the weighting value is determined. The value of the flag is dependent on whether the weighting parameter is above or below 205. This flag doesn't affect the master load calculation, but it does affect some of the calculations for the fuel pulse width. This is the best candidate that I've seen for causing the jittery IPW issue. I'll see if I can look at it further this weekend and perhaps come up with a patch to test it.
EDIT: Having thought about it a little more, it should be pretty easy to test this. We can create a 1D table for the over/under value, and then set the over/under value to 255. Another over/under value to try would be 0. This value is below all the possible weighting parameter values. For the 9653 ROM, the address of the over/under value is 0x162C. Its a word length value, so use uint16 for the scaling.
1) You guys may already know this, but the name "MAF filter" is somewhat of a misnomer. This value is used to calculate a weighted running average between the old master load value and the newly calculated master load (from the MAF). The formula goes like:
MasterLoad = [MAFfilter*MasterLoadOld + (256-MAFfilter)*MasterLoadNew]/256
2) SD master load is inserted in place of MAF master load further down in the master load calculation subroutine, so SD master load is not affected by this running average calculation, and thus any changes in the "MAF filter" value have no effect on the SD master load.
However, in looking a little further just now, I do see that there is a flag that gets set at the end of the subroutine where the weighting value is determined. The value of the flag is dependent on whether the weighting parameter is above or below 205. This flag doesn't affect the master load calculation, but it does affect some of the calculations for the fuel pulse width. This is the best candidate that I've seen for causing the jittery IPW issue. I'll see if I can look at it further this weekend and perhaps come up with a patch to test it.
EDIT: Having thought about it a little more, it should be pretty easy to test this. We can create a 1D table for the over/under value, and then set the over/under value to 255. Another over/under value to try would be 0. This value is below all the possible weighting parameter values. For the 9653 ROM, the address of the over/under value is 0x162C. Its a word length value, so use uint16 for the scaling.
Last edited by mrfred; Nov 30, 2009 at 10:04 AM.
Nov 27, 2009, 07:39 AM
#14
Awesome mrfred! I'm out of town until Sunday night; I'll def try it when I get back.
Can you double-check my XML:
<table name="MAF Pulsewidth reset (test)" category="Speed Density Tuning" address="162c" type="1D" scaling="uint16"/>
Can you double-check my XML:
<table name="MAF Pulsewidth reset (test)" category="Speed Density Tuning" address="162c" type="1D" scaling="uint16"/>
Last edited by scheides; Nov 27, 2009 at 08:18 AM.