NefMoto

Hello,

I have an application where I am wanting to run parallel MAF sensors on a 2.7t. The engine is going in a Boxster so the need for parallel MAF’s is driven by spatial constraints and the desire to keep using ME7.1 engine management to maintain readiness monitors.

I have an Arduino nano that I am using to read 2x MAF sensors from a 1.8t (06a906461l), using lookup tables to first convert from voltage to mass air flow (g/s), then add together (sum) to get total mass air flow, then covert again to a voltage that the stock hitachi MAF sensor (06C133471A) would output, then output that voltage to be read by the me7.1 ecu.

I’ve got this all rigged up on a test bench. I am using a y-pipe to connect 2x 1.8t mass air flow sensors to 1x hitachi S4 sensor so that I can compare my simulated voltage (parallel MAF voltage being crated by the Arduino) to the hitachi sensor voltage that I am trying to emulate… I am doing this to check that my hardware and software is doing what it should be doing. Then I have a leaf blower attached to the setup to pull air through everything.

I can tell that my 2x 1.8t readings are almost exactly the same. This gives me confidence that the sensors are good and my measurement setup is ok. My issue is that the Arduino simulated voltage isn’t as close to the actual hitachi voltage that I’d like. In example, when air is moving and the hitachi sensor reads about 3.2v (which is about 107 g/s), the Arduino spits out 3.0v. The hitachi sensor is used, but came from a good running car. Also, if the sensors was degraded, I’d expected it to read low as opposed to high.

My question for the forum is… I am using the mass air flow vs voltage tables from the associated ecu bin files to make my conversions… should these be reliable enough to make my voltage-maf conversion with? I COULD adjust my conversion table to dial the Arduino into this hitachi sensor, but it seems like I should be able to just use the tables from the ECU’s. In all, the Arduino and the hitachi sensor are about 6% off of each other at 3v… is this too much? Error will likely be greater at higher mass air flow levels. What do you think?

Either way, you're going to probably need to tweak MLFHM/KFKHFM/KFLF etc. etc. so whether or not you do it in the arduino code doesn't really matter much.

Fair point, Arduino table and MLFHM could be anything being that I have control over both. Just trying to get started with something usable.

Do you have any idea what sort of accuracy should be excepted out of a MAF sensor? I found a Bosch document that stated 1.5% for new hot film MAF sensors… I realize the tune will have to be dialed eventually, I’m just trying to set a target for how good my Arduino+2x MAF’s need to be before I stop thinking about it and move on.

Would really help to have a calibrated flow bench.

Thanks!!

Accuracy or precision? heh. hard to say.

its better to run it with stock maf and yours and then compensate difference with KFKHFM/MLHFM
1 point of comparing its a waaaay far from any precision

p.s. what about "add ushfm_w, uushk_w" would be much easily than arduino.. yay or nay? 

I was thinking accuracy - the sensor and arduino voltage readings seem pretty stable, they are just different. I've checked that my 5v and 12v supplies are stable. I am thinking either one of the conversion tables i'm using is not very good (even though they were taken straight from the bin files) or the hitachi MAF is suspect. Here's a graph to show the difference I'm seeing.

(https://i.imgur.com/SZ1mJHul.png)

I totally get that the SW can be adjusted to dial it in, I'm just trying not to make sure I'm not building in some error into my MAF setup.

fukenbroken - what do you mean by "its better to run it with stock maf and yours and then compensate..."?

Again the reason I'm pursuing parallel MAF's is because of spatial constraints - i'd have to make some pretty elaborate intake ducting to tie into a single MAF sensor.

That's plenty consistent. I'd say build your MLHFM based on your data and call it a day

Well I added an artificial scale on the arduino table (scaled up the hitachi MAF table) to bring it real close. MLHFM can take it from here. In this plot, you can see the low and high speed on my leaf blower then the cost down to zero flow.  This equates to about 3.1V (100 g/s) and 3.6V (145 g/s). I guess the take away is if you want to test a MAF sensor at full scale, you need a pretty big leaf blower.

(https://i.imgur.com/qDmxLk4l.png)

I'm sure you already know this, but the flow profile of a leaf blower is going to be very different from actual flow with airbox and the fact that it is pulling not pushing etc

nyet - great points and understood. Definitely not the same, but I did include a few key elements to make my setup somewhat representative.  I'm using the blower as a suction device (it can be reversed on my corded Toro unit by reconfiguring it). It is placed a couple of feet away from the 2.7t MAF in an effort to eliminate any flow nasties from affecting the MAF sensor. On the 2x end of the y-pipe are the 1.8t MAF sensors with the small cone filters directly attached (as I intend to run them). 

Perhaps the 9% that I had to modify the hitachi table with accounts for the specifics of the 2.7t airbox & intake ducting.

I tried to spare the folks by blurring my disaster of a workbench, but here's the setup.

(https://i.imgur.com/gJIR6WGl.png)

Introducing another point of failure is dumb.

Either run SD or if you really want two mafs then wire 2nd maf to rear O2 input and add them together in software in the ECU.

There is absolutely zero reason to run a piggyback, and I seriously doubt you are going to get the construction right where shit won't fail due to vibration or moisture.

Thats definitely not going to work well with the maf that close to the filter.

No wonder your signal is very different. I'm surprised it is as similar as it is.

You're going to see some very strange results at idle IMO

The airbox (and entire tract) on the 2.7t intake is specifically designed for linear results across all intake velocities.

Messing with that invites a whole host of fueling issues that can only partially be mitigated with KFKHFM/KFLF/FKVVS

A couple of things to take from your comment -

1. I should check response at lower flow rates (3-5.5 g/s is spec for idle), this will give me a better read on drivability and idle stability. It would be acceptable if both the hitachi and Arduino read within 3-5.5 g/s.

2. Check the effect of putting a straight section in front of the 1.8t mafs. I’m sure that the cone filter mounted on the maf housing doesn’t explain the 9% because during testing I could put my hands on the filter in an effort to divert flow and the effect on measured air flow were very little… but this could be worse at lower flow (idle). I’m aware that it is recommended to have a straight section in front of the maf, but that isn’t really a luxury I have. The OE setup has the maf mounted directly to the air box which is basically a velocity stack in a box… so OE doesn’t exactly have a 12” straight in front of the maf sensor either.

This kind of goes back to my original question of how close is close enough? With the 1.09 scale built in, the flow curves line up pretty well, so the system in the picture (2 MAF’s, cone filters on MAFs as shown, Arduino) is representing the hitachi MAF as accurately as the graph shows.

It's unfortunate that you don't realize that none of this matters.

Your arduino is:
1. Not going to have pulsation correction (if relevant).
2. Not going to be able to take advantage of KFKHFM
3. Will probably make the ECU throw codes if the correct voltage is not presented on the pins fast enough.

At this point you might as well connect the two voltages together and feed it into the ECU.
The precision will be about the same. This is a massive waste of time. As is trying to look at gram exact accuracy when you're going to be adding this and then ECU will do wrong corrections via KFPU and KFKHFM to it. Giving you errors of 10% and more.

If something I learned is that the most dangerous people are those who picked up a microcontroller for the first time. They have an urge to stick it into every place possible, where it's not needed.

The code to do what you want to do is literally trivial to write, you need to copypaste the MLHFM routine, change the inputs and outputs, call both halves, then add the resulting two airflows and write them to mshfm_w and mshfms_w.
That's it, job done. You can even look how it's done in the C5 RS6 from factory. Takes maybe half an hour to write it (I'm being generous).

Even better is to remove the MAF's in the first place and run SD in this situation.

@Nye I am surprised you are being an enabler for this madman. None of this is needed, it's a huge downgrade in precision and reliability. You will get better results even running alpha/n than this bullshit.

I'm curious about this, why wouldn't KFKHFM apply?

In any case, I agree with the rest of your statement.

The reason this is so popular, of course, is that hacking arduino code is much easier than hacking in ASM and has a much much much lower barrier to entry.

I'm not flat out discouraging him because it's at least less dumb then alpha-n.

Being that the Arduino is trying to replicate the OE MAF signal, it seems like KFKHFM would apply, though it’s ability to make up for the potential inadequacies/discrepancies of the Arduino remains to be determined.

That being said, agreed the rs6 method is much cleaner, thanks for pointing this out and also agree the barrier to entry with Arduino is much lower (I will go learn how to implement the routine in the ecu). The trivial algorithm that was pointed out is exactly what is bing used (nothing fancy), just outside of the ECU in a separate controller.

As was pointed out, the loop rate of the Arduino vs what the ECU is expecting is a point of risk along with how fast the Arduino can respond to changes in airflow.

You will also have clock synchronization issues because the ECU runs in 1ms raster etc.
My point is just physically wiring the two signals together into one and feeding it into the ECU won't really be any worse than the Arduino for precision and will be much more reliable.
Linearizing them separate in the ECU and then adding them together is the only thing that is better.

KFKHFM criticism does not apply, I forgot that the axis for KFKHFM was rl. So it does not matter if you apply it to each individually or to the whole result. The RS6 applies it to each individually though IIRC.

prj, why not suggest digging the MAFs altogether for your MAP based load conversion?

I did. And that's what I'd do in a such situation.
It's much harder to tune though, because BGSRM actually has to have reasonable values so that load is right, unlike with the MAF.

For this you will need to program atmega328p(most arduino boards use it)  in C, without any libary.  It will take you more time to learn all that than ASM in C167
And as other suggest, stock ECU will be more safe to use, and it will be far more better.
I am using atmega328 for years pushing it to limits, I know it can do this task to work without problem, but I also suggest do it with stock ECU

Just wanted to offer a word of encouragement - I've talked to quite a few people from around the Internet who were working on Arduino based piggyback hardware of various sorts. It really is a "when you have a hammer, everything is a nail" type of situation, it would seem. All of them have been able to learn how to do things with stock ECU instead. One of my main motives in publishing open source and open documentation for various ECU tasks is to get more people out of the "ECU scary, going to make hack hardware instead" mindset.

Agree that the Atmega approach is totally viable too, albeit challenging. To do things in a theoretically correct way you'd need <250us latency and 2khz loop rate (Nyquist), so that the ECU sees the same 1ms samples as it would without the Arduino in place even if the cycle clocks are skewed from one another. The real constraints to make the car run are probably looser, but still this is not a place where you want to be introducing latency or aliasing artifacts of any kind. And at the end of the day, you still have to deal with the usual analog stuff (ground loops / voltage bias, noise, blah blah) and you have an unreliable piece of homemade hardware in your car.

Getting the tools set up to patch is worth the investment as you can add much more functionality and you don't have to worry about these kinds of hardware devices again.

Thanks everyone for the valuable input and pardon my ineptitude on the matter. This sets up the 2.7t Boxster for success and I appreciate it.

I’ll also add that I’ve used arduino+atmega32p for over a decade to exteranlly control my N75 based on MAP voltage. I did this mainly so I could instantly change my boost curve on the fly.

I’ve later patched ME7.5 to do something similar to what prj suggested and used post-cat O2 input to read a 2nd MAP and an output to control a 2nd N75 for a compound turbo setup. I’ve also used SAI relay output for an exhuast cutout.

However, my most recent project is to use arduino + ESP32 to drive a LCD for a custom color MFA just to display selected gear on a dsg swapped mk4.

For engine control, I agree with the others. Very worth it to learn.

The length of the suction path, from the air flow meter to the turbine impeller, is 1.5 meters.
Y-pipe is asymmetric at the inlet (near the flow meter) and with a large angle of attack of the air flow.
What "linearity" are we talking about? This is pure savings and implementation on one flow meter!
In terms of gas dynamics, a design with a crooked Y-pipe is an engineer's nightmare. It is near the measuring zone of the flow meter that the swirling of the intake air flow occurs, distorting the measured data!

The desire and the idea are clear and real.
Personally, I implemented a signal adder for two flowmeters for atmega 328, two 12-bit spi ADCs and one 12-bit spi DAC. Based on two Bosch flowmeters
0280217814 with a limit of 1560 kg/h and corresponding original linearization curves interpolated to 12 bit resolution.
After working with the code, we got a sampling time of 20 kHz at a resolution of 12 bits.
The addition of values ​​from two flowmeter signals is performed correctly and coincides with the mathematically added values.
The naturally resulting linearization graph(MLHFM) is created mathematically as a sum and put in me7.1.

The official Bosch information about HFM5 indicates the following time parameters for converting air flow into voltage:
1) T1 = 15 ms (In case of sudden increase of the air-mass flow from 10 kg · h–1 auf 0,7 Qm nominal, time required to reach
63% of the final value of the air-mass signal.)
2) T2 = 30 ms ( Period of time in case of a throughflow jump of the air mass | ∆ m/m | ≤ 5%.)
With a conversion time of 15ms, we obtain the maximum frequency of the air mass meter signal change equal to 66.6666 hertz
The available 20kHz ADC/DAC sampling rate is more than sufficient to respond quickly to changing flowmeter signals.

It is important to pay attention to the reference signals Vref, which are twisted into one point by the author of the topic ...)