Support for a flex fuel sensor and automatic timing/boost advance & fuel scalar changes based on the flex fuel sensor

Boost targeting with curve learning - no more overshoots/undershoots

Boost control of a single turbo/twin turbos with external wastegates

Are these realistic or should I just keep my procede and stack it with the Cobb if I want these features? Would strongly strongly strongly prefer to remain Cobb-only.

Thanks!

Just my personal opinion on your list. Cobb could come in here and refute everything i'm about to say, but this is how i see it.

(1) Almost certainly not going to happen. That would require external hardware for the Flexfuel sensor to integrate with the DME and then recoding the DME to reference additional sensor output when targeting timing.
(2) Cobb has stated they have no interest in rewriting the DME for boost targeting. IMHO load targeting is a better(if not easier) means of tuning anyway.
(3) Definitely a possibility. IIRC Cobb has actually been working on flipping the DME WG control logic. I have no idea how much progress they've made though.

__________________

"I'm not surprised you get along well with all the other neighbours. If you put fifty children with Down's syndrome in a room there is going to be a lot of hugging." David Thorne

Just my personal opinion on your list. Cobb could come in here and refute everything i'm about to say, but this is how i see it.

(1) Almost certainly not going to happen. That would require external hardware for the Flexfuel sensor to integrate with the DME and then recoding the DME to reference additional sensor output when targeting timing.
(2) Cobb has stated they have no interest in rewriting the DME for boost targeting. IMHO load targeting is a better(if not easier) means of tuning anyway.
(3) Definitely a possibility. IIRC Cobb has actually been working on flipping the DME WG control logic. I have no idea how much progress they've made though.

Doesn't seem like the flex fuel sensor would be that hard, aside from having to add an input to the DME. I agree its probably not going to happen, just asking

I guess my only issue with the load targeting is that the car doesn't seem to make load targets aside from 3500-4500rpm... is that just because of the tiny stock turbos/turbines? Would a Cobb tuned car with large turbos make load targets all the way to redline? If so, then yes I agree with you.

Like I have pointed out to them, there's nothing wrong with load targeting if you can actually use it without getting weird behaviors due to exceeding boost targets in the code that we have no control over.

Doesn't seem like the flex fuel sensor would be that hard, aside from having to add an input to the DME. I agree its probably not going to happen, just asking

I guess my only issue with the load targeting is that the car doesn't seem to make load targets aside from 3500-4500rpm... is that just because of the tiny stock turbos/turbines? Would a Cobb tuned car with large turbos make load targets all the way to redline? If so, then yes I agree with you.

Ohh yeah, definitely nothing wrong with asking. Products only advance when their markets push them to do it.

When you are below load targets how does your requested boost vs boost mean abs look? If you are below boost target then you can a little WGDC into the base table and get actual closer to target. However, like Carl morris just kind of alluded to, i think part of the tuning strategy Cobb uses is to keep load a little under target so as to prevent weird side effects some people are seeing.

__________________

"I'm not surprised you get along well with all the other neighbours. If you put fifty children with Down's syndrome in a room there is going to be a lot of hugging." David Thorne

Ohh yeah, definitely nothing wrong with asking. Products only advance when their markets push them to do it.

When you are below load targets how does your requested boost vs boost mean abs look? If you are below boost target then you can a little WGDC into the base table and get actual closer to target. However, like Carl morris just kind of alluded to, i think part of the tuning strategy Cobb uses is to keep load a little under target so as to prevent weird side effects some people are seeing.

The boost mean abs drops below req boost somewhat. I know I could go and pull out or add wdgc (same way to fix overshoots which I have done) but why doesn't it learn? Those tables should be auto-adjusting to a certain extent. I had a Profec on my Eclipse GSX in 1997 that could boost target perfectly. :P Why do we have to fiddle with it based on logs to get it to work in 2013?

The boost mean abs drops below req boost somewhat. I know I could go and pull out or add wdgc (same way to fix overshoots which I have done) but why doesn't it learn? Those tables should be auto-adjusting to a certain extent. I had a Profec on my Eclipse GSX in 1997 that could boost target perfectly. :P Why do we have to fiddle with it based on logs to get it to work in 2013?

The main thing is the Profec is targeting boost, while the DME does not. The other problem is more of a slight confusion in the naming of some of the tables. We really should have called them Load/Boost Ceilings, not Load/Boost Targets. The DME tries to get close to the load and boost requests, but its normally never going to hit them exactly.

Carl's main issues have to do with very high altitude and I've recently found some new things relating to that. At this point, its on the list. While I am concerned with offering these tables as they will almost certainly overspin the turbos, I'll get them added... I just don't have a date right now.

To your other questions:

(1)The FlexFuel sensor is a bit more than just adding an input to the DME. Its possible that this could come at some point, but if we simply feed the signal to the DME, we would need to do massive changes to pretty much every piece of logic. The code simply doesn't exist in stock form from BMW, which means it would need to be written.

(2)Changing the strategy of the DME to be boost targeting would again be a huge undertaking and would require extensive testing. I see this as being unlikely, but I won't completely rule it out.

(3)External WGs are still on the horizon, but with the new options that have been surfacing lately, we should be able to do some testing on this front soon.

I always have a long list of tasks, but don't worry guys, I'll get to them all.

The main thing is the Profec is targeting boost, while the DME does not. The other problem is more of a slight confusion in the naming of some of the tables. We really should have called them Load/Boost Ceilings, not Load/Boost Targets. The DME tries to get close to the load and boost requests, but its normally never going to hit them exactly.

Carl's main issues have to do with very high altitude and I've recently found some new things relating to that. At this point, its on the list. While I am concerned with offering these tables as they will almost certainly overspin the turbos, I'll get them added... I just don't have a date right now.

To your other questions:

(1)The FlexFuel sensor is a bit more than just adding an input to the DME. Its possible that this could come at some point, but if we simply feed the signal to the DME, we would need to do massive changes to pretty much every piece of logic. The code simply doesn't exist in stock form from BMW, which means it would need to be written.

(2)Changing the strategy of the DME to be boost targeting would again be a huge undertaking and would require extensive testing. I see this as being unlikely, but I won't completely rule it out.

(3)External WGs are still on the horizon, but with the new options that have been surfacing lately, we should be able to do some testing on this front soon.

I always have a long list of tasks, but don't worry guys, I'll get to them all.

-Josh

Awesome Josh, thank you. Luckily for me, I also value them in the order you seem to be doing them... the external wastegates etc being #1 priority to run (for example) Vargas Stg 3 turbos or a single turbo kit in the future.

#2 would be a nice-to-have but not a deal-breaker, and #1 kinda the same. If modified fuel hardware comes out allowing us to just run 100% E85, that'd be fine too.

Awesome Josh, thank you. Luckily for me, I also value them in the order you seem to be doing them... the external wastegates etc being #1 priority to run (for example) Vargas Stg 3 turbos or a single turbo kit in the future.

#2 would be a nice-to-have but not a deal-breaker, and #1 kinda the same. If modified fuel hardware comes out allowing us to just run 100% E85, that'd be fine too.

Thanks for replying

No problem. I don't always post, but I usually troll the forums when I get home from work lol. Thank you for the requests as well. We love adding features whenever possible (its much more fun than trying to understand what some German engineer was thinking while he wrote code for your DME).

Ohh yeah, definitely nothing wrong with asking. Products only advance when their markets push them to do it.

When you are below load targets how does your requested boost vs boost mean abs look? If you are below boost target then you can a little WGDC into the base table and get actual closer to target. However, like Carl morris just kind of alluded to, i think part of the tuning strategy Cobb uses is to keep load a little under target so as to prevent weird side effects some people are seeing.

The boost mean abs drops below req boost somewhat. I know I could go and pull out or add wdgc (same way to fix overshoots which I have done) but why doesn't it learn? Those tables should be auto-adjusting to a certain extent. I had a Profec on my Eclipse GSX in 1997 that could boost target perfectly. :P Why do we have to fiddle with it based on logs to get it to work in 2013?

I honestly believe the PID logic does "learn" to a degree. I have a protune map that was on stock turbos. After getting the turbos replaced under warranty, I get massive throttle closures due to exceeding the 1.28 bar limit. After a few weeks of driving, the boost control will be much better. PID tables are P - present error, I - accumulation of past errors, and D - the prediction of future errors, it has the ability to correct itself over time, just not immediately. Back in my stage 2+ days, those maps oscillated like crazy when I first flashed them, but after a few weeks it was hardly noticeable.

I honestly believe the PID logic does "learn" to a degree. I have a protune map that was on stock turbos. After getting the turbos replaced under warranty, I get massive throttle closures due to exceeding the 1.28 bar limit. After a few weeks of driving, the boost control will be much better. PID tables are P - present error, I - accumulation of past errors, and D - the prediction of future errors, it has the ability to correct itself over time, just not immediately. Back in my stage 2+ days, those maps oscillated like crazy when I first flashed them, but after a few weeks it was hardly noticeable.

This.
I believe the PID tables are there as a means of allowing the DME to take elevation, weather, component wear etc... into account. However, it takes so long for the DME to finally settle down that it's kind of hard to know what it can or can't account for. I just try to get the base tables as close as I can and hope that the PID tables will take care of it when conditions change.

I've been waiting for the weather to clear so I can try out some things with the PID tables but it's just not happening. Either it's raining/snowing or it's so cold(and bald tires) that I break sideways when trying to grab a 3rd gear log.

__________________

"I'm not surprised you get along well with all the other neighbours. If you put fifty children with Down's syndrome in a room there is going to be a lot of hugging." David Thorne

This.
I believe the PID tables are there as a means of allowing the DME to take elevation, weather, component wear etc... into account. However, it takes so long for the DME to finally settle down that it's kind of hard to know what it can or can't account for. I just try to get the base tables as close as I can and hope that the PID tables will take care of it when conditions change.

I've been waiting for the weather to clear so I can try out some things with the PID tables but it's just not happening. Either it's raining/snowing or it's so cold(and bald tires) that I break sideways when trying to grab a 3rd gear log.

Guys PID is a just very basic type of closed loop (feedback) control algorithm. It can be implemented either analog or digital. In this case digital for controlling the WG. It stands for Proportional Integral Derivative, the last two being in the calculus sense. So if you have a system and it is measuring current error E of some commanded position, and that error signal is being fed back to a controller to produce a correction then the output of a PID is completely determined by the three parameters (p,i,d) of the PID controller:

correction = p*E + i*I(E) +d*D(E)

Here I(E) is the integral of the error signal history and D(E) is the derivative. In a digital controller I(E) is just a sum of some past series of E's and D is the difference. In an analog PID these are tuned with various resistors, capacitors, & inductors.

This is one of the most basic and sometimes very effective controllers out there, the parameters completely determine its behavior. The learning you may be sensing is coming from somewhere else. The Cobb ATR is letting you set p, i, d. There are consequences to each, I suggest you pick up a book on control theory and see what they are. As you crank up the gain on these things they can seem to perform better but if there are unmodelled dynamics in the system (there are) you can get some unpleasant side effects or wear out mechanical components.

Anyway I am sure there are adaptations and learning going on in the system but not as a result of the PID itself. Perhaps the rest of the ECU is adapting to the new PID settings, who knows.

Carl's main issues have to do with very high altitude and I've recently found some new things relating to that. At this point, its on the list. While I am concerned with offering these tables as they will almost certainly overspin the turbos, I'll get them added... I just don't have a date right now.

Great...glad to hear it's on the list. Now if I can just get a 2-step rev limiter/launch control on "the list" I'll be one happy Cobb customer :-).

But anyway, overspinning issues aside, won't this additional control also be useful for people trying to get rid of flatlined timing due to exceeding the boost target?

Great...glad to hear it's on the list. Now if I can just get a 2-step rev limiter/launch control on "the list" I'll be one happy Cobb customer :-).

But anyway, overspinning issues aside, won't this additional control also be useful for people trying to get rid of flatlined timing due to exceeding the boost target?

I don't think this will have much to do with any timing issues as they relate directly to altitude, but it is possible. We'll know more after we do more testing. I'll let you know if I need your help with altitude testing since I know you have consistent high elevation 'quirks'

I don't think this will have much to do with any timing issues as they relate directly to altitude, but it is possible. We'll know more after we do more testing. I'll let you know if I need your help with altitude testing since I know you have consistent high elevation 'quirks'

OK. Speaking of table labels and such, I went back and forth with Henry via email last summer on some issues with some of the tables. I never felt like he really understood what I was saying on some of the axis labeling issues and I eventually gave up. At some point if you're interested in taking a look I'll send you the same information...

OK. Speaking of table labels and such, I went back and forth with Henry via email last summer on some issues with some of the tables. I never felt like he really understood what I was saying on some of the axis labeling issues and I eventually gave up. At some point if you're interested in taking a look I'll send you the same information...

Feel free to shoot me an email, but I believe he asked me about those questions you sent. Specifically, some of the axis points not looking correct? If that's what we're talking about, then just be aware that we read in axis values as they're populated in the DME. These values can be modified in ATR/ATP, but you have to be careful as some axis are shared with tables (some of those tables may not be defined) and you could cause issues with something you're not trying to modify.

Feel free to shoot me an email, but I believe he asked me about those questions you sent. Specifically, some of the axis points not looking correct? If that's what we're talking about, then just be aware that we read in axis values as they're populated in the DME. These values can be modified in ATR/ATP, but you have to be careful as some axis are shared with tables (some of those tables may not be defined) and you could cause issues with something you're not trying to modify.

Wait so if, for example, I change the rpm points on the load target table (I changed them to even 500 rpm increments) then that can affect other hidden tables, and I shouldn't do that? Is that what you're referring to?

I don't think this will have much to do with any timing issues as they relate directly to altitude, but it is possible. We'll know more after we do more testing. I'll let you know if I need your help with altitude testing since I know you have consistent high elevation 'quirks'

I live right at 8000 ft and do most of my driving say 7k up to 12000 ft, let me know if you need something tested. Running Stage 1+ right now, have some downpipes I need to install as soon as the snow melts a little and will run stage 2+ at that time. 335xi AT