MicroSquirt.com read only forum (Jan.15,2018)

Since there has been more activity as of late on installations using MAF sensors, the question of how to obtain a calibration curve for a particular MAF sensor. To help with this I have created a windows application called the MAf Analyzer, available here:

http://www.microsquirt.info/mafmap.htm#MAF_analyzer

What this program does is to fit a series of measurement points to a mathematical model. With this fitted model it is then possible to generate the dense 1024 points needed in a maffactor.inc file for microsquirt/MS2/Sequencer. The measurement points can come from a magazine, Internet, or actual flow/response measurements. The program uses two different numerical least-squares methods to reduce the data (depending on if there is zero-flow response data available) and provides an error analysis on the functional fit compared to the measured data.

The zip file contains a detailed writeup on the operation of the Maf Analyzer program, and some example flow test runs for GM LT1/LS1/LS2, Ford Lightning and Infiniti Q45 sensors, with the generated output maffactor.inc files available on the website link (above).

- Bruce

Let me add a few things about the ECU software that goes with this. The release is 2.905, applicable for MS-II and microsquirt in non-dual spark mode. For microsquirt in dual spark mode any of the existing 3.4x codes can be used. In all cases, if you are going to use the curves generated by the MAF Analyzer, you MUST use TS only, 2.905 and 3.4x inis won't work in MT.

The most significant additions to the 2.905 code are:

For indexing spark and AFR tables the SAE PID 43 option should be used. This is considered the best way of handling this and is explained in the MAF Analyzer document.

There is a new ouput variable, synch status, that may help with identifying VR sensor problems. It will show up on a datalog next to the Trigger+- status. The Synch status codes are:

0 = Looking for 2 consecutive regular teeth
1 = Looking for missing teeth
2 = Waiting for Delay Teeth to pass
3 = Achieved full synch

There were also significant improvements for CAN working with GPIO devices such as the transmission controller.

grippo wrote: There is a new ouput variable, synch status, that may help with identifying VR sensor problems. It will show up on a datalog next to the Trigger+- status. The Synch status codes are:

0 = Looking for 2 consecutive regular teeth
1 = Looking for missing teeth
2 = Waiting for Delay Teeth to pass
3 = Achieved full synch

Let me follow-up with the significance of the sync status output when you are debugging a VR sensor setup. This, along with the trigger+/- are all you need to debug VR tach issues - they go a long way in understanding what the code is thinking...

How I would use it is the following: when installing on an engine, just hook up the power and VR sensor. Next, crank the engine and watch the Sync value. If all is well the Sync will march up from 0 to 1 to 2 to 3 and stay at 3 forever - if so then you have good sync.

- Lets say you have do not have the VR connected. When you crank, the Sync will stay at 0 - this is your indication that no signal is getting into the microsquirt.

- This time, lets say the VR is hooked up with the leads reversed. Crank the engine. The Sync will count from 0 to 1 to 0 to 1 to 0, etc. In this case, reverse the leads.

- To check for noise in the system, look at the Trigger +/- variable. What this does is clean up noise by either putting in or taking out a tooth where one should not be. For example, often with missing tooth wheels, at high RPM, during the place where there is the missing tooth the VR circuit may trigger. This is due to the "phantom tooth" effect. The firmware will detect this tooth and automatically throw it out - and it will increment the Trigger+/- variable. So the firmware basically "recovers" from the incorrectly added tooth and everything is OK, but to let you know.

The code will only recover from one added/missing tooth per revolution - if it encounters more that 1 badly-placed tooth it resets sync to 0 and starts all over again - this is your indication that there is VR noise coming in....

Note that during the start-to-run transistion, there ay be some added/removed teeth and the trigger+/- may change a few counts. This is normal. But, once the engine is running the trigger +/- should stay constant. I

- Bruce

Mind post the GM/Delphi part number for the MAF?

I'm getting ready to use the Infiniti Q45 sensor in my car. I used the MAF analyzer program and input the data from the MAFMAP page. The data that the program gives is very different from the included Infiniti .inc file. Could some elaborate as to why the differences exist, and which one I should be using? Thank you. Attached is a copy of my maffactor.ini that I generated with the MAF analyzer program and formatted to work with the MS2 source.

The data you show is about half the flow of the file included in the MAF Analyzer. What data did you enter in the MAF Analyzer to get the output that you did. If it is a table or curve please post the table or a picture of the curve. Make sure you include the units of the flow and the source of the data. This seems to be way too much difference if the same MAF type was used.

I used the table that is on the MAFMAP page. It is as follows:
I divided by 3 to get g/s to mg/s

To convert you have to divide by 1000, that is, move the decimal place 3 to the left. So 1480 becomes 1.480, 17510 is 17.510, 605990 is 605.990. I did this to your numbers, entered them, and got a reasonable curve. I don't know where the 49542 max that you got came from, since if you divide the 605990 by 3 you would get something near 20000.

Oops, my mistake. I meant that I divided by 1000 to move three decimal places. Also, I want to use "10*mg/sec" as the output units, correct?

Yes you want 10xmg/sec for the output units. But I have noticed some discrepancies in the example files. I will talk to Bruce about these.