Maf options?

[bmwman91]

Yes, the CLT pull-up resistor is also 1k.

I would not worry about the slow response time of the thermistor; the one in the AFM isn't any faster. The air temperature definitely changes between idle, PT and WOT as higher flows will cool things off as the air has less time to heat up, but I have never seen it be an issue. You do want to mount the thermistor in such a way that it does not get heat-soaked by whatever it is mounted to. I actually have mine mounted in the air tube that connects the inlet to the air filter box to the cover behind the headlights. Originally I had it in the air box, but I found that it was reading too hot since there is a lot of hot air trapped there (back of the air box near the PS reservoir) which would heat up the wiring, and with it being copper, it easily conducted into the sensor. Then again, the AFM is a giant piece of metal, so I doubt that the thermistor was immune to that effect either.

As far as the fast transient behavior like when you snap the throttle, you generally tune parameters specific to those situations. There are compensation factors for TPS rate of change and stuff, so the IAT thermistor lagging is not likely to be an issue.

[coffeeandcigars]

I guess finding a different one similiar enough is a bit of a challenge then outside of an M42 AFM.

M42 IAT:
R25 = 2081,7 Ohms
R25/85 = 3534,49 K

I came across this one here that seems to line up not too bad and its way easier than getting a 2nd AFM
Vishay NTCLE350E4212FMB0
R25 = 2100 Ohms
R25/85 = 3511 K

https://de.farnell.com/vishay/ntcle3...ohm/dp/3777722
Looking at the Response time in the Datasheet i am unshure if that is fast enough to accurately follow the IAT when going from slow cruising/idle (very hot IAT) to WOT (cooling down quite quickly). What do you think?

[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

[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]

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]

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.

[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.

[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]

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]

...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, 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]

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]

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]

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]

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.