Maf options?

[coffeeandcigars]

Well, I see that it is a very not-stock M42 lol. I would have said that I don't think that an M42 can be maxing out an M52 MAF, but the US never got the 2.0L variant (only the bigger ones), so I suppose that it is indeed possible if you are making >150bhp.

The M52B20 has the smaller MAF (max. 518 kg/h) compared to the bigger displacements B25/B28 (max. 725 kg/h).
It was a surprise to see it maxed out, i was guessing the M42 is max. around 150-160hp. When my M52B20 was stock it took around 436 kg/h on this exact MAF while also running good and achieving its topspeed.
The M42 i have is just bored over to 84,5mm.
The only mods that would really affect the M42s airflow numbers is the headwork and the ITB intake. To my knowlegde the cams i have are stock.

Since you are using a very different intake manifold, perhaps it is enough of a change to eliminate / change the AFM resonance behavior. Do you have access to a wide-band O2 sensor? It would be good to log the AFR when you are at WOT. Do you feel like the car sort of loses power at WOT in the 2500-3500 RPM range? Are you on a stock tune?

I have a WBO2 on my other car but i ordered the stuff to make another harness for the E30 as the harness is a b**** to switch over...
WBO2 could also tell if the measured Airflow from AFM/MAF is realistic....lets hope it isnt just pig-rich
Below 4000 it generally feels a bit lacking.
It currently has a Chip made for a stock engine from a guy that has a decent track record in the EU. I think it mainly put some more ignition advance in it.

I would be interested to know about the intake that it looks like you are developing...I see 3d printed stuff in there, so fun things must be happening!

indeed, very fun heres a video about the 3D-Printed stuff: https://www.youtube.com/watch?v=OdWPkFzQtQg&t=3s
From what ive read your stroker uses a stock intake? I bet that beast would love ITBs ;)
Are you on the stock ECU+MAF converter?

EDIT: From looking at the comments in the Youtube vid, it sounds like the first plot you showed in the thread was with a stock M42 intake manifold, and the more recent ones are with your prototype? If that is the case, then yeah I would think that the change in AFM resonance is a result of that. Also, as far as the MAF, I found that having a trumpet / velocity stack in front of it helped a fair amount with the output oscillations. You seem to have that taken care of. Can you remove the MAF and put up some pics of the inside so that I can see what the sensor element looks like sitting inside of the overall MAF housing? The fact that the sensor output is as stable as it is makes me think that BMW went with a design that inherently damps the signal.

All the logs i did so far were with the ITBs. If/when i put the stock intake back on i will for shure do more logs cause i want to see the what the ITBs actually changed.
Dont have pictures handy right now.
I will report when i find out more (WBO2 etc.) and have taken some picture of the MAF =)

[coffeeandcigars]

I found my ghosts today it held for so long until i stopped checking


And here a couple pics of the MAF. Looking at it from the engine side:





Plus a couple ghostless WOT logs from around 2000

[bmwman91]

lol yeah, I imagine that would cause some strange readings...

It looks like the resonance that I have observed in the 2500-3500RPM range is very possibly due to some interaction of the stock intake with the AFM. There looks to be no sign of it in your data.

[coffeeandcigars]

Regarding the pulsation of individual cylinders you saw with your MAF at WOT: today i read that the Siemens MAFs that are used in the M52 Engines have a pulsation free output. =)

[bmwman91]

Cool. That probably offloaded a fair amount of processing from the ECU (and back in the M52 era it was still somewhat limited). No ECU would have had sufficient spare cycles to read it with a high sample rate and digitally filter the signal. Megasquirt 3 (MS3) adopted a strategy of reading the MAF at specific crank angles only, and MS3 is a lot more powerful than the old Siemens MS40 ECUs. I would imagine that the MAF is internally providing the low-pass filtering directly. The disadvantage of that is a small increase in output delay, but it would still be faster than an AFM by a good amount.

coffeeandcigars what is the max sample rate you can run with your ADC? I would be super interested to see the MAF data from a WOT pull, sampled at 2500Hz (intake pulse frequency is 240Hz at 7200RPM, and you generally want 10X oversampling when trying to inspect the true shape of a waveform). If you are just dumping ADC values out from the Arduino into a terminal as ASCII formatted text, it might be asking a lot lol. I think you could just write 8 bit ADC values directly to the serial output and use some Python to convert the raw values (taken in as far ASCII chars) to readable text values. The high sped (10kHz per channel) logger I build more or less did that with the dsPIC MCU and an interface written in VB.net.

EDIT: I would also be interested to see the documentation for the Siemens MAF...got a link?

[coffeeandcigars]

Cool. That probably offloaded a fair amount of processing from the ECU (and back in the M52 era it was still somewhat limited). No ECU would have had sufficient spare cycles to read it with a high sample rate and digitally filter the signal. Megasquirt 3 (MS3) adopted a strategy of reading the MAF at specific crank angles only, and MS3 is a lot more powerful than the old Siemens MS40 ECUs. I would imagine that the MAF is internally providing the low-pass filtering directly. The disadvantage of that is a small increase in output delay, but it would still be faster than an AFM by a good amount.

yes, perfect for my case

coffeeandcigars what is the max sample rate you can run with your ADC? I would be super interested to see the MAF data from a WOT pull, sampled at 2500Hz (intake pulse frequency is 240Hz at 7200RPM, and you generally want 10X oversampling when trying to inspect the true shape of a waveform). If you are just dumping ADC values out from the Arduino into a terminal as ASCII formatted text, it might be asking a lot lol. I think you could just write 8 bit ADC values directly to the serial output and use some Python to convert the raw values (taken in as far ASCII chars) to readable text values. The high sped (10kHz per channel) logger I build more or less did that with the dsPIC MCU and an interface written in VB.net.

I think it can go pretty fast if its just one analog value we are after. My logger is mainly limited to around 20 Hz because of the RPM and Wheel-RPM inputs. I have those working via interrupts and if the time between running my main loop gets too short it wont catch at least one correct period of Rising edge. This solution is not ideal...
I will try just pushing the 8 bit raw value to Serial monitor and putting that into an Excel for conversion to Volt/Airflow!

EDIT: I would also be interested to see the documentation for the Siemens MAF...got a link?

its from this guys website (german). He mentions it in his description of his MAF-conversion, no datasheet unfortunately.

http://kolliman.de/e30m3/luftmassenmesser/luftmassenmesser.html

https://www.youtube.com/watch?v=4086pqBcjxA&list=WL&index=1

Are you able to tune the ECU of M42/M44s, i read through your topic of reverse engineering these ECUs but that stopped after a lot of info (that i cant comprehend ).
Did you get to a working XDF for tunerpro and to burn your own chips?

[bmwman91]

Yeah, mixing analog measurements with frequency measurements can be tricky. I generally took the approach of making a very lightweight ISR for the rising edge input for RPM which just logged the period since the last edge into a chosen global variable, and then back in the main loop had a function that just computed the RPM based on whatever value was currently stored in the variable which was updated by the ISR. There was other logic to detect timeouts and stuff too. But overall it allowed me to run high sample rates for the analog stuff, and while that strategy meant that there were 'duplicate' RPM values, it either was not a big deal, or I was able to deal with it in post-processing with some smoothing functions.

I am not super great at M42 tuning, and the real work was done by Sssquid Tuning back when I was collaborating with them on M1.7 reverse engineering. There are no complete / correct M1.7 XDFs publicly available unfortunately. The information I got from them was strictly confidential since it was work that they did themselves. The M44 (which uses Motronic 5.2) is completely different and as far as I have seen there is zero tuning support for it...which is unfortunate, because I think that it would be amazing to use M5.2 as an upgrade for the M42.

Thanks for the MAF info!

[coffeeandcigars]

...which is unfortunate, because I think that it would be amazing to use M5.2 as an upgrade for the M42.

100% i would love to add knock control and a MAF to the M42 with one of those. I think they are more like the MS41 where you can flash them (Thats what i am more familiar with, M52 stuff)

The xdf for M1.7 i found on tunerpros website is trash imho...and needs a warning added its unfortunate that the good stuff isnt public but i can understand it. It takes a lot of knowledge and work to create one!

Thinking about the endgoal i am unshure if i should just go the route of a plug and play KDFI (some sort of megasquirt) for 500€ now.
I ll definitely try and simulate the AFM via MAF for fun but in the end theres a lot more that i would want to adjust:
->The alpha n map for a M42 TB+intake (dual sequential blades) i am shure isnt similar enough to my single blades+new design in Airflow. So when AFM/MAF/my converter craps out and the ECU has to revert to Alpha N (i guess it has this capability) its gonna run shit or doesnt run at all and leave me stranded.
->I will propably have very limited tuneability regarding fuel, even more so if i am actually maxing the AFM/MAF and am already running on the edge of the map.
->I will have 0 ability to control spark.

[bmwman91]

Yeah, a more modern aftermarket ECU solves basically all of the issues. I have a Link E36X and a half-done wire harness sitting around. The car now runs really well on and I don't want to go tearing it apart for a little while longer lol. But, knock control, traction control, fully modeled fuel injection, wide-band feedback and flat-shifting are all things that I look forward to! The Link ECU is a little more costly than Megasquirt, but the fact that it uses the same 88 pin connector which can work with the OEM harness is a big plus. Well...it physically plugs in...lots of stuff needs to be re-pinned. Still, if terminals on the harness side got moved around properly, the E36X would otherwise be plug-and-play for the M42.

[coffeeandcigars]

coffeeandcigars what is the max sample rate you can run with your ADC? I would be super interested to see the MAF data from a WOT pull, sampled at 2500Hz (intake pulse frequency is 240Hz at 7200RPM, and you generally want 10X oversampling when trying to inspect the true shape of a waveform). If you are just dumping ADC values out from the Arduino into a terminal as ASCII formatted text, it might be asking a lot lol. I think you could just write 8 bit ADC values directly to the serial output and use some Python to convert the raw values (taken in as far ASCII chars) to readable text values. The high sped (10kHz per channel) logger I build more or less did that with the dsPIC MCU and an interface written in VB.net.

did a test today, it was around 1 kHz (it didnt let me upload the xlsx ):
theres something going on it seems, but its strange that AFM and MAF are both so similar in showing those "oscillations", would have guessed they react very different to actual varying airspeed...
blue=MAF; red=AFM
WOT Pull starting somewhere from around 1500/2000 to just after 7000

[bmwman91]

There will be EMI and electrical noise, although there is a lot less than I'd expect for an unfiltered reading (or did you put an RC filter back in place?). The fact that both signals show the same pattern, and that it looks like a regular pattern rather than completely random, is pretty interesting. Depending on the topology of the ADC in the microcontroller, there can be issues with 'ghosting' between channels, usually when there is a single sampling capacitor multiplexed with multiple inputs. A signal with high input impedance (such as one with even a few kOhm resistor inline as part of an RC filter) usually makes this worse. Residual voltage from one channel can bleed into the next channel's reading if there is not sufficient time between samples since the capacitor needs to charge/discharge to the level of the next signal input. I assume that the Arduino code you have runs a main loop at 1kHz, with the AFM signal being sampled and then immediately followed by the MAF signal, and then some 'dead time' until the end of the main loop? How is the grounding set up between the Arduino and car/signals?

The larger oscillations from the MAF signal make sense since they are present what looks like the lower RPMs at the start of the WOT pull. Low pass filtering is always a trade between group delay (how much it delays the output from matching the input) and both filter cutoff sharpness and how low the passband frequency is. So, on a 4 banger going WOT at 2000RPM, the filter isn't fully attenuating the ~67Hz oscillations.

You can see one of the characteristic downsides of the AFM in this plot...at the start when you snapped the throttle open, you can see that the output swung high as the momentum of the door carried it past where it should have been, then it rebounded, and then settled into proper reading. The MAF has none of that, although these old ECUs do not always love the oscillation in the MAF signal.

Anyway, it is really cool that you were able to bump the sampling up to 1kHz. You can get a much better idea of what the signal actually looks like.

[bmwman91]

Hey so somehow I missed the cool video you posted detailing the 3d printed intake development and stuff. Great work there! Let me know how the PA-CF and PA-GF stuff holds up. In theory it should have a sufficient heat deflection temperature that it won't creep at ~80°C. I'm impressed that you got it printing nicely in an unenclosed printer! Those parts came out looking great.

[coffeeandcigars]

Regards the 1kHz log: It was MAF and AFM without any filtering directly to the Analog-Pins. As you guessed its just 2x AnalogRead and then directly Serial.print.
Most of your post is over my head
What i didnt expect was that the MAF hit in a pretty wide range at first until it settled to a more narrow spread. The AFM (minus the overshoot ) was faster to a stable reading/narrow spread.

Hey so somehow I missed the cool video you posted detailing the 3d printed intake development and stuff. Great work there! Let me know how the PA-CF and PA-GF stuff holds up. In theory it should have a sufficient heat deflection temperature that it won't creep at ~80°C. I'm impressed that you got it printing nicely in an unenclosed printer! Those parts came out looking great.

Yeah that thing is the # 1 motivation behind playing with the electronics
So far V3 is really solid. I drove the setup for around 100 miles now and it has like 10-12 full heat cycles.
When doing the Proof of Concept V1, all in PETG the runners that touch the head eventually softened and created VAC-leaks, but that was expected
I wanted to have the design ironed out somewhat before going to expensive material.
The stock intake on the M52s is made from PA66-GF so using PA6-CF/GF although with less fibres than injection molded is pretty close to the original.
PA/Nylon with fibers is doing fine without a enclosure! Do you have a printer?

...i think you need one of these for your stroker

Today i also made a very disappointing discovery regarding all my previous logged data . I noticed that my Arduinos 5V circuit was running at only 4,7-4,8V. What i thought was the AFM and MAF maxed at 5V is them really at 4,7-4,8V due to Voltage-reference->Arduinos supposed 5V rail the precious airflow...its all gone

I did remedy this today for another test by juicing the Arduino externally to 5,1V and connecting the very precise 5,0 V as my Voltage-reference from the ECU.
From what ive read this is risky because the external reference can only be active as long as the Arduinos 5V is present and higher than the reference...
I was thinking of using a relay that connects the reference only when the Arduino is already running and commands it. And i may try running it at 5.5V to avoid beeing lower than the reference. Will see

logs with correct ref:



to get over the disappointment from the Airflow being measured wrong cause i am a dumbass i tried the DAC to simulate the AFM Output to the ECU.
That went really nice at least. Strangely driveability was improved. Was running conversion at 20 Hz.
I did try and add 5% of AFM-signal to everything over 3.2V (so that its mainly WOT), now i really need the wideband stuff, but of course crimpcontacts on backorder

[bmwman91]

Good progress...catching your mistakes and learning form them is how you develop skills. Let me know how the PA+GF prints do after they get some more time under the hood.

So yeah, as far as grounding and references, you always want to try to use all available reference signals for whatever you are measuring. For sure the Motronic 5V signal is what the ADC should be referencing. For grounding, you should run a wire to the same terminal that the Motronic uses (on the battery tray just in front of the firewall).

Where were you getting the supply voltage form before? 4.7-4.8V seems like pretty low output from the onboard voltage regulator.

For the sensor conversion, you will want to add a thermistor (or tap into the existing one in the AFM). Since the AFM puts out a signal proportional to volume flow rate, and the MAF puts a signal out proportional to mass flow rate, the two will diverge as air temperature changes. If you are doing all of your testing at about the same temperature, this will not be immediately obvious. Anyway, the two parameters are related through the Ideal Gas Law. So to be able to properly mimic the AFM signal, you need to read in both the mass flow rate and the air temperature, calculate the volume flow rate, and then determine the desired output voltage that would be expected from the AFM.

I dug through some of the stuff from when I developed the MAF conversion and here are some things you will need to do it properly.

First you need to determine the resistance of the thermistor. It is the lower-leg in a voltage divider, and its value is a function of the measured voltage.

Vin = 5V
Vout is the measured IAT voltage at the AFM
R1 = 1000 Ohm (this is a fixed value resistor in the Motronic)
R2 is the thermistor resistance in Ohms

R2 = (Vout * R1) / (Vin - Vout)


Computing the air temperature from the M42 AFM thermistor is as follows (the 'k' values are specific to the M42 AFM thermistor and are NOT the same for other AFMs found in E30's).

ka = 1.322854E-03
kb = 2.525480E-04
kc = 2.274156E-07
R is resistance is in Ohms.
T is temperature is in units of Kelvin, which are what the next equation uses. Just subtract 273.15 if you want to know the value in Celsius, but don't do any computations with the Celsius values.

T = 1 / (ka + kb * ln(R) + kc * (ln(R))^3)


Converting mass flow rate to volume flow rate using temperature for density compensation:

Vdot is the volume flow rate and the desired output parameter, in cubic meters per hour
mdot is the mass flow rate, determined from the MAF output voltage, in kg per hour
Re = 0.287033 kJ / (kg*K) - this is the engineering gas constant for air
T is the air temperature in degrees Kelvin
P = 101.325 kPa (this does vary based on weather and altitude, but the ECU never measured it, and the MAF inherently corrects for it anyway)

Vdot = mdot * Re * T / P


The M42 AFM transfer function. I actually got this directly from Bosch, and while I can't share the documents I got from them, this function very precisely represents the sensor's behavior. All of the Bosch AFM transfer functions are of this form, although the constants are again only appropriate for the M42 AFM.
k1 = 1.08202
k2 = -1.68872
Vdot is the air flow in cubic meters per hour
V is volts

V = k1 * ln(Vdot) + k2

If you invert the equation, you get the sensor's transfer function for volts to flow.
k1b = 4.76221
k2b = 0.92420

Vdot = k1b * e^(k2b * V)

[coffeeandcigars]

Awesome post with great Info! Thanks for sharing

Where were you getting the supply voltage form before? 4.7-4.8V seems like pretty low output from the onboard voltage regulator.

That was from the Laptop USB. But after i noticed i tried first hooking up 7V to VIN of the Arduino and that was also not a stable 5,0 V. Thats why i tried setting the PSU to around 5,1 and feeding it directly yesterday.

For the sensor conversion, you will want to add a thermistor (or tap into the existing one in the AFM). Since the AFM puts out a signal proportional to volume flow rate, and the MAF puts a signal out proportional to mass flow rate, the two will diverge as air temperature changes. If you are doing all of your testing at about the same temperature, this will not be immediately obvious. Anyway, the two parameters are related through the Ideal Gas Law. So to be able to properly mimic the AFM signal, you need to read in both the mass flow rate and the air temperature, calculate the volume flow rate, and then determine the desired output voltage that would be expected from the AFM.

Yes! My plan was to source another AFM to get a temp sensor, have that mounted in the Airbox and feed the ECU. Have the Arduino read that also and then calculate Volume-Airflow from MAFs Mass-Airflow and IATs temp. From what i ve read the M1.7 has "knock protection" based on IAT (pulls timing if IAT gets too high) and also then recalculates mass airflow (or directly load) internally via AFM and IAT...man thats a bunch of back and forth

R1 = 1000 Ohm (this is a fixed value resistor in the Motronic)

is this true for ECT also?

(the 'k' values are specific to the M42 AFM thermistor and are NOT the same for other AFMs found in E30's).

Wow, you saved me a bunch of headache!!! Wanted to steal the IAT from some random AFM i could get for cheap...strange that they werent using the same part throughout I guess finding a different one similiar enough is a bit of a challenge then outside of an M42 AFM.

The M42 AFM transfer function. I actually got this directly from Bosch, and while I can't share the documents I got from them, this function very precisely represents the sensor's behavior.

Thats awesome