[WhatsADSM]

With the release of MHD we now have the ability to flash our own cars with:
1) Off-the-shelf maps
2) A "pro" tune provided by a known N55 vendor
3) A tune we have created on our own (from the bin and associated xdf).

I'm guessing that some of us out there plan to go down option 3 listed above (i.e. tune it ourselves), or at least do some tweaking ourselves.

The intent of this thread is to have a working area where we can talk about our experiences and share information about MEVD17 tuning in general.
We can use this thread to talk about things like:

• XDF issues/fixes/etc
• Understanding the algorithms the DME uses
• Sharing maps/results

What I would like to avoid:

• Questions revolving how to flash a car with MHD, how to download MHD, what tablet to use, etc. All of that is very well outlined in the existing thread here: http://www.e90post.com/forums/showthread.php?t=1318714
• Generic "How do I tune my car" questions. I certainly appreciate and welcome beginners to get involved; There are many well written generic intros on the subject on the net. I just don't really think we need to rehash that all there.

Quick reference to various software/documentation:

• TunerPro download link: http://www.tunerpro.net/downloadApp.htm
• XDFs (98G0B is for our ECU): https://github.com/dmacpro91/BMW-XDFs
• JB4 back end flashes - 2/23/17 (for reference): https://drive.google.com/drive/folde...UVWLWhkV2NiN2M
• Cobb's ATR guide for the N55: https://drive.google.com/open?id=0B6...E82OEVMTi1SLUU

[WhatsADSM]

I guess I can start. I plan to flash my car in the spring after some basic hardware upgrades, and have started to look into the bin and xdf. In general there seemed to be a lot of tables unlocked thus far which is very promising. However like many cracks unless its really well documented it can be hard to decipher the various tables, and models (many are still titled in German to boot). So I sent Martial a PM and he eventually got back to me on some of my questions. I figured I would post those questions here to start off:

Reguarding the "%" units I see as the axis scalars for many of the tables:

Originally Posted by WhatsADSM

There are quite a few tables in the XDF that list their units simply as "%". They typically seem like they would be load scaled (for example the Timing tables). Is "%" just a default thing in the XDF and no one has filled it in yet?

Originally Posted by MHD Tuning

% = load

Me trying to get a handle on a flow chart of how the load request ultimately gets generated:

Originally Posted by WhatsADSM

I'm guessing the DME starts off its load request with the throttle progression table and then uses that to calculate a load based on the modelled torque limit. It then ultimately translates the torque to a desired airflow and then based on ambient conditions to a desired manifold pressure? Is that (generally) correct?

Originally Posted by MHD Tuning

Yes looks correct

Me trying to find the base WGDC table:

Originally Posted by WhatsADSM

I am stuggling a bit to wrap my head around the various wastegate tables. Where exactly is the primary WGDC base table? Wastegate Position - für Vorsteuerung (if so this thing has a Y scalar from 0 to 1?!).

Originally Posted by MHD Tuning

Base table is Compressor characteristic. It's the power needed in kW to spin the turbos.

[Joey911]

Subscribed

[WhatsADSM]

First off, just a note that I added some more links to the first post. I archived some information in a public area of my google docs. This includes a copy of the BMS back end flashes (reference for fuel and ignition control only), as well as stock bin, for the N55. Also added a copy of the COBB ATR guide for the N55.

Next I had some free time here at home so I took a closer look at the "Compressor characteristic with required compressor / turbine power" (KF_ATL_PVERD) table.

I took that table and cross-referenced it against a picture that COBB has in their manual for the "WGDC (Base)" table. They don't directly match but are clearly the same with different scaling, and I say this for two reasons:
1) The Y axis in the MHD XDF is exactly half that of COBB. Did someone miss a bit somewhere? Someone didn't notice a shift right/left in the assembly? I don't know. In any case the COBB manual does clearly state that it is the "boost setpoint factor", and if that is so, I would *think* MHD got it correct, and the value is likely closely related to commanded absolute pressure.
2) The Z values in the table are definitely different but are related by a factor of 1.5626 (i.e. multiply MHD by this number and that is what the COBB table shows). MHD claims these values are in "kw" (power to spin the turbo), COBB seems to suggest they are a direct duty cycle command. I'm not sure who is correct there, although if they are really in kw, then there needs to be some other table involved to resolve kw to a duty cycle... and Martial@MHD never said anything about it. Maybe COBB is right for the Z?! Who knows.

While the engineer in me would really like this all to make sense in terms of units, scales, etc. ultimately as long the boost setpoint and maf g/s can be logged accurately, and the scaling is correct at the Y-axis and X-axis level I guess I'm not *too* worried as you can always tweak the Z-value up or down and with some trial and error get the compressor mapped out. I will say I do like the idea of a table that is referenced by commanded pressure as well as a air mass... That should really help to nail down the boost curve pretty well.

[JETmn]

Unfortunately I may go down this route too. I really wish the OTS maps were unlocked. I would love to just buy the E30 OTS map and make a few tweaks for my car. I am running a PS1 so I can run a little more boost than a stock turbo car. It is never a bad thing to learn to tune your own car. I used an AEM EMS on my last car.

[houtan]

Subd

[WhatsADSM]

Originally Posted by JETmn

Unfortunately I may go down this route too. I really wish the OTS maps were unlocked. I would love to just buy the E30 OTS map and make a few tweaks for my car. I am running a PS1 so I can run a little more boost than a stock turbo car. It is never a bad thing to learn to tune your own car. I used an AEM EMS on my last car.

Yea, not sure I totally agree with the way MHD is attacking this whole licensing bit. It seems they want to only make the software and then outsource the OTS tunes. They charge for the base software and then separately for the tune (which presumably they get some $$ for the OTS tune and so does the tuner). With that model they have to treat the OTS tune IP as protected... because otherwise if they allowed you to see the tune you could just send a copy to your buddy and he could flash it for free bypassing the middle man.

The issue with the model as-is is that those of us who purchased the OTS tune aren't allowed to then modify it. AND on top of it all there is a conflict of interest. Why should MHD help the community of DIY tuners (although we have purchased their product which clearly states I can DIY tune)? If they help me and I come up with a tune that is roughly equivalent to their OTS offering, then you are back to the point where you just buy MHD and use the community provided OTS tune for free bypassing their OTS offering and costing them money.

If you ask me this is all backwards and I suspect why all tuning packages I have ever worked with instead just make you pay for the platform in its entirety (tune, and all base maps) first. Then you can use it as you please. Going that route there are no worries about someone circumventing the IP, because there is no reason to protect it in the first place. Essentially you just bundle all of the map packs they offer now into the price of the tool. If they outsource the tuning work to a 3rd party, then just pay the 3rd party a flat rate upfront or a small royalty for every sale of the tool (just as they do now). You might say "but that would cost the customer more; everything is bundled". My answer is "not on the bottom line". Most people today have to purchase the tool and then purchase the map pack anyways, since they can't tune their car on their own so the bottom line price is the same. For the few of us that do tune it ourselves, I'm guessing we would have no problem paying a little extra to have a nice base map to start from (hell I purchased the map pack, just because). Not to mention you no longer need to pay the R&D to protect the map IP, and there is more economy of scale as well since everyone is inherently buying all of the maps. Seems like a win-win relative to where we are today... but I will freely admit my background is not in marketing.

[bahn]

I'd be happy to answer any questions but I don't have time to write a guide.

[WhatsADSM]

Originally Posted by bahn

I'd be happy to answer any questions but I don't have time to write a guide.

No need to write a guide this is intended to be a working area thread.

So I have a few questions still around the WGDC (assuming for now the target boost is understood):

1) The "Compressor characteristic with required compressor / turbine power" table. Are the cells really in kW? If so what tables are involved after that to go to a base duty cycle? Wastegate Position - Modell?
2) What do the "ATL - Regler" tables model?

[JETmn]

My last modified car was also a DSM

First thing, it seems that load based tuning is the way to go. Wedge uses that and it seem like Justin is also switching to that.

I also totally agree with your assessment of the buying process for MHD/maps. I guess it saves you a little money if you don't have to buy the OTS maps and only get a protune. I see zero reason the logging isn't included, you can't do anything without logging. It kind of opens up a legal issue for them where if an OTS tune blows up a car that they weren't logging with. You could say you should be logging even with an OTS tune, but if you make the tune available without logging capabilities...

Anyway, that is beside the point, we can't change that. I am still on JB4 for a short while longer, but I will be joining in to the fray soon. Depending on time I may do my own tune or I may just have a protune done and be done with it.

[bahn]

Originally Posted by WhatsADSM

No need to write a guide this is intended to be a working area thread.

So I have a few questions still around the WGDC (assuming for now the target boost is understood):

1) The "Compressor characteristic with required compressor / turbine power" table. Are the cells really in kW? If so what tables are involved after that to go to a base duty cycle? Wastegate Position - Modell?
2) What do the "ATL - Regler" tables model?

The "kW" cell value from the compressor characteristic is converted to WGDC via Wastegate Position model.

Not sure what the ATL - Regler tables are used for. Maybe someone else can chime in on that. MHD Tuning

[WhatsADSM]

Originally Posted by bahn

The "kW" cell value from the compressor characteristic is converted to WGDC via Wastegate Position model.

Not sure what the ATL - Regler tables are used for. Maybe someone else can chime in on that. MHD Tuning

Ok that makes some sense. The wastegate position is one of the few tables that actually does state a little about how it works:
"This table uses the Z value and Y value to deduce the X value. For tuning, the X axis must be modified."

BUT... 2 things:

1) Lets take for face value that the Y-axis is infact air-mass in kg/h (as the XDF states). This scaling is not consistent with g/s in the compressor table. To correct this I figured I would normalize on g/s (more common) which means I simply divide by 3.6.

If it were true that it was in kg/h then that means the largest value in the Y-axis is 269 kg/h or 74.7 g/s... That's VERY low, which means the DME would be essentially constantly operating in the last row of the table... given we are talking about boost here.

I actually started to go into the XDF to change it to g/s and found something interesting. The Y-axis scaling is listed as "X*0.03125/3.6"... That 3.6 sure is suspicious isn't it.

In a nutshell I'm pretty sure the XDF has an error, and the Wastegate Position - Modell Y-axis is in terms of g/s. Which makes much more sense.

I hate to be picky about this stuff but its very important. Incorrect units can lead to expensive stuff not working... just ask NASA and Lockheed

2) The XDF shows the wastegate position model cell (Z) as "%". That can't be load as it wouldn't make any sense ans wouldn't mean you couldn't do as you are saying and translate from kW to duty cycle. Sounds like that should be kW. If it *is* kW this also means that the highest possible duty cycle value to EVER come out of the open-loop wastegate modelling is 45% (that's the greatest X-axis). I actually buy that since that is probably as high as BMW ever wants the open loop to command. Anything more has to be done via a P-I regulator.

However that was just considering the biggest number in the X-Axis. If I instead run an example car through like say a PPK car making 340hp (~270 g/s) in reality if we use the compressor characteristic table alone the highest ultimate duty cycle you could ever see coming off the base table is like 17% duty cycle.

Something doesn't add up there, 17% is too low. There has to be another table being applied in between the compressor characteristic table and the wastegate position model table. "Additional WG due to the spring"? "WGDC Adder"? one of the ATL-Reglers?

[Joey911]

Originally Posted by WhatsADSM

Ok that makes some sense. The wastegate position is one of the few tables that actually does state a little about how it works:
"This table uses the Z value and Y value to deduce the X value. For tuning, the X axis must be modified."

BUT... 2 things:

1) Lets take for face value that the Y-axis is infact air-mass in kg/h (as the XDF states). This scaling is not consistent with g/s in the compressor table. To correct this I figured I would normalize on g/s (more common) which means I simply divide by 3.6.

If it were true that it was in kg/h then that means the largest value in the Y-axis is 269 kg/h or 74.7 g/s... That's VERY low, which means the DME would be essentially constantly operating in the last row of the table... given we are talking about boost here.

I actually started to go into the XDF to change it to g/s and found something interesting. The Y-axis scaling is listed as "X*0.03125/3.6"... That 3.6 sure is suspicious isn't it.

In a nutshell I'm pretty sure the XDF has an error, and the Wastegate Position - Modell Y-axis is in terms of g/s. Which makes much more sense.

I hate to be picky about this stuff but its very important. Incorrect units can lead to expensive stuff not working... just ask NASA and Lockheed

2) The XDF shows the wastegate position model cell (Z) as "%". That can't be load as it wouldn't make any sense ans wouldn't mean you couldn't do as you are saying and translate from kW to duty cycle. Sounds like that should be kW. If it *is* kW this also means that the highest possible duty cycle value to EVER come out of the open-loop wastegate modelling is 45% (that's the greatest X-axis). I actually buy that since that is probably as high as BMW ever wants the open loop to command. Anything more has to be done via a P-I regulator.

However that was just considering the biggest number in the X-Axis. If I instead run an example car through like say a PPK car making 340hp (~270 g/s) in reality if we use the compressor characteristic table alone the highest ultimate duty cycle you could ever see coming off the base table is like 17% duty cycle.

Something doesn't add up there, 17% is too low. There has to be another table being applied in between the compressor characteristic table and the wastegate position model table. "Additional WG due to the spring"? "WGDC Adder"? one of the ATL-Reglers?

The xdf file is poorly documented and errors here and there. Not sure if they're trying to hold back because it is not fully developed yet, or just want to limit what diy tuners can do.

[bahn]

Originally Posted by WhatsADSM

Ok that makes some sense. The wastegate position is one of the few tables that actually does state a little about how it works:
"This table uses the Z value and Y value to deduce the X value. For tuning, the X axis must be modified."

BUT... 2 things:

1) Lets take for face value that the Y-axis is infact air-mass in kg/h (as the XDF states). This scaling is not consistent with g/s in the compressor table. To correct this I figured I would normalize on g/s (more common) which means I simply divide by 3.6.

If it were true that it was in kg/h then that means the largest value in the Y-axis is 269 kg/h or 74.7 g/s... That's VERY low, which means the DME would be essentially constantly operating in the last row of the table... given we are talking about boost here.

I actually started to go into the XDF to change it to g/s and found something interesting. The Y-axis scaling is listed as "X*0.03125/3.6"... That 3.6 sure is suspicious isn't it.

In a nutshell I'm pretty sure the XDF has an error, and the Wastegate Position - Modell Y-axis is in terms of g/s. Which makes much more sense.

I hate to be picky about this stuff but its very important. Incorrect units can lead to expensive stuff not working... just ask NASA and Lockheed

2) The XDF shows the wastegate position model cell (Z) as "%". That can't be load as it wouldn't make any sense ans wouldn't mean you couldn't do as you are saying and translate from kW to duty cycle. Sounds like that should be kW. If it *is* kW this also means that the highest possible duty cycle value to EVER come out of the open-loop wastegate modelling is 45% (that's the greatest X-axis). I actually buy that since that is probably as high as BMW ever wants the open loop to command. Anything more has to be done via a P-I regulator.

However that was just considering the biggest number in the X-Axis. If I instead run an example car through like say a PPK car making 340hp (~270 g/s) in reality if we use the compressor characteristic table alone the highest ultimate duty cycle you could ever see coming off the base table is like 17% duty cycle.

Something doesn't add up there, 17% is too low. There has to be another table being applied in between the compressor characteristic table and the wastegate position model table. "Additional WG due to the spring"? "WGDC Adder"? one of the ATL-Reglers?

As Joey said there's errors all over the XDF. The Y axis is g/s. Also you'll notice that the boost setpoint factor in the WGDC (spool) table is scaled incorrectly (X/16384). As it's currently scaled it would almost never be used. The correct conversion appears to be X/8192 (same as the compressor characteristic table). When using the commanded WGDC system you'll notice "boost setpoint commanded" logging parameter is not scaled to match the boost setpoint factor in the commanded wgdc table. The logged parameter needs to be multiplied by 2 to match the command wgdc table.

Logging parameter WGDC Base % is actually the cell value from the compressor characteristic table but it looks like the MAF g/s used is actually the MAF req. WGDC g/s logging parameter HOWEVER it appears the logged parameter WGDC Base % is scaled like Cobb. If you change the compressor table to multiply the cell value by 1.5626 you'll then be able to line up MAF req. WGDC g/s & Boost setpoint get the correct WGDC Base "%" from the compressor table.

[JETmn]

Originally Posted by bahn

As Joey said there's errors all over the XDF. The Y axis is g/s. Also you'll notice that the boost setpoint factor in the WGDC (spool) table is scaled incorrectly (X/16384). As it's currently scaled it would almost never be used. The correct conversion appears to be X/8192 (same as the compressor characteristic table). When using the commanded WGDC system you'll notice "boost setpoint commanded" logging parameter is not scaled to match the boost setpoint factor in the commanded wgdc table. The logged parameter needs to be multiplied by 2 to match the command wgdc table.

Logging parameter WGDC Base % is actually the cell value from the compressor characteristic table but it looks like the MAF g/s used is actually the MAF req. WGDC g/s logging parameter HOWEVER it appears the logged parameter WGDC Base % is scaled like Cobb. If you change the compressor table to multiply the cell value by 1.5626 you'll then be able to line up MAF req. WGDC g/s & Boost setpoint get the correct WGDC Base "%" from the compressor table.

Awesome post Bahn! That will save a lot of headaches for the rest of us.

[WhatsADSM]

Originally Posted by bahn

As Joey said there's errors all over the XDF. The Y axis is g/s. Also you'll notice that the boost setpoint factor in the WGDC (spool) table is scaled incorrectly (X/16384). As it's currently scaled it would almost never be used. The correct conversion appears to be X/8192 (same as the compressor characteristic table). When using the commanded WGDC system you'll notice "boost setpoint commanded" logging parameter is not scaled to match the boost setpoint factor in the commanded wgdc table. The logged parameter needs to be multiplied by 2 to match the command wgdc table.

Logging parameter WGDC Base % is actually the cell value from the compressor characteristic table but it looks like the MAF g/s used is actually the MAF req. WGDC g/s logging parameter HOWEVER it appears the logged parameter WGDC Base % is scaled like Cobb. If you change the compressor table to multiply the cell value by 1.5626 you'll then be able to line up MAF req. WGDC g/s & Boost setpoint get the correct WGDC Base "%" from the compressor table.

Thank you so much for all the info! That little stuff would have taken me a while to figure out.

I'm going to ask MHD if I can make fixes to the XDF and commit/merge them back to his GitHub. There is no real excuse for errors in the XDF certainly if we know the fixes for them.

[houtan]

I don't fully understand what you guys are talking about, but thanks for posting and working on the xdfs. Please let post what MHD says when you bring the errors to his attention.

[bahn]

Originally Posted by WhatsADSM

Thank you so much for all the info! That little stuff would have taken me a while to figure out.

I'm going to ask MHD if I can make fixes to the XDF and commit/merge them back to his GitHub. There is no real excuse for errors in the XDF certainly if we know the fixes for them.

From my understanding it is Justin not Martial who is creating the XDF's.

[JETmn]

Originally Posted by bahn

From my understanding it is Justin not Martial who is creating the XDF's.

If Justin is creating them, then it is a serious conflict of interest. The more he releases to us, the more people that won't buy his OTS maps. I sure hope Martial is in charge of them as he will be less biased, but still somewhat biased as he has to be getting a cut of map sales too.

[bahn]

Originally Posted by JETmn

If Justin is creating them, then it is a serious conflict of interest. The more he releases to us, the more people that won't buy his OTS maps. I sure hope Martial is in charge of them as he will be less biased, but still somewhat biased as he has to be getting a cut of map sales too.

That's just what I heard from a reliable source. Hopefully MHD Tuning can confirm or deny.

I also have some possibly unfounded doubts about the Wastegate Position model table being an inverse lookup for the Z of the compressor characteristics map (at least directly). The conversion factors are not the same, so I don't know how you can accurately compare the two.

[houtan]

I say email both of them.

[bbnks2]

Originally Posted by JETmn

If Justin is creating them, then it is a serious conflict of interest. The more he releases to us, the more people that won't buy his OTS maps. I sure hope Martial is in charge of them as he will be less biased, but still somewhat biased as he has to be getting a cut of map sales too.

Conflict of interest? There is an awkward mentality in this thread which is skewing its intent...

MHD/Justin are under no obligation to publicly release anything. You are paying Martial $200 for his efforts to bring OBD flashing to your POCKET (via an app). The license is a fair price for unlimited flashing. That has nothing to do with mapping out the DME. Martial gives you BMW's .bin files to do with as you please!

You are then paying Justin $50 for a generic re-map (if you choose that route). His time and effort has gone into generating these maps. He has intellectual property to protect, which is why they SHOULD and ARE locked to prevent abuse. You are already getting your money worth 10x over with what is being provided with the $50 V25 OTS maps! Go ahead and compare the value to COBB, JB4, or Dinan...

Just about every map gets locked by the tuner (with a few exceptions - COBB OTS). Cobb Vin locked their flash device, so allowing their OTS tunes to be edited wasn't an issue. You had to pay COBB $700 to buy their AP to flash your car with (proprietary cobb file type), which protected their revenue stream from competitors flashing their files. Look at Dinan too. I can guarantee they have more bytes of the DME mapped than the public N55 XDF does (and probably a deeper understanding of it). Why aren't people fighting them to release it publicly? Why aren't people fighting them to unlock their maps so you can copy their tables? They'd laugh you out the door...

Luckily for us, the COLLABORATIVE work of various people to define tables is being shared PUBLICLY. Anyone can contribute to the XDF and help advance the platform, as is being done above and as has already been done by people previously (look at the change log on GitHub)! Justin has no obligation to educate people on how to custom tune their cars or on how to interpret his work.

If Justin intentionally put some eggs into the public XDF to keep himself ahead of the "game" than that is a serious ethical issue. However, I don't want to believe that is the case. Especially without something to support it!

I would imagine Justin probably knows himself what each table does when he tweaks the numbers a certain way, just like COBB probably knew with their tables (looking back, I'd gladly take my COBB pro-tune back). How the tables are scaled, or how they are labeled, are probably a non issue for Justin... I do find it interesting that people are finding so many errors in the details though. It's kind of ironic after seeing MHD boast about how COBB is the one who had things scaled incorrectly...

FYI, have you guys compared a base .bin to a ppk .bin? The public XDF hasn't even mapped out HALF of the bytes of changes BMW made from stock to ppk. I am guessing there is a lot more to learn and expand upon, which will surely happen over time if people put effort into it!