Since the SciVision has its own translator, there is no need for a piggyback to go along with the Ostrich. If your plans are to use a "generic" MAF sensor, you'll need a piggyback to skew the output voltage so that the DME can process the signal accurately.

Before going with the SciVision, I picked up a great piggyback controller called the XFC (Xtended Fuel Controller) and I intended on using it with a compatible MAF sensor and just tweeking the output to get it to work. In the end, I ended up using the piggyback with my SciVision strictly cause of its great datalogging capability and PWM outputs that I used for controlling a boost solenoid. I used it to log RPM, boost/MAP, knock activity from KLR, MAF voltage and exhaust backpressure with another MAP sensor.

For guys interested in venturing down this mod path, I'd recommend going with an Ostrich setup cause it offers all the control you need to fine tune your car (on a budget). You do need a datalogger to get feedback info so that you know where to make changes. If you want to do a MAF conversion with a generic sensor, take a look into the XFC controller - I felt this piggyback offered way more functionality than the piggyback controllers commonly offered for the 951.

I still have my XFC and no longer have any use for it since I've moved to a standalone engine management system. If there is anyone interested in this piggyback for a MAF conversion please send me a PM.

Ok, attached is an Excel worksheet that allows you to play with the three AFM Transfer Function Tables. This worksheet will output a graph of the transfer function, and will hopefully allow people to get a better understanding of the 944/951 workings by manipulating the tables.

Transfer Function Worksheet

Furthermore, those with aftermarket MAFs, can try to get the transfer function to match their aftermarket unit (and see why the 944/951 stock code is limiting).


-Rogue

Vic you have a PM, (actually three identical, my excuse is browser malfunction, sorry).

I have started playing with the tuner pro software, but I don't seem to be getting anywhere with it. Since I already have the ape MAF setup on my 951S, I disregarded the 24 and 28-pin bins that were included in the bundle, and used the ape MAF bin instead. But things don't seem quite right with the bundled 28-pin XDF file. Is there something I need to do in reference to that, or isn't there any problem there? Also, I don't plan on getting/using the ostrich, since you state that an eprom burner (which I now own) will suffice. Only I will be using eeproms instead of eproms, to make erasing/re-writing them less of a hassle. I understand that I will not have any real-time logging capability, and will not be able to make on-the-fly changes by going this route. What I AM expecting, but can't seem to get out of the tuner pro, is the ability to see the tables, maps, and functions contained in the bin, along with the ability to make alterations to them, based on the readings produced by my A/F gauge and knock sensor, after making a test run. What is the error of my ways here? And what do I need to do, to get things rolling?

The APE chips moved the maps all over the place. I would have to build a new .xdf to make TunerPro properly work with the APE chips...
Frankly it isn't worth my time - the APE chips are nothing special anyway. They are nothing more then tuned AFM chips.

You should just start with the .bin provided in the bundle, and tune from there.


-Rogue

Thanks, Rogue. By saying "they are nothing more then tuned AFM chips", I assume that you mean that they use "false" MAF code (meaning that the APE setup is a cheater system), while you use true MAF code? Do you mean to say that if I start out with the bin that you provided in the bundle, it will work OK for the APE maf setup? And what are the chances that you could send me the BIN and XDF files that YOU are using, so I can start out with something that is based on truth?

Yes, you could call it "false" MAF code. But even that is a stretch... APE didn't touch any part of the code that actually deals with reading the airflow meter / MAF. So the reality is that the APE chip is simply an AFM chip that has been tuned to "work" with the MAF they selected...

Yes, I've re-wrote the code to understand air-mass, and have been running a MAF sensor directly to the DME (no piggyback) for a while.

The .bin I provided will work fine for the APE MAF, though you _will_ need to tune it.


-Rogue

My stupidity - the [28pin DME limited.xdf] file DOES INDEED WORK for the APE MAF bin file. I didn't realize that I had to double-click on the parameters to view the data, as I have my computer set up for single-click operation, and I'm not used to double-clicking. But I am far from having a complete understanding of it all. For example, I can't understand why the rev limit it set to 7040, but the WOT fueling map only goes up to 6240. What is going on with fueling, between those 2 numbers? That is precisely the area where I have the most concern about running too lean. And why is there 3 different AFM transfer function tables? Since you seem to be the resident expert around here on this stuff, I'd like to emulate what you are doing, if you don't have a problem with that. It doesn't bother me a bit if people emulate what I am doing. In fact, from my perspective, it tends to help validate it. I'd like to know what MAF unit you are using. I am considering using a Ford unit, in place of the APE NGK one, although it is nice and shiny chrome. Also, what size injectors are you using, and what is your max boost set to? The "true" MAF code that you have written is what really tweaks my interest though (it rings like the bell of truth, inside my head). I assume that you have an XDF file that works with it. What would it take for me to get a copy of it to work with off of you? Since you undoubtedly spent a lot of time and effort writing it, I am willing to pay you some money. Unless, for what ever reason, it is something that you wish to keep to yourself. Let me know. Thanks.

The .xdf does not work properly for the APE .bin - trust me.
You might get some data correct, but most the data is moved, and won't display correctly using the .xdf.

As far as the WOT map only going up to 6240 - any RPM value above that simple uses that last cell...

There are three different AFM tables because of how the DME defines the AFM transfer function curve.

I'm using the new slot-style hitachi MAF - an excellent sensor, much better then previous gen stuff. Boost is ~18psi, and injectors are 76lb/hr.

I will not be releasing an .xdf or .bin with my MAF conversion.

But I'm more then willing to help anyone who wants to explore this DIY.

You should take a look at this thread - lots of good info here:

More DIY stuff

The first 3 questions are answered. I am not familiar with "slot style" MAF sensors - what exactly does that mean? Probably the only things I plan on changing in the APE code are that last WOT fueling cell, and possibly timing, IF I decide to raise my max boost from 20 to 22psi. But using the FQS switch, without even touching the code, would also accomplish those 2 things. But I would like to raise the A/C on idle up to to 1000 to 1100rpm, for better cooling while sitting at red lights. The other issue that interests me is the fact that your MAF conversion also incorporates a MAP sensor. I was under the impression that with one of those, there is no need to have an MAF sensor. Could you explain that? And would it be of any benefit to me if I install a map sensor, and splice it into to the DME? I do appreciate that you are assisting me in this endavour. But save for upping the A/C idle rpm just a tad bit, at this point, I may just decide to leave the DME firmware alone, and go back to my original plan of installing a 3 or 3.5 bar FPR, along with using the + 12.5%, +25%, and -2.73 degrees FQS settings, as needed. Maybe I purchased the chip burner needlessly.

The slot-style is simply the new Hitachi sensor - variations are used in everything from Ford to Chevy to Nissan.
The purpose of incorporating a MAP sensor is to get the best of both worlds. With a MAP only setup, each chip would have to be custom tuned to the specific engine VE in order to determine air-mass. However, with a MAF, the DME directly reads air-mass - if the MAF curve is programmed into the DME, the AFR will be correct regardless of mods (assuming enough fuel). Now by starting with the MAF setup, and incorporating a MAP, we can get the DME to also understand boost! Using the MAP, we can adjust timing and targeted AFR for different boost pressures! No longer will the user have to re-chip or re-tune for different boost. I.E. You can run 12psi of boost and the AFR/Timing will be proper.
Now you turn it up to 18psi, and the DME will automatically adjust for the higher boost - AFRs stay solid, and timing is adjusted appropriately.

I've been able to get a lot of functionality out of the DME, by re-writing and changing the code. Without these changes, hooking a MAP up will not help in any fashion.

Finally, I still have significant doubts that the APE .bin is going to operate correctly with the DIY Tuning packaged I released. Send me the .bin so I can verify - if you start making changes and the .xdf isn't correct, then you could seriously damage the engine...

Rogue,

Good for you on getting the DME to properly work with the MAF and MAP signals. Are the changes to the code done thru the TunerPro software then? Is there info available on the internet that would help in figuring the proper MAF specific code or is this a custom solution?

Way to go!

No real info on the 'net - and the only one who has done true-MAF conversion before isn't about to give out any info.
This is the result of much time of mine, invested in dis-assembling the stock software...

Cool stuff is coming ;)

Thinking about the MAF and MAP combo some more... The DME uses idle, part throttle and a single row WOT table for fuel and ignition, so have you re-written this arrangement for using the MAP sensor? If I recall correctly, the maps use LOAD vs RPM, so I'm guessing that the ignition table must be using MAP on one axis to allow for the "correct" timing at different boost levels.

Yes, I've re-written the tables and expanded them as well.
You are correct that the axis are now rpm vs pressure.
Additionally, I've changed the overboost function to use the MAP sensor as well - so now the DME has real protection from an overboost situation.

All really cool stuff - congrats man. You've definitely provided the 951 community with a tuning solution that far exceeds ANYTHING on the market that retains the DME. Keep up the good work!

Thanks :)

Any chance of getting the DME to recognize a CAM sync instead of the REF signal for sequential operation? Since the DME from the S or S2 do it, would this be possible for the 951 DME? I've got a sweet, simple, bolt on (hall effect) cam sync arrangement that I use with my standalone system that works great. Would be interesting to hear if this would be possible.

Just looked at the wiring diagram - 951 only has 2 injector ouputs and single wire output for ignition. Any open pins that could be used as additional ignition or injection outputs?

Well hall effect sensors have a different output then VR sensors (typicaly). Some testing would need to be done to see if the DME could accept that signal as a "trigger"... And even if so, the software would need to be re-written to understand and use this signal, which would need to have at least two signal events per cam-rev.

But more importantly, the DME has only the single injection circuit... This means that even if all the above "ifs" are accomplished, there is no way to individually fire an injector - the DME fires all the injectors simultaneously because that is how the hardware is configured. No way around this, without changing internal DME components (and a lot more work unsaid).

Just saw your edit.
There is a free output that terminates shortly after the uP... I suppose a conversion to an external injector controller that accepts a TTL signal could probably be accomplished...
Though that is a hell of a lot of work just to get a little bit cleaner idle and low-load cruising.

Any way of splitting the ignition output to where you could run wasted spark?