Miller Gen 3 MAF analysis
Collapse
X
-
There are indeed many fuel/ignition maps. It seems many of these are used based on what "variant coding" is set in the file i.e. leaded/unleaded, regular/super etc etc. Interestingly enough, the files provided by MIller are all based on an automatic car...
Anyway, never been one to trust any xdfs on the net, hence creating my own definition files.
I've got most stuff defined in WinOLS now and slowly porting over the useful stuff to romraider.
Leave a comment:
-
Well put. Hence why I messed with reverse engineering M1.7 for a few years, and decided to go with a Link E36X lol (not that I finished the conversion yet, but it'll happen someday!).Leave a comment:
-
yeah, internet XDFs for the E30 were basically all based on guesses/hearsay, and made by well meaning people who just did what they had to do in order to get by. There's definitely going to be missing maps; there's no way you're getting them perfect without a matching disassembly. Even on more modern, popular cars - say, the N54/335i - the public XDFs out there are just a fraction of what's actually inside the DME, and there are still errors.
The biggest obstacle is there's basically no documentation - I think the "damos" file for early Motronic was basically printed on paper sheets. Most of these were either lost or are rotting in an old file cabinet somewhere - I've only ever seen screenshots of them, I've never actually found any scanned, certainly not for the M20 (I might have seen a partial PDF for Motronic 1.0 somewhere). There's no way, even with a disassembly - you're going to be able to figure out all of the maps without it. It took me 3 years to do it with MSV70, and I had all of the parameters defined in the Damos/A2L. All I had to do was figure out what the offsets were, remap that, and label everything (and by "all", I mean it was still a huge effort).
Contrast that with newer cars, where documentation is plenty - I have basically every A2L for every BMW made since the E90, and most of them since the E46. Most of them don't even need to be remapped because there's a definition for every software version. It's just too bad I don't give a damn about any of them, lol.Leave a comment:
-
The XDFs for old Motronics on the internet are, largely, full of errors. I cannot recall what descriptor 3A is specifically, but there is effectively no single "injector constant" in these. While there are some constants that do sort of function as flow rate scalers, they do not work under all operating conditions, and the only way to correct for injector flow rate changes is to re-scale all of the fuel maps (of which there are several dozen, multiple copies, some copies used under some conditions, etc).
Tuning the base fuel correction maps and ignition timing maps is reasonably straightforward, although I am not sure how accurate internet XDFs are. In a complete XDF, there are dozens and dozens of filter constants, switch-over constants and stuff like that, on top of the fuel & ignition maps (not to mention several other types). I am no expert at this, and am certainly not a tuner, but I worked with a professional tuner for multiple years reverse engineering the hardware (since that is closer to my professional background) so I at least have a good grasp of the hardware. From what I learned, the internet XDFs are not only incorrect in many ways, but they are missing about 80% of the relevant tuning parameters. It's cool to see people still working on these still, and a number of people have successfully modded the executable code as well as maps.Leave a comment:
-
yep you're right! dunno how i got that screwed up when transposing.
Since you have done a fair bit on this, i do have a question. All the tunerpro xdfs have on the internet have labelled 3x1 2D tables with the axis header "3A" as injector constants. Im not sure thats what it really is.
To me, it makes no sense that it would be a 3x1 table, and even less sense that there would be 2 instances of it.
In the 318i file im working on, these are the decimal values from the file:
To me, this looks more like something that is either in use, or not in use ("3A table 2") depending on one or more of the variant flags in the file. Any advice based on your findings historically?Leave a comment:
-
I interacted a lot with Sssquid in somewhat of an engineering capacity when reverse engineering Motronic 1.7. Jay leaves no stone unturned, and I know that he was aware of the challenges posed by converting an AFM to a MAF without an ECU remap, so he likely put the proper work into addressing those challenges.
@ba114,
In your M40 AFM TF plot, you seem to have reversed the order of the K1 constant array. It should be a nice smooth exponential curve (all Bosch AFM TF's are).
M42 for example:
AFMTF = K1 * (2^K2) * K3
with K1 & K2 being 8 element arrays, values indexed by FLOOR(ADC_COUNTS / 32), and K3 being 32 elements indexed by MOD(ADC_COUNTS, 32)
Last edited by bmwman91; 01-21-2022, 07:43 PM.Leave a comment:
-
Am currently using SSSquid Tuning's MCK. According to their site, their maf kit is the only true conversion kit on the market.Leave a comment:
-
There are many tables in the ecu that reference iat and clt. Many of these would relate to cold start enrichment, ignition modifiers etc.
I believe the table above is the only table that effects the airflow calculations based on IAT. It would be no issue setting this table all to 1.
If I can figure out loading this in IDA and starting to trace the functions I could confirm that.Leave a comment:
-
-
I worked on MAF conversions for several years, along with some very in-depth Motronic reverse engineering. My car is running on a MAF, and has been for a bout a decade now. There is more to it than simply playing with the transfer function and zeroing the IAT tables. I cannot recall the specifics, but I believe that IAT is used to retard ignition timing in cases where the incoming air is above a certain temperature in order to prevent detonation, and that alone is sufficient reason to me to not nullify the IAT tables.
The other big challenge, and it is less of a problem on am 6 cylinder than a 4 cylinder, is the fast response time of the MAF vs the AFM. The step response time of the AFM is on the order of 50ms IIRC, where as the MAF is on the order of 1ms. I have plenty of data logs showing that you can clearly resolve every single intake valve opening when the throttle is open more than ~50%...when doing a WOT pull, the MAF output looks sort of like a sine-sweep / chirp as you go up the RPM range. The AFM is slow and heavily damped, which serves as a low-pass filter for all of this, and the Motronic's analog sampling rates are fairly slow (maybe 100Hz). This causes issues with a MAF since the signal ends up getting measured at random times during an intake pulse, by a system that expects any given sample to be an "average" of the incoming air flow. In practice, the car will run OK, but I found that it was hard to tune for consistent AFRs due to this.
The other thing is the AFM's mechanical resonance. I cannot speak for the M20, but on the M42 the AFM's flap door resonates at high throttle openings in the 2400-3400 RPM range, effectively over-reporting the air flow. If you look at the high-PT and WOT maps, you will see that the fuel values are leaned-out, specifically to account for that known effect. There is another smaller resonance up around 5500RPM IIRC. When you connect a MAF, it reports actual air flow all the time, so those leaned-out map sections cause VERY lean running. On the M42, it basically led to fuel-cut at WOT around 3000RPM.
So...what to do? In my case, I built an external conversion box that takes in the AMF signal and a thermistor (same transfer function as the stock one). It both converts the mass-proportional signal to a volume-proportional signal, and performs some hefty digital filtering to low-pass / average the MAF output swings. Step response is ~15ms, which is still better than the AFM, and the Motronic has no problem reading it. However, I still ended up needing to remap the fuel tables to deal with the non-existent sensor resonances.
If you want to run a MAF directly to the ECU, you would probably need to change fuel tables, rewrite parts of the code that do the density conversion but still keep the IAT inputs for any ignition-related compensations, and have the MAF ADC sampling performed at specific crank angles to ensure that you are reading at a consistent part if the intake stroke (there were several discussions in the MS3 forums about this years ago and I think that crank-aligned sampling was the ultimate solution since trying to run a moving average on the signal was way too much to do in a high speed interrupt routine).Leave a comment:
-
ok, Nando, that'll get you on a few lists, I suspect!
t
not Christmas lists, I don't think.Leave a comment:
-
I've used IDA a lot in the past, but I kind of want to try this:I agree with all said, if I get this figured out I'll release my calibration changes, part numbers etc to do the swap.
Ideally I'd actually like to learn to fully disassemble the code and write a maf function to replace the AFM logic completely. I've freed up a significant amount of space in the code by removing several unused fuel and timing tables so there is plenty of space to fit a standard 256 byte maf transfer.
says it supports the 8051Leave a comment:
-
Nice work OP! Always amazes me that there is still more to learn about E30s, and it's stuff like this that keeps me coming back to r3v.Leave a comment:

Leave a comment: