Readiness - Catalyst

[carabuser]

Just to update, we went through a lot of parameters and custom logging via PM to get find a way to stop this lambda oscillation. It doesn't seem to be caused by the usual cat diagnostic.

We finally found a toggle that fix the behaviour:
Setting C_TEMP_CAT_MIN_LAM_ADJ_ACT (0x4132C on I8A0S) to 1772 stopped this oscillation.

This disables some component of the trim routine (doesn't effect the normal STFT or LTFT values). I intend to go further back in this routine and work out the root cause but this is just an update for anyone following along.

 

[Neophyte]

Excellent work! The default value of the table is 162.00? Not sure if it needs to be in hex value or?

 

[corbanistan]

Thanks @carabuser!

"The constant represents the minimum threshold for of the Catalyst temperature for activation of the trim controller. (e.g. 300 °C)."

"Dynamic fuel trim (LACO_REQGNTRIM0): Trim control should be deactivated to not generate a set point shift with the P share output (eg. set C_TEMP_CAT_MIN_LAM_ADJ_ACT to maximum value)."

 

[corbanistan]

Excellent work! The default value of the table is 162.00? Not sure if it needs to be in hex value or?

Gonna be 16bit LSB First. Equation is (0.0625 * X) - 273.15
Default value for me is 88.98

 

[studio54]

Yes, thanks to @carabuser for all the help, we tried a lot of stuff

On mine, the default value is 362.13 C° but the equation used was simply : X*0.0625

After setting it to 1772, here are 2 logs (cruising + idle) :

https://www.spoolstreet.com/graphs/13-01.14721/?series=7,13,14,21&zoom=-4,451

 

[335iN54]

Just to update, we went through a lot of parameters and custom logging via PM to get find a way to stop this lambda oscillation. It doesn't seem to be caused by the usual cat diagnostic.

We finally found a toggle that fix the behaviour:
Setting C_TEMP_CAT_MIN_LAM_ADJ_ACT (0x4132C on I8A0S) to 1772 stopped this oscillation.

This disables some component of the trim routine (doesn't effect the normal STFT or LTFT values). I intend to go further back in this routine and work out the root cause but this is just an update for anyone following along.

This is really good outcome!
I wonder if there is similar issue on other BMW engines and other cars in general and whether tuners have dealt with it.

Also can you advise if MHD OTS maps can be exported on a file to apply these modifications as I do not have a custom tune?

Thanks

 

[335iN54]

Yes, thanks to @carabuser for all the help, we tried a lot of stuff

On mine, the default value is 362.13 C° but the equation used was simply : X*0.0625

After setting it to 1772, here are 2 logs (cruising + idle) :

https://www.spoolstreet.com/graphs/13-01.14721/?series=7,13,14,21&zoom=-4,451

View attachment 64087

Your idle afrs are mint!
RPM is in 650 to 670 range which is as smooth as it can be.
On mine with afr oscillation rpm jumps to slightly over 700 routinely

 

[carabuser]

I just want to be clear that this isn't a new feature or a fix that everyone needs. This is just a fix for a specific issue that @studio54 was experiencing with his car. If your car has lambda readings that oscillate across eachother in a helix pattern then post a log here and we can try find out what toggles work for your circumstance.

I have seen the lambda oscillations in a lot of logs for catless cars but the causes vary. It seems they all stem from diagnostic routines but there's not just one that can cause this dancing afr issue. They are only present below 4k rpm and at low pedal input so most people don't know they are there and don't pick up on the associated surging feeling it generates.

I personally had the problem on both my cars and I started digging and it turned out to be caused by the catalyst efficiency diagnostic routine so I disabled that and everything is happy. The fix on my INA0S cars was completely different to Studio54's I8A0S car. It might just be that the routines are slightly different between MSD80 and MSD81.

This is only applicable to custom tuners though. The OTS maps are locked for a reason and it's not fair to Wedge to change that. If there's some consensus on the fix maybe it will be added into the "catless downpipe" tickbox in MHD but that would need buy-in from Jake and probably need a few more case studies.

 

[Neophyte]

Yes, thanks to @carabuser for all the help, we tried a lot of stuff

On mine, the default value is 362.13 C° but the equation used was simply : X*0.0625

After setting it to 1772, here are 2 logs (cruising + idle) :

https://www.spoolstreet.com/graphs/13-01.14721/?series=7,13,14,21&zoom=-4,451

That looks really odd without the signature wave!

I'll see how mine goes. Thanks heaps guys

 

[studio54]

Yes, it could be great if added as a tickbox in MHD flasher for use with OTS maps.

When searching on Google :

site:datazap.me "i8a0s" "stage 2"

(Assuming that those stage 2 logs are made without primary cats as intented)

We can find lots of logs, unfortunately most logs are just recorded from the WOT, but on some we can spot a few seconds of AFR during ~2500 rpm cruising just prior to WOT, and on most of them we can spot the ~13.8-~15 helix. However we cannot be sure if it's related to the trim control like on mine, we need more i8a0s people to check if they got the bouncing just by doing an idle log 2-3 minutes after startup, and if so then test with a modified bin.

As I told to carabuser, I don't know if it was in my head, but the car felt a bit smoother at low load.

 

[carabuser]

Yes, it could be great if added as a tickbox in MHD flasher for use with OTS maps.

When searching on Google :

site:datazap.me "i8a0s" "stage 2"

(Assuming that those stage 2 logs are made without primary cats as intented)

We can find lots of logs, unfortunately most logs are just recorded from the WOT, but on some we can spot a few seconds of AFR during ~2500 rpm cruising just prior to WOT, and on most of them we can spot the ~13.8-~15 helix. However we cannot be sure if it's related to the trim control like on mine, we need more i8a0s people to check if they got the bouncing just by doing an idle log 2-3 minutes after startup, and if so then test with a modified bin.

As I told to carabuser, I don't know if it was in my head, but the car felt a bit smoother at low load.

I used that search and also tried IJE0S too and every single log that had some non-WOT action had that problem. It seems any catless car is going to suffer from it.

@Jake@MHD Would MHD consider adding this fix as part of the catless downpipe flash option?

Hopefully we can distil it down to one or two toggles in the calibration.

 

[335iN54]

Not sure about not being fair to MHD. Its not like we want to steal their maps!
Just some minor changes to fix something that should have been considered in first place, anyway...

 

[carabuser]

Not sure about not being fair to MHD. Its not like we want to steal their maps!
Just some minor changes to fix something that should have been considered in first place, anyway...

MHD and (WedgePerformance) Ken are very different entities. I think MHD just give Ken a small slice of the OTS map pack sales and he enjoys the benefits of association when it comes to selling custom tunes. Ken doesn't really do any big R&D he just offers up his base tunes and has no input on the technical stuff within the DME whereas Jake at MHD is the one responsible for all the developments across all their supported ECUs.

The OTS maps have a few issues in them but those are present in every other tune out there. I always take a look at the unlocked OTS tunes when they come out just to see what's actually going on and they don't have anything exciting, basically nothing changed outside of what is available in the public XDF. There's not a big difference between what the OTS offer and what you get using the other free available bins from BMS, COBB or RFP. If I went and gave out unlocked copies of other people's tunes it wouldn't be long before people did the same to me.

In an ideal world someone like Jake would be digging into the logic and working closely with a tuner to get a perfect map but that just takes way too much time. Basically aside from the developments that come about on these forums, nothing has really been done since COBB finished their dev work. They went through the documentation and selected all the tables they felt relevant and defined them in their own "XDF" and also put all the hard work finding the RAM addresses that are needed for key parameters that we all use for our logging.

There's no real sense in Jake spending hours digging through this stuff as it wouldn't bring any new customers to MHD and would take his time away from the million other things he's being asked for. I do think that if we work out exactly what needs to be fixed then Jake might make that change to MHD.

 

[corbanistan]

MHD and (WedgePerformance) Ken are very different entities. I think MHD just give Ken a small slice of the OTS map pack sales and he enjoys the benefits of association when it comes to selling custom tunes. Ken doesn't really do any big R&D he just offers up his base tunes and has no input on the technical stuff within the DME whereas Jake at MHD is the one responsible for all the developments across all their supported ECUs.

The OTS maps have a few issues in them but those are present in every other tune out there. I always take a look at the unlocked OTS tunes when they come out just to see what's actually going on and they don't have anything exciting, basically nothing changed outside of what is available in the public XDF. There's not a big difference between what the OTS offer and what you get using the other free available bins from BMS, COBB or RFP. If I went and gave out unlocked copies of other people's tunes it wouldn't be long before people did the same to me.

In an ideal world someone like Jake would be digging into the logic and working closely with a tuner to get a perfect map but that just takes way too much time. Basically aside from the developments that come about on these forums, nothing has really been done since COBB finished their dev work. They went through the documentation and selected all the tables they felt relevant and defined them in their own "XDF" and also put all the hard work finding the RAM addresses that are needed for key parameters that we all use for our logging.

There's no real sense in Jake spending hours digging through this stuff as it wouldn't bring any new customers to MHD and would take his time away from the million other things he's being asked for. I do think that if we work out exactly what needs to be fixed then Jake might make that change to MHD.

Well said @carabuser and thanks for your efforts here. Thanks to people like you all on forums and free time by myself my XDF is tons larger than the public one. I've fixed and added many descriptions and titles too for easier understanding. Maybe soon in the future I'll put it up on a public Github so beginners can take a crack at it.

Only other thing I was wondering is if you could confirm the C_TEMP_CAT_MIN_LAM_ADJ_ACT equation. WinOLS is giving me something different than docs and this forum. Thanks.

 

[carabuser]

Well said @carabuser and thanks for your efforts here. Thanks to people like you all on forums and free time by myself my XDF is tons larger than the public one. I've fixed and added many descriptions and titles too for easier understanding. Maybe soon in the future I'll put it up on a public Github so beginners can take a crack at it.

Only other thing I was wondering is if you could confirm the C_TEMP_CAT_MIN_LAM_ADJ_ACT equation. WinOLS is giving me something different than docs and this forum. Thanks.

Just going off the Continental manual:
C_TEMP_CAT_MIN_LAM_ADJ_ACT
2 byte, LSB First. signed
Conversion = X*0.0625-273.15

I think the representation for signed registers differs between the continental and BMW layer. In the continental layer you need to apply the offset. In the BMW layer it's easy, just select it as signed and your done.
So for the value in question:

You see that it's 0 to 7FFF in hex which scales to -273.15 to 1774.7875. So 0 in hex equals -273.15 and 7FFF would be 1774.7875.

 

[RSL]

273.15 is Kelvin conversion. 0K = -273.15C

 

[corbanistan]

Just going off the Continental manual:
C_TEMP_CAT_MIN_LAM_ADJ_ACT
2 byte, LSB First. signed
Conversion = X*0.0625-273.15

I think the representation for signed registers differs between the continental and BMW layer. In the continental layer you need to apply the offset. In the BMW layer it's easy, just select it as signed and your done.
So for the value in question:
View attachment 64118

You see that it's 0 to 7FFF in hex which scales to -273.15 to 1774.7875. So 0 in hex equals -273.15 and 7FFF would be 1774.7875.

That's the equation I got. Thank you.

 

[Jake@MHD]

Hey guys. I would be happy to add this fix to the "aftermarket" downpipe flash option. Let's get it tested on some more cars and go from there. As @carabuser stated, there are likely a few other causes to the oscillation. The few I've seen myself have been the temporary ones, like the intentional heavy rich / lean swing back and forth a few times to measure rich to lean response time and vice versa.

I would be interested in hearing more about what this "trim" routine is actually doing. It is likely for OEM catalyst optimization reasons, as you can find information such as this in various studies: "Empirical studies have shown that oscillating the AFR around stoichiometry at an optimized AFR frequency, amplitude, and bias widens the catalyst window, thereby increasing catalyst conversion efficiency"

Going "high flow" downpipe, combined with catalyst & sensor aging / adaptation over time likely exacerbates the "feature" to where the surging can be felt.

 

[studio54]

Thanks @Jake@MHD

On mine, it was bouncing indefinitely. With the fix, beside better looking AFR, the car seems to be smoother at those low loads.

@carabuser sent me some other parameters to log, in order to pinpoint/isolate more specifically what part of the trim control is triggering the behaviour. I will record a log and check with him ASAP.

It's also different toggles depending if it's IJE0S or I8A0S, but seems anyway related to catalyst, or I don't understand why the DME would bounce the AFR, and since Stage 2/2+ are supposed to run without the primaries , it would be great to get rid of this useless oscillation.

Maybe people here that have the oscillation could try the fix and report.

 

[335iN54]

Hey guys. I would be happy to add this fix to the "aftermarket" downpipe flash option. Let's get it tested on some more cars and go from there. As @carabuser stated, there are likely a few other causes to the oscillation. The few I've seen myself have been the temporary ones, like the intentional heavy rich / lean swing back and forth a few times to measure rich to lean response time and vice versa.

I would be interested in hearing more about what this "trim" routine is actually doing. It is likely for OEM catalyst optimization reasons, as you can find information such as this in various studies: "Empirical studies have shown that oscillating the AFR around stoichiometry at an optimized AFR frequency, amplitude, and bias widens the catalyst window, thereby increasing catalyst conversion efficiency"

Going "high flow" downpipe, combined with catalyst & sensor aging / adaptation over time likely exacerbates the "feature" to where the surging can be felt.

I have been noticing time after time people on catless dps reporting this afr behaviour on facebook N54 groups with no one having a proper explanation.
I myself have been chasing it for over a year up until recently changing parts assuming it is a hardware issue after initially I suspected it might have something to do with removing the cats however when I inquired from MHD regrettably they did not have an explanation.
I believe someone reported here that he achieved better emission results and passed the test in UK on catless dps by sorting out this afr oscillation.
Moreover smoother engine idle and possibly marginal fuel consumption reduction etc would be some of the benefits that is known atm.
So yes it may not improve power output and all that most people care about but it would be a good thing if mhd can address this issue particularly considering the due diligence on the emissions aspect.
Cheers