Here's the Link
 

Finally signed up at famous miataturbo.net...


First to answer shuiend: My intention when developing the MAF Converter was primarily own interest to find a proper solution to eliminate the bottleneck of the original AFM. It was a hot topic in the German forum, people trying to find mechanical workarounds getting more air into the engine. I started assembling some more units to help other drivers, a deal in exchange to getting feedback and making it reliable and stable.


At the moment I'm limited on time and no printed circuit boards are left. What I could imagine is work on a new series end of the year - if enough interest is there.


One point to mention is the need for the original MAF plug for the Converter. You can't buy them (as far as I know), but the plug is mandatory to avoid provisional jacks and sticking to the original wires.

Gunar, welcome to the forum. Nice looking device, by the way.

I wonder if you would satisfy my curiosity by describing the method you used to convert from the new MAF signal to the inverted AFM signal.

I had to check this thread wasn't from 1991.

MAF Converter characteristics
 

The starting point for the conversion was measuring both, the output of the original AFM connected by pipe with the Volkswagen Pierburg MAF, outside the car for different static airflows (using an adjustable garden vac :giggle: ). This provided the first plot. For the coding also algorithms to avoid double compensation of air temperature (already done by the ECU) and controlling the fuel pump were needed.
Next step was to test the behavior in driving conditions. Here for instance it turned out that the dynamic behavior of the Pierburg MAF required some fatter AFR at low end compared to the original. This was quite a surprise, because the response time of the MAF according to Pierburg should be in a range of <50ms, the Converter works with 16MHz and recalculates signals in around 10ms. Both pretty fast, but I guess this is quite normal in building ECU maps and optimizing behavior between parts.
We then also did some logging of the AFR together with rev and throttle position/vac to validate the behavior. The goal was to follow the original characteristic as much as possible whilst creating the best power output when revving up under full throttle.
Never put it on the dyno, but recent feedback was, that the power of the 1.6 NA with Converter is very close to the 1.8 NA ( from a guy who owns both).

Hi Joe, does this answer your question? Any comments?

Gunar your kit is fantastic :)

I'll second that. I have installed it on a stock '91 and a turbo '91 and it has performed perfectly.

How does this kit work on a 1.8 swap? I just bought an RX7 non-turbo AFM and would still like to go this direction if it will work well. If you are going to be constructing a new version could you make one optimized for 1.8 swaps? I realize that most will go the ecu route for boost and also serious N/A guys as well, but there is a target market for this. Thank you and excellent work!

If it will work on my car I want one ASAP! I could also test one on my car if you'd like to find out how it would work on a swap as I have a wideband installed.

It looks like a very solid design.

My question was actually more about how you implemented the realtime conversion (formula vs. lookup table)- the data gathering process is fairly obvious, and is pretty much identical to what I did back when I created a similar mechanism for replacing the mechanical airflow meter with a manifold pressure sensor using the Greddy eManage Ultimate. (A woefully obsolete device by modern standards.)



Assuming that you are keeping the stock 1.6 ECU and using the 1.8 injectors, there should be essentially no difference. The 1.8 will draw slightly more air, and the 1.8 injectors will deliver proportionately more fuel. No need for different mapping.

Good point Joe. I thought about that on the drive home from work and wish I could have edited my post one more time. 1.6 ECU and 1.8 injectors so It'll work OK for me. Thanks!

Conversion and coding
 

Air mass and temperature are captured by the on chip ADC. The code is using a mathematical interpolation formula to follow the conversion graph (see post before) as good as possible. After using 6 different ranges for the interpolation, I'm now down to an engine off value, 2 interpolation ranges (or call it linear equations) and a max value working fine. It is realized with if clauses in the C code. Lookup tables proved to be much slower in execution. However when it comes to analog conversion with the on chip PWM, non-linearity of the output transistor has to be compensated as well. Because the ECU compensates temperature for the air flow, the code also takes care to compensate the compensation (Yes), because a mass airflow meter automatically takes care of air pressure, humidity and temperature in its output. All in all not so straight forward...
:idea:


Hope this helps.


[QUOTE=Joe Perez;1243061]It looks like a very solid design.

My question was actually more about how you implemented the realtime conversion (formula vs. lookup table)- the data gathering process is fairly obvious, and is pretty much identical to what I did back when I created a similar mechanism for replacing the mechanical airflow meter with a manifold pressure sensor using the Greddy eManage Ultimate. (A woefully obsolete device by modern standards.)