I don't have a problem running as you did in the cold start thread but only idle when its warmed up ironically. I didn't want to disable too many periphery bits becuase my EGR is still attached and functional.

My car doesn't go silly lean as yours did when giving it gas.

 

It has to be an SD thing then.

 

I plan to change MUT00 address to 0x8CCD temporarily and log it at evoscan as is (no scaling).

MUT00 / 01 are predefined as airflow rate at 94170715 V7, so if you do not log airflow rate at the same time, you should not have any problem.

This evoscan definition should work (just display 8 bit data as 0~255 integer):

<DataListItem DataLog="Y" Color="" Display="Tephra_Var" LogReference="TephraVar" RequestID="00" Eval="x" Unit="units" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="300" ChartMin="0" ChartMax="300" ScalingFactor="1" Notes="" Priority="1" Visible="False" />

 

Indeed AND I have the problem solved!

The solution was simple just renabled closed loop and the SWFT for the o2 sensor kicks back in stopping the weird AFRMAP dip. I'm not sure why this is but it must be something related to temperature.

I discovered this by reading an old post where AFRMAP was moving around on its own. MrFred said that it was related to the o2 sensors so on a hunch i enabled closed loop again solving the problem.

So warning to those using SD and tuning with open loop disabled

 

well we would have got there eventually

 

Roadspike, the issue is still likely there. Closed loop is just hiding it.

Log AFRMAP and you'll probably see it jumping around when it shouldn't be.

 

I did and confirmed its a rock solid 14.7 AFRMAP

 

Keep an eye on it as I see the AFRMAP stuff be stable some days and others it bounces around like crazy.

 

I'm convinced the AFRMAP is in that wierd calculation that uses the front o2 sensor to calculate the afrmap from scratch. Since I had the o2 feedback disabled it somehow got in there still. We need a dev guy to get in to the main fuel loop and see if there is some way of blocking out this code loop so when we use full time open loop it wont happen.

I also noticed that AFRMAP was rock solid until exactly 70C engine temp on my car which may correlate to the min temp for closed loop variable.

 

Any progress on the boost problem? Has mrfred looked at this??? I can't log the above MUTs as my car is apart. I have a race Sun. that I am trying to make. Any news/help would be appreciated.

 

well there was two problems
1) gear wasn't being calculated properly, fix posted a few pages back
2) car wasn't going into closed loop - which means boost error/tbec wasn't being calculated properly..

fix discovered a few posts up

 

Does that look right? I have been trying to get the logs for the MUT tables you requested, and haven't had a chance... Do I need to drive or can i just let the car idle and log?

 

Nice. It was not clear if the closed loop problem was only Speed Density (SD) or MAF and SD roms.

 

Wait you think my closed loop issue was a solution?

I was on a tangent but just a related 94170015 issue. I found the solution to my afrmap going all wonky but I didn't have a solution to the gear based boost control.


Side notes:

I do have a log of some brief interaction of my red being controlled by psi based boost control but nothing to really test out the gear based boost. I really need to turn down my boost via the map and see if its more heavily controlled and get more accurate results :P

 

I also did not think that this solved the boost error/tbec problem.

Besides, I do not think that in my case the ecu was not going into closed loop...