M3.3.1 413/506 DME XDFs 'M3.3.1 Missing Book of Misinformation'

[nomecone]

With 2025 being roughly 30yrs since the end of OBD1 I think it's about time to get all the community information together.

Maybe giving the old code a kick will catch the eye of old tuners that may now be willing to share more secrets, or correct some errors still propagating in the XDFs.

This will not be a tuning guide. This is documentation and trying to understand the Motronic 3.3.1 code and data.

Work in Progress
1. Cleaning up and continuing development of the 413/623 Google sheet that is based off of Hairyscreech excel file. This sheet is linked below and anybody can add comments to help out. Currently only I can edit the sheet. I am using cell "notes" to label data. I am using cell comments for discussion and to make links to jump to locations.

Out of scope until after 2025 is getting into the code disassembly. I'm an ME not a CS so that is going to be rough for me.

Putting the project files here:
XDFs:
https://github.com/NomecOne/BMW-DME-M3.3.1

Google Sheet to define ROMs and other info (this has some copy paste from Hairyscreech and others):
https://docs.google.com/spreadsheets/d/ ... sp=sharing
you can view and add comments to cells to help define the 413 ROM and other items

Fun fact #1 there was a portable BMW tool called a MoDic that could plug into the diagnostic port of a M3.3.1 car and program an update to the eprom if it was small enough to fit into some yet unknown reserved space on the eprom. Additionally if a blank chip was put into the DME the MoDic could, through the diagnostic port, program the whole eprom. -source BMW TIS documents.... I guess everything to program a chip is onboard then. That would be quite the trick if somebody figured out now how to program/burn eproms using the DME itself like the MoDic could.

[kickingklutch]

thank you for the work your willing to put into this man i myself have recently gotten into tuning my obd1 325i and the mess of information is stressful if you need any help in anything feel free to let me know my knowledge is currently slim but you never know

[nomecone]

I'm back. I'm took a big pause. Had a career change. Blew up all my vintage race bikes at the national championships after ripping holeshots and leading. Big highs and big lows. I didn't feel like doing anything after not finishing any of the my vintage motorcycle classes for the second year in a row...after winning 2 years in a row prior. Poor me.

I found my bootstraps now and I'm giving them a yank because it either continue this or sell my e36.

Fun theory #1 if you keep you old DME/chip/rom from your ews enabled car you could just extract that ews data from the original file and put it into your new tune file basemap. Then EWS would still just work no alignment needed bc you already did it by bringing in the data...although failing hardware and other gremlins probably mean delete is still a better option. Anyway it could be a feature to transfer the data in, delete, or doing nothing. Turner pro + instructions could make this happen I believe.

[nomecone]

Fun fact #2 the checksum location can be moved. There is a table of locations that defines the checksum region.

[nomecone]

Fun theory #2 injector size affect on injector constant if you are changing it

Not a complete list but a summary of roughly what the values are.

4 Ways of looking at the same information:

pn..........;descrip......;#/hr..;Inj.C.;Hex..;Factor
280150415;95 m3.......;17.16;43478;A9D6;1.000
280150440;Pink 96m3..;21.50;34702;878D;0.798
280150927;-.............;23.50;31748;7C04;0.730
280156370;alpb3s pink.;23.80;31348;7A74;0.721
280150947;Blue.........;25.50;29258;724A;0.673
280155715;Light Blue..;25.60;29144;71D7;0.670
280150218;-.............;31.32;23821;5D0D;0.548
280150934;-.............;31.32;23821;5D0D;0.548
280150945;red..........;32.10;23242;5ACA;0.535
280150431;-.............;35.64;20934;51C5;0.481
-............;Dark Blue...;39.77;18760;4947;0.431
280158227;-.............;41.43;18008;4658;0.414
280150558;green top..;45.20;16506;407A;0.380
280158123;12ohmev14;62.86;11869;2E5C;0.273
280158040;-.............;90.48;8246;2035;0.190

[nomecone]

thank you for the work your willing to put into this man i myself have recently gotten into tuning my obd1 325i and the mess of information is stressful if you need any help in anything feel free to let me know my knowledge is currently slim but you never know

Thanks had PM'd me about a value the 413 xdf and where it is at in the 506
"BMW OBD1 Bosch M3.3.1 HW413 xdf from you on github vss limiter is there as 0xD27E in the hex is it something i can look for in 506?"
Yes it is there, shifted slightly. This is the engine RPM limit when no VSS is present. Is is not used unless your VSS is broken in some way.

413 d27e rpm limit when no vss signal.PNG (37.39 KiB) Viewed 18664 times

[nomecone]

How should fueling correction table data be viewed? What is the most correct?

Main fuel tables are RPM v. Tl(Time Injection Basic)(ms). The data in the table is correction factor at that point. Over the years of following this topic most people,I think, and most public XDFs for sure do one of the following with the table data:
1. leave it as a raw decimal value with 128 being zero correction ; conversion = x
2. converted to lamba / This is also becomes what could be viewed as a multiplication factor after converted ; conversion = x/128
3. Converted to afr ; conversion = (1-(x/128-1))*14.7 (or similar, I can't recall the eq used)

#1 is reasonable to just leave it and not worry about it. More is more fuel, less is less fuel
#2 lamba NO but, multiplication factor yes. Depends on how the program uses the data in the table.
#3 Just NOOO its not AFR

Have seen Olafu post that 64 = 0.5x fueling and 255 = 2x fueling which leads to believe it is multiplication factor.

Also the old Jim C quotes posted all over are OG source.

Tl = Q / (n * Ki)

With Tl quantified, we now take into account the vagarities
of the particular engine family and operating conditions by
introducing multiplicative factors to correct the theoretical
injector time to the ACTUAL time for injection (Ti) needed
at that instant. Finally an ADDITIVE factor (Tv) is added to
compensate for the differing injector opening time under lower
than nominal voltages.

Ti = (Tl * [C,D,E...]) + Tv
JimC

data as factor of correction.PNG (32.88 KiB) Viewed 18528 times

So I think the best/most accurate way that all the correction maps should be viewed is with data conversion factor as (x/128). Does this seem to be the best way to format all the map data as we continue to drive to a point to complete the equation Ti = (Tl * [C,D,E...]) + Tv

[nomecone]

Micro progress on side questions. The ba114 romraider 413/506 definition file has a few things in it that have not been discussed I think. I will warn the 506 rom there is a wacky one that is the same as what miller performance cars based there warchip rom on.

On the topic of a collaborative spreadsheet being available on Google sheets, I am getting closer. The programming dream team of chatgpt and me have made scripts to help convert all the notes/comments/data validation messages that hairyscreech did into notes on a Google sheet. Without the scripts it was either lose the info or copy paste one by one.

I have collect a few more ROMs some stock, some NA performance, and some FI big injector.

On the 413 XDF I have been going back over it and updating wording and descriptions with the latest info. Changing the conversion factors on some items to align with know and some assumed equations the data goes into. I am having second thoughts on doing the XDF creation all in the GUI. It's a bit clunky in some regards trying to implement "advanced" features for me. Maybe it's a skill issue on my part.

[nomecone]

Added Google sheet to OP that anyone can comment in cells to help define the 413/623 ROM

[nomecone]

I have added some ROM reads that I personally have taken to the github. I have more to put there but I have to label and organize them.
I have an oddball 744 software version of the 413 ROM. I have not crossed the 177 or 609 software versions in the wild yet.

initial rom upload.PNG (53.05 KiB) Viewed 18082 times

Also some screenys of the google sheet to define the 413/623 ROM. A lot left to clean up and a lot of undefined values left to uncover and document.

sheet example1.PNG (98.38 KiB) Viewed 18082 times

sheet ex2.PNG (132.79 KiB) Viewed 18082 times

I'll keep chugging alone solo for now. Seems I am the unlucky one as nobody else has the time and interest right now. I missed out on the 2016-2019 progress. Wish I would have been active then.

[Baltica]

I am glad to see progress in your work. I have 177 and 609 soft on my computer at home, but I am currently on a business trip, I will be able to send it in 2-3 months

[nomecone]

I am glad to see progress in your work. I have 177 and 609 soft on my computer at home, but I am currently on a business trip, I will be able to send it in 2-3 months

I will appreciate these files. I have a few 609s for the internet but unsure if original 100%(have not compared files yet). I do not think I have 177 at all.
Did you read/dump them yourself?

[Baltica]

177 soft was sent to me by my friend, I'm sure it's the original. He told me that 177 was used for the 525i police. I've never used it, only looked through it. 609 soft several files, some from the Internet, some were also sent by a friend. I used 609 soft, vanos advanced at higher RPM and more cranking fuel, the engine starts and immediately the RPM is high, especially cold, maybe I forgot something else. What strange moment in 506 soft did you write about? And what did you find interesting in 744 soft

[nomecone]

The ba114 account on GitHub that made a romraider profile(a pretty good one too). The 506 file he posted in his GitHub is not original in my opinion. It's an exact match for the file that miller performance cars used for their war chip. They moved the cranking fuel map and checksum and some other stuff is messed with. Millers encrypted files and the ba114 posting are the only places on the net I know of that specific file existing. So there is some connection there. I thank them for their work. I submit an 'issue' to them on GitHub to warn about the 506 file.

I have not found anything interesting in the 744 software other than it exists(I have not really look at it though). I never have seen anybody mention it then, I got a dme to read and it was 744.

I have ROM overload this plus all the online files found. Got a stock 506/623 chip last week for $5.50 USD...I probably have a problem.

[Baltica]

I used to have chaos in my head and on my computer. There were files signed correctly and incorrectly. I sorted bins by checksum address, adding #7D32 to the name, for example. After that it became clear. I have many bins for different ecu.

You have a good collection! Chip for $5) In my country they sell them for $50

Have you had experience setting up m50b30/32?

[nomecone]

Not really. Alpina chip read is the only exotic/different read that is OEM I have. I have all these mod chips but cannot share those.

It was the eprom only for $5.50. DME complete is $75-250.

[nomecone]

I used to have chaos in my head and on my computer. There were files signed correctly and incorrectly. I sorted bins by checksum address, adding #7D32 to the name, for example. After that it became clear. I have many bins for different ecu.

You have a good collection! Chip for $5) In my country they sell them for $50

Have you had experience setting up m50b30/32?

I agree complete file checksum is good idea. I'll get a bit more advanced checksum for each file I post and have it listed. I started labeling them with VIN number after I found out how to decide it... I am probably a bit too proud of it and have been wielding it like a sword. I'll do a little thinking on naming convention.

I have been playing with chatgpt helping me make a file parsing tool. I only dabble in powershell, excel/VBA, and now the Google app scripts for Google sheets. If I get some features ported over from my powershell script into Google sheets I think that would be best.

I wish I had a test bench to run a DME and perform test. I don't have the time to develop one.

[nomecone]

Worked a bit on MAF selection sheet and the database of MAF calibration data sheet. More to come. Thanks to ba114 and the MS41 community for a lot of info. Some data if from other sources, some I have personally verified in multiple ROMs, and some from MAF companies.

I have focused in on there most common MAFs and the "best" MAFs.
I have reread a lot of old thread on 540/Euro, 803, and 809 MAFs. With the knowledge I now have from going through a lot of ROMs it's cleared up a lot of confusion.

First 540/Euro MAF the volt vs airflow data stored in the ROM from a 540 and a Euro M3 are exactly the same data. I have read the ROMs myself and checked the data. It's provided in the Google sheet linked in first post. Second this MAF is only viable if you get it cheap and you are doing NA only. This MAF only adds 50-80kg/hr of head room total. The errors start well before the kg/h listed at 5V. The max threshold error limit in the ROM has to be adjusted to do a MAF calibration for a higher flowing MAF. With that known, you can change the threshold while retaining the stock MAF and get almost the same max airflow as the 540/Euro MAF. Unless the bigger diameter actually comes into play affecting the power output there is not much reason to go to a 540/Euro. The 540/Euro also does not have enough flow capacity for boost application. For the cost cutter budget people you could do resister mods to pull down the voltage and make a customized calibration, and accept the cons of losing the low end tunability. There is a sheet with a tool to help with the(lifted from ba114).

You can also see the 803 MAF does not have a lot of headroom for boost. The car it was on was only in the mid 200s... I only have ba114 calibration data on the 803 MAF. I have a few ROM dumps that should have the data but I cannot find it...unless the ROMs I have are not right. This MAF has just a little move head room than 540/Euro MAF. 803 would need resister mod to run much boost.

809 MAF finally enough room to run boost but if you want big HP it's still not a got enough airflow range. The data in the sheet is pulled straight from a Porsche 993TT ROM that I did myself to confirm data posted by others. I'll post the ROM and the XDF(that only has the MAF data defined).

So that leaves you with what I think is the best options if you want to change MAFs. HPX or VMP MAFs that come with calibration data that can be adjusted for the intake tube size you want to run/what HP capacity desired. There maybe some other MAF brands that are viable, please mention them and I can add to the spreadsheet(and later to calibration setup information).

I do a little professional work with newer frequency based output Bosch MAFs and have a little better understanding but, there is a lot to learn for specific applications.

maf select.PNG (144.25 KiB) Viewed 17797 times

maf cals.PNG (106.1 KiB) Viewed 17797 times

[nomecone]

The Bosch book about the M-Motronic system that all that enter should read
https://e28goodies.com/wp-content/uploa ... uction.pdf

Two flow charts that set the foundation. The BMW software is customized off of the base system so remember your grains of salt.

Fun here is that the way Bosch words it the LOAD signal in the output of the MAF. MAF signal is Load in the Motronic system as stated by Bosch. The history of 413 tuning like many other communities has call the "basic injection time" the LOAD. It can be seen as a processed and converted load indicator(given your injector size and fuel settings). This one reason that I believe so many are confused from the start.

So maybe a better description of the main fueling table axis(and all that are indicating a load level) would be:

RPM vs. "Basic Injection Time Calculated from MAF Load signal with Injector Size Constant and Fuel target AFR Accounted For'

That is a mouth full though.... SOOOOO...."LOAD"

inj time flow chart.PNG (26.84 KiB) Viewed 17572 times

ign time flow chart.PNG (28.96 KiB) Viewed 17572 times

[nomecone]

Put my hardware kit in a box. The universal programmer XGecu T48 is a good option. With Moates back in business the burn2 is a nice small and very easy to use product cost a bit more than a T48 but the software of the t48 has a lot going on that could be confusing...and just seems a bit sketchy.

The Moates ostrich is the real win for this sort of work to having Moates back.

Screenshot_20250412-201454.png (248.39 KiB) Viewed 17516 times

[Baltica]

Hi bro, very interesting, at first glance it is difficult to understand about maf. I read the forum from the phone. Is it possible to calibrate a 30 year old oem maf 413? taking into account the tuning camshafts.
There is a strange behavior in my ECU: when the lambda mode is on, I start the warmed up engine, it needs to idle for some time. The mixture slowly becomes very lean, reaches 19:1, my device does not show more. This continues. Once I open the throttle, and everything is fine, the mixture is 14:6. I turned off the lambda mode, and this problem is gone. I also reduced the values ​​​​in the global fuel enrichment table in cold mode (warm up correction).

[nomecone]

You would not want to tune MAF calibration data to tune a car.

The only times to tune a MAF calibration curve data is when the data is unknown and you are creating the data, slight adjustment offsets of whole curve for aftermarket MAF in custom housings to dial them in, when modifying a MAF with a resistor mod to read higher flows(losing some reading on the low end), and if transplanting the sensor into a different size housing.

Yea that a lot of cases to tune a MAF calibration...but, do not tune the MAF for a stock MAF or known MAF calibration. That is my opinion.

I recommend making a post about your problem over on bimmerforums. I would like to keep this thread focused on developing the ROM knowledge. I'll try to dig up olafu quote on when closed loop is active and try to make a flow chart of what compensations are active in idle condition.

That said... to not just say f off on outa here. Typically a modified car is tuned with lambda off/sensor unplugged. Get the tune close to 1 lambda, then switch on the sensor/plug it in and it helps to smooth out the car not make it worse. That said, there maybe something wrong with your sensor or wiring and the ECU is getting bad data and making it think you needs less fuel. Include info about your car when/if you post on BF, like, are you running chip for cams?

[dex]

The universal programmer XGecu T48 is probably the best option now that Moates is gone.

Moates are back, www.moates.net

[nomecone]

The universal programmer XGecu T48 is probably the best option now that Moates is gone.

Moates are back, www.moates.net

OOOOOOh. NICE! I have pretty much all of it already. The Moates website is supper slow to load and sometimes getting cloudflare failed to load issue. Maybe website is having issue.

The Burn2 is super easy to use for the specific use case. The T48 has more capability and is lower cost.

I have always questioned the CobraRTP products and been grateful that I had no need to buy them since I have the Moates Ostrich 2.0 already. Seems CobraRTP is out of stock of everything anyway.

[nomecone]

I can't help but look at MAF data. I am a LARGE MAF ENTHUSIAST.

This is a table based on the MAF data I have for the HP estimate that you would hit the error limit of the MAF...when you set the max flow to the 4.75V flow. You could push higher into the voltage range but you have to leave some up there I think for noise overhead and the like. The stock settings limit for the M50tu I believe is 750kg/hr or ~ 4.25v limit. So the biggest gain for the stock/540/euro MAFs comes from editing the limits in the DME not actual hardware(ignoring potential efficiency increases from the larger diameter MAF)

mafsmax4.75.PNG (8.34 KiB) Viewed 17336 times

This assumes no resistor mod. It is known that when the 803/809 MAFs were popular that resistor mods were used to change the measured flow range.
The 803/809 MAFs are $$$$ now and not worth it for turbo application, Plus the hassle of developing a your own resistor mod + custom MAF calibration to suite. The 540/Euro and m62 are good candidates for high output, high rpm NA builds.

The HPX and VMP5K are now the obvious choices for turbo builds given the cost and data given. Each can adapt to your HP goals with a housing size + calibration change. Calibration data tool are provided by the manufactures. You can further down-select to the VMP5k 3"(tube) if you want to run 3" charge pipe and be north of ~575HP, from these estimates anyway. The HPX would need a little larger tube to measure up there or, take a look at the HPX-E version. HPX-E will be a lot closer to the VMP5K with a 3" tube, Calculating for what size charge pipe would be the most efficient in your operating range is probably a good idea before you spend spend spend.

[nomecone]

Started adding a few of the other cars OEM bins that are the source of MAF data to the GitHub link in first post. There are posts with converted data around to compare to. If you go about checking it all yourself befor using you will notice that is a bit of conversion error is brought in. A few kg/h difference can occur depending on how you do it. I recommend checking and making sure you agree with the data before using

Screenshot_20250416-223035.png (64.19 KiB) Viewed 17214 times

[nomecone]

Have been adding several items in my WIP version of the 413/623 xdf. I have a lot of touch up work to do yet but I am running out of new sources of information without a ton of real car test time, a SIM bench + the time, or diving into the program disassembly time sinks.

I started to wonder how much of the calibration data the community has defined over the years. Excluding the program portion, just the calibration data.

~67% has been defined. I did given some 0.5 scores on areas that are only sort of known. Sure there are some mistakes in there. I am working through table by table cleaning up and doing sanity check on them.

how much we know result.PNG (3.9 KiB) Viewed 17107 times

how much do we know.PNG (58.73 KiB) Viewed 17107 times

Adding more info to the XDF where I can. I am bending the proper use of the XDF a little trying to make it a one stop shop for information.

info example.PNG (31.87 KiB) Viewed 17107 times

[nomecone]

I have been trying to resolve the injector constant into its parts. It much be made up of a value representing the injector size, unit conversion factors, number of cylinders, stoichiometric ratio(possible the value stored in the ROM is used), and revolutions per cycle. Google gives results with many attempts that do not work out...so far. I'll come back to this later. Driving into MADNESS:

calc madness.PNG (72.18 KiB) Viewed 16689 times

I have also been comparing may files and have noting settings that are being changed when the injector constant is changed. will have to make a second pass on this and note the ones that are scaled by the injector constant changes and items that are changes in a different way.

unknown settings possibly injector scale related.PNG (83.13 KiB) Viewed 16689 times

I see that are at least some people viewing the thread. Probably the best I can hope for considering the age of the system now and how most of the threads other places of days past descend into a gate keeping dumpsterfire.

I have started to take issue with some of the information that Jim Conforti put on forums. I believe what he said is true IF you assume a specific context. As far as I have read he never states that context.

Example:

Rescaling only the injector constant will get you very little.

You have to understand the basics of this ecu.

Specifically, that when you rescale the Ki you also have to rescale EVERY calculation
that uses LOAD (Tee sub Ell or Tl)

This means complete disassembly.

Jim

I think this is misleading. He eludes to having to rescale all the calculations which would be in the program....Well empirical study so far shows me that only 1 byte on the program is changed with injector scale. Maybe Jim meant the load axis' in the calibration data. This is also not always edited with injector scaling. Sometimes you do not want/need to scale the load axis down because you are going to flow enough air to still use the whole load scale. If you pick an appropriate size injector for how much air you are flowing you will always want to use the whole load scale. The time when you need to rescale the axis is when you put in an injector too big for your application and your injector is only using ~ half the map table because you never flow enough air to get to the higher load side of the table.

Here is another

lndshrk 09-19-2008 03:38 AM
Can I make a suggestion?

learn to disassemble.

Either that or wait for my Shark Edit tool to be released.

I'm the guy who INVENTED the method to properly rescale injectors
for the M3.3.1 ecu, over 10 years ago.

EVERYTHING is LOAD-BASED in M3.3.1

You change Ki, you change load everywhere in the ECU.

Jim

Still waiting on the OBD1 shark edit software....My spreadsheet with scripts is more likely to be useful to community tuning than shark edit at this point. I believe Jim is glorifying the ability to change the calibration data here again. The "change Ki, change load everywhere..." is again only for the specific case of oversize injectors in setups that will never reach the high load side of the tables unless you rescale the axis to smaller values... In which case you are maybe wasting money on injector you do not need. This method that Jim claims as his invention is a method to run injectors that are too large for your car by rescaling everything to get resolution back/use the whole table. That part of it is kinda silly. OKAY credit where credit is due there are a bunch of values stored in the constants section before the table data that do need to be scaled with the injector constant. Those still do need adjustments.

And another

lndshrk 09-26-2008 12:27 AM
Chris,

What happened? Try hackers bragging about "hacking" the program before it was
released - so I added more security. Then having a son born 14 SEP 08.

Trust that it is worth the wait.

As to rescaling load maps you have to rescale them ALL.

Let's give a simple example.

Say you go from 100cc to 200 cc injectors (2x)

Your load values should be then cut in half for ALL references to load.

By ALL I mean:

Map Indices

Map DATA that is used to compare to Tee Sub Ell (Tl)

Data Points that are used as compares to Tl

There are 33 "data objects" that need to be rescaled in the 506 version.

(Now later, if you wish to expand the Tl axes of the Fuel and Ignition tables, you are
fully welcome, but first we get the part load right!)

The only way to find all of these is to DISASSEMBLE the code, and track down every
single reference for the load variables in the code. Or to use a tool written by someone
who has.

Many of these are used as control for emissions, and where closed loop operates.

If you did not rescale them, you would be in closed loop mode twice as "high" on
the load scale - essentially trying to seek Lambda = 1 under partial boost.

In many cases you then get to see what piston metal looks like in the exhaust.



Even a d*mos file won't help you, as some of the changes are made in the actual
CODE, versus the CAL DATA space.

Jim

Has not been worth the wait. This is a fantastic example. double the injector half the on time which in this case is used as an indirect load value. Jim mentions expanding the Tl axes later.... Well if you plan to the use the whole 200cc's of the injector do not scale the axes by half in the first place, only scale table data and constants. Again do not install larger injector unless you need them. AKA you are hitting Tl values larger than the main table provide.

The stating of 33 data objects to change in 506 (I have seen Jim do this a few times way back then stating there are xx item to change in xxx software) reads a bit like bragging to me. About 30 years and an actual list of the these 33 items, locations, definitions does not publicly exist(nether does OBD1 sharkedit, though I believe a few people did get sharedit back then). If the items to adjust with injector scale were all publicly known I would have a Nomecone/ChatGPT script for changing injector size with one input in a few hours(a competent coder would have it in minutes). But, You know, NO HANDOUTS.

The Damos comment. Well, I think an official German paper DAMOS file on 3.3.1 would be useful and help. "should try reading books instead of burning them" ... Empirical data is showing only one byte so far in the program that is injector scaled. I wonder if Jim is overstating "SOME" while meaning one.

If you do read through all the threads 413/506 related on the net be mindful what information to accept as true, half true, and complete BS. I can give you my guarantee I am making mistakes here. When 2026 gets here I hope I'm ready to start a publicly documented disassembly myself.

The Google Sheets Document is getting ahead of My XDF Development. The 413/623 ROM definition sheet is getting close to being as defined as it can be from public information and data comparison. Only new public information/testing/SIM/Disassembly can move it forward soon.

If you have a nugget of information consider bringing that into the public knowledge base here.

[nomecone]

My posts are a bit rhetorical at this point. But I'm still trying to figure things out on how I want to display them in the XDF. Currently, all the tables that I have labeled use the hex offset of the data, not the beginning of the axis information. The index of tables in the ROM data uses the beginning of the axis information to mark the locations of tables. Labeling with the start of the data as the offset makes sense in the context of how tuner pro works. Currently, the label matches the start point listed in the parameter within tuner pro.

In the context of the ROM itself, it would make more sense that I would label it in the same fashion that the index of tables already has labeled the start of table data. You might say it doesn't really matter. But in the background I'm also working on scripts that are reading in hex data and then outputting information about the file you already in. I need to decide/have one method of organization and calling all these items across multiple scripts and programs. It's already chaos enough.

[nomecone]

Per my other thread about TP handling of cell equations I have found that 256 is used in a bunch of equations and it most likely should have been 255.... great.

I crossed this...
https://www.tunerpro.net/examples

Note here the use of 255

motronic axis tp.PNG (43.17 KiB) Viewed 16340 times

Then in the example files linked on the page 256 is used

motronic axis tp 2.PNG (37.47 KiB) Viewed 16340 times

255 seems to be correct to me. Max value is FF = 255
(256-255)*40 = 40 this does not seem right. Should be zero.
(255-255)*40 = 0 this seems right to me

Looks like most if not all motronic xdfs copy pasted from the example file and now have 256 in every occurrence of the equation. Not my favorite type of fix to make. WHOOPY. Maybe time to cross the line and hand edit the XDF in Notepad++

I do not really want to be a perfectionist. I know I am still making mistakes. My plans however are to finish 413/623 then apply that info to all the BMW motronic 3.x versions. I do not want to keep propagating errors. I have been having good luck with writing scripts to parse the ROMs. End goal is something that can output an XDF based on the ROM or a file based on the ROM that Tuner Pro can import. I would also like my scripts to be useful if you want to use ROMRAIDER or other apps I have yet to explore, generally make as much of the BMW M3.x info available to everyone as I can. Right now I am 413/623 and TunerPro focused.

*update* still hard to say what is right. Rpms look "cleaner" when its '256-' and I do not get any issue with conversions. '255-' makes some axis start at zero which make conversion calcs based on RPM ugly. mult or divide by zero. So what is 40RPM difference among friends?

[nomecone]

I played with making a patch in TP to see what it was like. Bit of a hassle but can be made. I used the MAF calibration as my test subject. First thing I found out was the patch appears to be limited to 256 bytes. MAF cal is 512 so it take multiple entries.

I am using the 540(800)/EuroM3(806) MAF cal data for the patch. I made the cal change then I moved to checking the new MAF high fault limit in the 800/806 ROMs. Turns out that although the cal data is an exact match the MAF high limit is set to a different value. This makes sense. I went with the 806 high limit setting for this test patch. I patched, I un-patched, and used to compare ROM/BIN to make sure it was doing what I wanted the patch to.

I think this was the sort of thing that was the wet dream of the BF tuning threads 15-20yrs ago... "Somebody could make an xdf and just make patches so we could easily swap common parts instead of buying a $$$ chip tune every time a part is changed" ... Well, that never happened publicly until now - 15-20yrs too late to be cool.

Before the patch

Prepatch-resized.jpg (243.2 KiB) Viewed 16114 times

Patch applied

postpatch-resized.jpg (247.06 KiB) Viewed 16114 times

Patch Setup

mafpatchsetup-resized.jpg (248.41 KiB) Viewed 16114 times

Some other generic patches should work fine. (Idle RPM for light flywheel, RPM limits, Speed limits, etc)
I would like to collect the data needed for coil swaps to have patch data for those.
I would like to better understand the TPS so other TPS/throttle bodies could be calibrated and patched in.
The injector constant change....the TunerPro patching mechanism is unlikely to be suitable for this...but I will look into it anyway.

[nomecone]

Updated vin2hex sheet to a sane conversion. The other worked but was using a wild method that I found. Understanding the binary conversion is much better.

vin2hex.PNG (83.85 KiB) Viewed 15708 times

[nomecone]

File believed to be the Alpina B3 3L ROM dump is now on the project GitHub.