Speed Density 2.0 (3D VE Tables, Baro)
Thread Starter
Evolved Member
iTrader: (5)
Joined: Oct 2006
Posts: 3,805
Likes: 2
From: Sacramento, CA
Unfortunately, the difference between the 2 tables being "enabled" is negligable. It may have been coincidental, but #2 seemed to hiccup more. But both really seemed to be pretty similar.
I did have 2D SD jitter fix #2 enabled on the test drives. But disabled it in the driveway and saw no difference with either Jitter test table while idling. I'll take another cruise around the block to make double sure. I can see where 2x idle load would be the same.
Maybe someone else will see different results...
I did have 2D SD jitter fix #2 enabled on the test drives. But disabled it in the driveway and saw no difference with either Jitter test table while idling. I'll take another cruise around the block to make double sure. I can see where 2x idle load would be the same.
Maybe someone else will see different results...
Still no difference with the original 2d jitter fix #2 disabled.
Im assuming when you say really rich, you mean at least a full point. I was basically expecting it to lookup fuel/timing for 2x the load I normally run at. (what was seen in the logs I posted)
Im assuming when you say really rich, you mean at least a full point. I was basically expecting it to lookup fuel/timing for 2x the load I normally run at. (what was seen in the logs I posted)
Thread Starter
Evolved Member
iTrader: (5)
Joined: Oct 2006
Posts: 3,805
Likes: 2
From: Sacramento, CA
The cause then is probably inside of the big main fuel/load cap loop there are quite a few branches it takes so I'll see what could happen in certain scenarios there.
Thanks RoadSpike, we really appreciate the effort you are putting into solving this. (I suggest you post up your paypal acct).
Thread Starter
Evolved Member
iTrader: (5)
Joined: Oct 2006
Posts: 3,805
Likes: 2
From: Sacramento, CA
I've poured over the big ipw sub quite a few times and the way its setup there is no way for the load to be different than the load calculated by the SD sub. So that leaves me to believe that only the multiplier which is effected outside of that sub is the thing at fault.
There are quite a few paths in this sub I chose the biggest jumps in hope that one of them was the culprit. I think I'll try a couple more this time.
Tests:
This one prevents an end skip so it will force the multiplier to be something calculated in this portion
<table name="SD Jitter Test #3 (Stock 0x8B28 -> 0x9)" address="10DC0" type="1D" level="1" scaling="Hex16"/>
This one is the warm up enrichment 3d table so i'm not too sure if this will do anything but worth a shot
<table name="SD Jitter Test #4 (Stock 0x8B0C -> 0x9)" address="10DDA" type="1D" level="1" scaling="Hex16"/>
IF possible I'd like someone to log the multiplier value when logging this jitter its location in ram for 9653 is 8ABB.
If it turns out that the multiplier is being randomly effected and for the most part stays static we may try something like forcing the multiplier to a static value.
Last edited by RoadSpike; Apr 13, 2011 at 08:11 PM.
Im pretty sure you need to add 8abb to a spot in the MUT table that isnt already being utilized. Then add that requestID as a new loggable item in evoscan.
Im not sure of a "safe" spot to put it in the MUT table without searching around a bit, though.
Im not sure of a "safe" spot to put it in the MUT table without searching around a bit, though.
Thats my problem.
There's no reason you couldnt temporarily use a spot that is being utilized just to get the info. I just dont know what consequences would come of changing something that is used in a stock rom.
https://www.evolutionm.net/forums/7597107-post2.html
Id probably change requestID 40 (gear, as per the post above) to 8abb, do a save-as on the rom. Get the info by logging "gear" in evoscan, then flash back to your original so you can log the real gear info later on.
There's probably a ton of spots you could safely put it. But there shouldnt be any issues doing it this way.
https://www.evolutionm.net/forums/7597107-post2.html
Id probably change requestID 40 (gear, as per the post above) to 8abb, do a save-as on the rom. Get the info by logging "gear" in evoscan, then flash back to your original so you can log the real gear info later on.
There's probably a ton of spots you could safely put it. But there shouldnt be any issues doing it this way.
The multiplier mostly stays at 128. When I first started, it was 133, then slowly came down to 128 over the course of 2 logging sessions.
I cant see a change in the multiplier during the load spike.
Jitter test #3 seems no different then 1 & 2
Jitter test #4 almost had me fooled. I thought the hiccup was completely gone. Then got it only at low rpm 2100-2500 twice. But during the entire testing session I had all jitter fixes disabled except for the one I was testing. What I saw may be the original 2d jitter. I could not replicate it like I can the 3d hiccup/jitter.
Fueling seemed to be the same during all tests.
And I dont think it can be said enough..but thank you for what youre doing. Even with the hiccup, Ive been running your rom for the past couple weeks daily, and Im still loving it.
Let me know if you'd like some logs. And if you want them trimmed down to the spikes. But they're really no different than the ones I posted earlier.
I cant see a change in the multiplier during the load spike.
Jitter test #3 seems no different then 1 & 2
Jitter test #4 almost had me fooled. I thought the hiccup was completely gone. Then got it only at low rpm 2100-2500 twice. But during the entire testing session I had all jitter fixes disabled except for the one I was testing. What I saw may be the original 2d jitter. I could not replicate it like I can the 3d hiccup/jitter.
Fueling seemed to be the same during all tests.
And I dont think it can be said enough..but thank you for what youre doing. Even with the hiccup, Ive been running your rom for the past couple weeks daily, and Im still loving it.
Let me know if you'd like some logs. And if you want them trimmed down to the spikes. But they're really no different than the ones I posted earlier.
Last edited by charlie.tunah; Apr 14, 2011 at 04:09 PM.
Thread Starter
Evolved Member
iTrader: (5)
Joined: Oct 2006
Posts: 3,805
Likes: 2
From: Sacramento, CA
The multiplier mostly hovers at 128. When I first started, it was 133, then slowly came down to 128 over the course of 2 logging sessions.
I cant see a change in the multiplier during the load spike.
Jitter test #3 seems no different then 1 & 2
Jitter test #4 almost had me fooled. I thought the hiccup was completely gone. Then got it only at low rpm 2100-2500 twice. But during the entire testing session I had all jitter fixes disabled except for the one I was testing. What I saw may be the original 2d jitter. I could not replicate it like I can the 3d hiccup/jitter.
Fueling seemed to be the same during all tests.
And I dont think it can be said enough..but thank you for what youre doing. Even with the hiccup, Ive been running your rom for the past couple weeks daily, and Im still loving it.
Let me know if you'd like some logs. And if you want them trimmed down to the spikes. But they're really no different than the ones I posted earlier.
I cant see a change in the multiplier during the load spike.
Jitter test #3 seems no different then 1 & 2
Jitter test #4 almost had me fooled. I thought the hiccup was completely gone. Then got it only at low rpm 2100-2500 twice. But during the entire testing session I had all jitter fixes disabled except for the one I was testing. What I saw may be the original 2d jitter. I could not replicate it like I can the 3d hiccup/jitter.
Fueling seemed to be the same during all tests.
And I dont think it can be said enough..but thank you for what youre doing. Even with the hiccup, Ive been running your rom for the past couple weeks daily, and Im still loving it.
Let me know if you'd like some logs. And if you want them trimmed down to the spikes. But they're really no different than the ones I posted earlier.
Out of curiosity did you try them both at once? That would prevent the end skip and force it into the loop for #4. Thinking the combination may reveal something