Click here for MegaSquirt® MegaManual™ Information, Guides, and Links
The software application you use to tune and configure your MegaSquirt-II™ (or MicroSquirt®) controller is called TunerStudioMS by Phil Tobin.
You also need Windows 9X/ME/XP and a conventional serial port to communicate with your MegaSquirt-II™ (or MicroSquirt®) controller. USB will may work, and many people have reported that they have been successful using a USB-serial adapter. Just about any computer that is capable of booting Windows 95 (or better) will be fast enough, but get the fastest laptop computer you think is reasonably priced.
To tune all the parameters of your MegaSquirt-II™ (or MicroSquirt®) controller so that your engine runs the best it can, you will need to do the following:
This section of the manual covers the first two items. the remainder are covered in the Tuning MegaSquirt-II™ (or MicroSquirt®) section. Before starting this section, be sure you have read and understood the information on the MegaSquirt-II™ (or MicroSquirt®) Installation page.
Some general principles to follow when setting the configuration parameters are:
Note that it is possible to damage your engine and/or MegaSquirt® by choosing inappropriate tuning or set-up parameters in TunerStudioMS. Be sure to read this document, and all associated tuning documents that apply to your engine, vehicle, and tuning circumstances. In particular, read the safety precautions.
TunerStudioMS has an 'automated' install package, similar to most other modern Java software. You download the set-up file (see below), click on it, and the package installs itself. You may have to select some options, or you may chose to select all the defaults.
When MegaSquirt® is loaded and communicating with your MegaSquirt-II™ (or MicroSquirt®) controller, the first thing you will see is the front page, which shows eight of the more useful gauges.
A number of the sensor readings are displayed, as well as some outputs. For example, the injector pulse width is the measure in milliseconds of how long the injector is opened for each pulse, regardless of how many times it is opened in a cycle. Duty cycle gives the percentage of time the injector is open irrespective of individual pulse duration.
Setting the General Parameters
Note that as the code develops, some advanced options may not be documented here. To find information on these advanced options, see the TunerStudioMS help file.
Some general principles to follow when setting the configuration parameters are:
Now we are ready to start configuring your MegaSquirt-II™ (or MicroSquirt®) controller!
On the main TunerStudioMS menu is an item called 'Settings/General'.
You can set these as follows:
The lag factors are used as follows:
NewValue = PreviousValue + (NewValue - PreviousValue) * (LagFactor/100%)
In each case the PreviousValue is itself filtered.
For example, suppose your last MAP value was 70, the lag factor is 40 and the current MAP value read directly from the sensor is 90. Then your MegaSquirt-II™ (or MicroSquirt®) controller will calculate:
NewValue = 70 + (90 - 70) * (40/100) = 70 + 20*0.4 = 78
If the MAP then remains at 90, then next value would be:
NewValue = 78 + (90 - 78) * (40/100) = 78 + 12*0.4 = 82.8
and so on...
This has the effect of slowing your MegaSquirt-II™ (or MicroSquirt®) controller's response to fluctuating input values, both smoothing them and reducing the effect of noise in the signals.
The following inputs can have lag factors applied to them:
For example, if you set the upper limit to 6000 and the lower limit to 5800, then in:
If you are using a knock sensor, separate baro sensor, or non-standard MAP sensor, you can configure your MegaSquirt-II™ (or MicroSquirt®) controller to work with them using the 'Sensor Calibration' dialog under 'Tools'.
The MegaSquirt-II™ code is set up for the standard General Motors temperature sensors. If you are using other sensors, you can use the 'Calibrate Thermistor Tables' dialog under 'Tools'. You enter the bias resistor value and three temperature/resistance points, and the table is created and downloaded to your MegaSquirt-II™ (or MicroSquirt®) controller for you.
IMPORTANT NOTE: Do NOT burn tables ('Calibrate AFR Table' or 'Calibrate Thermistor Tables') on a running engine. Even idle is NOT allowed, because these tables ONLY exist in flash, so once a table is erased, there is nothing but garbage in there until it is re-programmed, one word at a time. Until that reprogramming is complete, operating the engine is unsafe.
MegaSquirt uses coolant and air temperature sensors to determine the warm-up characteristics of the engine and the density of the intake air. They are essential to proper functioning of a MegaSquirt® controller. Both sensors are Negative Temperature Coefficient (NTC) thermistors. This means that they are resistors whose resistance decreases as their temperature goes up.
MegaSquirt® uses the temperature sensor as one leg of a voltage divider. The 'supply voltage' of 5.00 Volts (we will call this Vs) is fed to a resistor with a default resistance of 2,490 Ohms (2.49K Ohm) (this is called a "bias resistor", and we will denote it as Rb) and this resistor is connected to the temperature sensor (denoted here by Rs) which in turn is connected to ground.
The voltage at a point in the circuit between the two resistors is used by the ECU to determine the resistance of the sensor, and thus its temperature. The voltage (V) at that point of the circuit is:
Resistor Rp does not affect the voltage divider, it simply limits the current to the processor pin (there should be very little current anyhow, the input is "high impedance").
MegaSquirt-II reads this voltage as a series of voltage steps: 1023 0.005 Volt steps. The conversion from volts to steps is done by the analog-to-digital converter (ADC).
To use a MegaSquirt® controller with an air cooled engine, you will have to decide where the best place is for the coolant sensor: in the oil, or on the cylinder head (CHT). There are various arguments for and against using either CHT or oil temperature as the 'coolant' temperature input on air cooled motors. A lot depends on whether the motor is substantially oil cooled or not. Since the CTS input is used for warmup enrichment, you want something that responds fairly rapidly, so this is highly engine-dependent.
For high temperature applications (i.e. air cooled engines with a CHT), in MS-II you can set the #unset EXPANDED_CLT_TEMP by changing:
#unset EXPANDED_CLT_TEMP
to
# set EXPANDED_CLT_TEMP:
Then the upper temperature limit should be 600 degrees F. This is from the INI notes:
; FAHRENHEIT (Expanded/Normal): ; Low Limit: -40F/-40F ; High limit: 600F/300F ; Low danger: 150F/50F ; Low warning: 200F/150F ; High warning: 325F/200F ; High danger: 350F/220FHowever, you have to calibrate the thermistor table(s) appropriately.
However, note that the tuning software limits the temperature range. The thinking is that if you are at an extreme it is probably a bad or missing sensor, so it goes to a default value. This isn't a big deal in TunerStudio though, you can change these limits in the ms2ReferenceTables.ini file. You can adjust these limits if EXPANDED_CLT_TEMP is set. Currently only the CLT sensor respects EXPANDED_CLT_TEMP, the IAT does not.
IAT min = -40, max=350 if outside that range it goes to 70 CLT min = -40, max=350 if outside that range it goes to 180 CLT with EXTENDED_CLT_TEMP min = -40, max=400 if outside that range it goes to 350 default
Here is the section of the ms2ReferenceTables.ini file that controls that:
; tableLimits (optional) = intentifier, min, max, defaultVal ; will set the default value if value is outside the min and max limits. tableLimits = 001, -40, 350, 70 #if EXPANDED_CLT_TEMP tableLimits = 000, -40, 400, 350 #else tableLimits = 000, -40, 350, 180 #endif"So the user can just edit the one line in ms2ReferenceTables.ini using notepad.exe or something similar to change it from:
tableLimits = 000, -40, 400, 350
to something like:
tableLimits = 000, -40, 600, 350
or similar, and it should work once the user re-burns the table.
The additional problem with very high temperatures is that the difference in voltage gets very small (and MegaSquirt can only read discrete voltage steps, about 5 milliVolts for each of the 1023 steps from 0.00 to 5.00). Also, if the volts at the processor pin gets very near 5.00 (~4.98) the values defaults to a safe value because it assumes there is an open circuit.
The ADC count result from the voltage divider circuit (above) is:
ADC Count = V/Vs = ADC max count * (Rs/(Rb+Rs))
= 1023 * (Rs/(Rs+2490)) for a MS-II (10-bit ADC)
One thing you can do is use a lower bias resistor (R7 for the CLT circuit) - this will give you more resolution at the high end of the temperature scale (but loose it at the cold end). The default value is 2.49K Ohms, and if that is what is in there you might try 2.2K Ohms or less (down as low as 1.0K). Note that you have to re-calibrate the thermistor tables when you change resistor values.
Here is a simple ADC count calculator that shows the number ADC steps for a given bias resistor and sensor resistance. If the ADC count values are very high or very low at your sensor's resistance (at a given temperature), the temperature range may be restricted:
For air-cooled use, one side of the argument says to use the CHT over the oil, as the oil takes over twice as long to get to operating temperature than water in a water-cooled car does. The engine does not need to run rich for long periods, only enough to keep the car driveable while it is warming up. Once the cylinder head is up to temperature, the car is usually quite driveable. For an air cooled engine you can drill and tap into a fin in the head for the CHT sensor.
The other side says that it does not matter if the oil warms more slowly, you can just set the warm-up enrichment to come off at a lower temperature. In that case, the GM coolant sensor fitted in the oil (sump) will work nicely. Search the archives for extensive discussions on these points. It is your decision.
The basic idea of IAC is that the motor or PWM solenoid starts out with a large opening of the air valve at cold startup, then gradually closes as the coolant temperature rises. The basic motor position at any given time is determined from the input table of step position versus coolant temperature. To this basic control algorithm, several features have been added as described below. You need to set your MegaSquirt-II™ (or MicroSquirt®) controller to tell it if you have a fast idle "solenoid type" valve or a stepper motor IAC, or neither. These are selected under Settings/Idle Control in TunerStudioMS.
If you have an IAC stepper motor, you will have to choose between 'moving only' and 'always active'. If you set your stepper to 'always on' for 15 min or so and it doesn't feel too hot to you, then you can leave it that way. Apparently this is what General Motors does. But if you want to be safe you can test it on the bench for 15 min or so. It will get right warm, but it shouldn't burn your fingers just touching it. If it gets too hot, use 'moving only' instead.
To select the appropriate 'Idle Control/Algorithm' for stepper motor control in TunerStudioMS you may need to do some testing. In some cases setting the stepper motor to "IAC Stepper Always On" will cause the IAC to get hot. However setting it to "IAC Stepper Moving Only", might cause a problem with idle speed changing from one start to another.
You can test if your IAC is suitable for 'always on' by leaving your stepper powered on the bench for 15 min or so. If it doesn't feel too hot to you, then set it to "Always On". Apparently this is what GM does. But if you want to be safe they should test it on the bench for 15 min or so, or monitor it closely in the car while not moving for at least 15 minutes, checking the IAC temperature frequently with your fingers. It may get warm, but it shouldn't burn your fingers just touching it.
Leave the other values (below) alone, you can experiment with them when you get the engine running.
This feature is implemented by inputting a 'Cold Position' that is the step position at start of extended warmup, typically about 80% of the final, fully closed step position. The IAC behaves normally until the step position commanded from the table just exceeds this Cold position value (either PWM or stepper). From that point on, the steps are tapered in so as to reach the last step value in the table over the 'cold taper time' period. (see the diagram). This slows the reduction in idle air as the engine continues to warm up (increasing the idle speed for longer than the coolant temperature alone would do).
Before attempting to start your your MegaSquirt-II™ (or MicroSquirt®) controller equipped engine, you will need to set a number of parameters that determine how MegaSquirt® injects fuel. These include the injector open time, Req_Fuel, injector control criteria, PWM criteria, EGO characteristics, etc. These constants are either calculated, or based on the configuration of your system. For the most part, these are very similar to those from MegaSquirt.
Note that for a Wankel rotary engine (Mazda 13B, etc.), see the MegaSquirt & Rotary Engines document for settings and other advice.
On the Settings/Injector Characteristics page:
Conversely, If you had injector specs that stated the opening time was 0.7 milliseconds at 14.5 Volts, and your battery correction was 0.20, then you should enter 1.0 as the 'Injector Opening Time'.
To tune the PWM [pulse width modulation] values for your engine, you need to know what kind of injectors you have- low impedance or high-impedance. If you are running high-impedance injectors (greater than 10 Ohms), then set the PWM time to a number like 25.4, in essence you are disabling the PWM mode. This allows full voltage to the injectors throughout the pulse width.
For low-impedance injectors (less than 3 Ohms), you need to limit the current to avoid overheating the injectors. To do this, there is a period of time that you apply full battery voltage [peak] current, then switch over to a lower current-averaged [hold] current, i.e. peak and hold. Alternatively, you can add resistors in series with the injectors. See the Injectors and Fuel Supply section of the MegaSquirt® manual for more details.
To run low-impedance injectors with the PWM current limit mode, you need to set two parameters - the "PWM Current Limit %" and the "Time Threshold for PWM Mode" - both are on the “Constants” page. The current limit % is the percent duty cycle when the current limit is invoked. The time threshold is the amount of time from when the injector is first opened until the current limit is activated.
High impedance injectors can run on 12 Volts without problems. Low-impedance injectors require some form of current limiting. MegaSquirt® has pulse width modulation to limit the current. You need to set the PWM parameters to match your injectors:
Set the initial PWM% to 75% if (and only if) you have you impedance injectors and you have NOT installed:
Note that most distributors are shipping the V3 main board with the flyback circuit installed. If you are not sure, look for the presence of Q3 and Q11 on the heat sink (3rd and 7th from the left), or ask the distributor.
You will tune these after getting the engine running. See “Setting the PWM Criteria” in the tuning section of this manual. Failure to perform the tuning steps can result in damage to your injectors. If you have high-impedance injectors, set these values to 25.4 ms and 100%, and you do not need to tune them further.
On the 'Settings/Injector Control' page:
In order to come up with this value, TunerStudioMS provides a calculator that will suffice for 99% of applications (those for which it will not work generally require changes to the MegaSquirt® controller code itself, and that is beyond the scope of this manual). To use the calculator, click on the Required Fuel button, and fill in the fields (Engine Displacement, Number of cylinders, Injector flow, and Air:Fuel ratio, then click 'Okay').
For a 4-stroke, a complete stroke cycle is 720 degrees of crankshaft rotation (i.e. two revolutions); for a 2-stroke, it is 360 degrees (this is also factored in the REQ_FUEL value down loaded to MegaSquirt).
In the tuning software, the upper REQ_FUEL box is the amount per cylinder, as noted above. The lower REQ_FUEL box is the value down loaded to MegaSquirt. It is the REQ_FUEL number on top, but scaled by your selected injection mode (number of squirts and alternate/simultaneous).
For example, if you inject simultaneous and one injection, and have the same number of injectors as cylinders [i.e. port injection], then REQ_FUEL on the bottom is the same as REQ_FUEL on top. Same with alternate and two squirts. If you put in simultaneous and two squirts, then REQ_FUEL is divided in half - because you squirt twice, you need to inject 1/2 the fuel on each shot.
Note: if you choose alternating for port injection, make sure your number of squirts is an even number (2,4,...) and evenly divisible into the number of cylinders. For example, with an eight cylinder engine, you could use alternating and 2, 4, or 8 squirts/cycle. With a six cylinder, if you choose alternating, you MUST use 2 or 6 squirts/cycle. Also, the only possible combinations for an odd-cylinder count engine are either 1 squirt/simultaneous or N squirt/simultaneous combination, where N is the number of cylinders."
Number of Cylinders | ||||||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 8 | 10 | 12 | ||
| 1 | OK | simultaneous only | simultaneous only | simultaneous only | simultaneous only | simultaneous only | simultaneous only | simultaneous only | simultaneous only | |
| 2 | no | OK | no | OK | no | OK | OK | OK | OK | |
| 3 | no | no | simultaneous only | no | no | simultaneous only | no | no | simultaneous only | |
| 4 | no | no | no | OK | no | no | OK | no | OK | |
| 5 | no | no | no | no | simultaneous only | no | no | simultaneous only | no | |
| Number | 6 | no | no | no | no | no | OK | no | no | OK |
| of | 7 | no | no | no | no | no | no | no | no | no |
| squirts | 8 | no | no | no | no | no | no | OK | no | no |
| 9 | no | no | no | no | no | no | no | no | no | |
| 10 | no | no | no | no | no | no | no | OK | no | |
| 11 | no | no | no | no | no | no | no | no | no | |
| 12 | no | no | no | no | no | no | no | no | OK | |
"OK" means the combination will work with either simultaneous or alternating. "no" means it will not work with either, i.e., not at all.
The maximum injector pulse width possible with your MegaSquirt-II™ (or MicroSquirt®) controller is 65 milliseconds.
Note that this works with the 'injector staging' parameter (below) to determine the base fuel pulse width, so be sure to read that section as well.
There is some benefit to choosing 2 squirts/alternating for port injection, since only half of the injectors fire at once, the pressure drop in the fuel rails is reduced and the fuelling is more consistent.
With throttle body injection, the number of injection/cycle you can will depend on your number of cylinders, plenum size, Req_Fuel, etc. You have to experiment to see what works best for your combination. Generally, you will need at least as ½ as many squirts per cycle as you have cylinder, though you can run this alternating.
Note that with port injection and alternating injection, you must choose at at least 2 squirts per cycle, otherwise every other cycle for each cylinder will get NO fuel! The engine will run very badly. (One squirt is fine with simultaneous.)
There are a number of considerations in choosing the number of squirts:
More squirts are more likely to help if the engine:
However, if the engine is tuned so that the idle MAP is minimized (likely 13.5:1 AFR or so), and has a higher idle speed (say 800 rpm compared to 600 rpm), then more squirts is less likely to help.
There are definitely some down sides to more squirts:
So more squirts may help. They may not, however. And this can be a bandage for poor idle or accel tuning. So users should start with 2 squirt/alternating for port injection, and tune it as well as they can.
Then, if they can't solve some issues, they should try more squirts. But jumping straight to more squirts is probably not a good idea - most often it just masks the need for a richer idle mixture or more accel enrichment.
|
Example: Suppose you have a 4 cylinder 4-stroke engine. Then in 720° (two revolutions) you have 4 spark events (at 0°, 180°, 360° and 540°, then starting over at 720°=0°). MegaSquirt can only inject on an ignition event, so 1, 2, or 4 squirts/cycle for this engine.
If you have 2 squirts/simultaneous, you have:
but with 2 squirts /alternating, you have:
Both are two squirts per cycle, but alternating only has 1/2 as many total squirts per injector (i.e., since only one channel is active per squirt), so the pulse width must be doubled. 4 squirts/simultaneous would look like this:
There are 4x as many injection events with 4 squirts/simultaneous compared to 2 squirts/alternating, so the pulse width is just 1/4 as long (neglecting the opening times). The req_fuel calculator will show this - watch the top and bottom numbers as you make changes to the alt/sim and number of squirts. The top number stays the same (it is the 'unadjusted number' for 1 squirt simultaneous), while the bottom 'adjusted' number used for the pulse width calculations changes with the number of squirts and simultaneous/alternating. Note that the above tables show which cylinder is at TDC at specific crank angles. Which injector fires when depends on which injector bank they are connect to. |
You should check that TunerStudioMS reads approximately the correct barometric pressure when no vacuum is applied (i.e. the engine isn't running). Below is a chart of the 'normal' barometric pressures for various geographic elevations. your MegaSquirt-II™ (or MicroSquirt®) controller should generally be within 2 or 3 kPa of the value below for your elevation. Because of the increased accuracy of the 10-bit ADC on your MegaSquirt-II™ (or MicroSquirt®) controller, versus the 8-bit ADC of MegaSquirt® EFI Controller, the MAP reading will likely be 1 or 2 kPa higher with your MegaSquirt-II™ (or MicroSquirt®) controller. If it is significantly different, check under 'Tools/Sensor Calibration' and verify that you have values of 9.3 (@ volts) and 260.9 (@ 5 volts) for the MAP sensor.
|
Elevation Above Sea Level |
Atmospheric Pressure |
||
|
Feet |
Meters |
kiloPascals |
example |
|
0 |
0 |
101.33 |
New York, Vancouver, Washington |
|
500 |
153 |
99.49 |
Dallas (435 feet), Detroit (585 feet) |
|
1000 |
305 |
97.63 |
Geneva (1230 feet), Kelowna (1129 feet) |
|
1500 |
458 |
95.91 |
Helena (1404 feet), Wichita (1290 feet), |
|
2000 |
610 |
94.19 |
Canberra (1886 feet), Las Vegas (2030 feet), Regina (1893 feet) |
|
2500 |
763 |
92.46 |
|
|
3000 |
915 |
90.81 |
Red Deer (2968 feet) |
|
3500 |
1068 |
89.15 |
Brasilia (3480 feet), Calgary (3750 feet) |
|
4000 |
1220 |
87.49 |
|
|
4500 |
1373 |
85.91 |
Banff (4500 feet) |
|
5000 |
1526 |
84.33 |
Albuquerque (4945 feet), Denver (5280 feet) |
|
6000 |
1831 |
81.22 |
Colorado Springs (5890 feet) |
|
7000 |
2136 |
78.19 |
Mexico City (~7200 feet) |
|
8000 |
2441 |
75.22 |
|
|
9000 |
2746 |
72.40 |
|
|
10,000 |
3050 |
69.64 |
|
|
15,000 |
4577 |
57.16 |
La Paz (13,169 feet), Mauna Kea (~14,000 feet) |
Note that weather stations usually report the barometric pressure 'corrected' to read as if 101.3 kPa was the 'normal' for your elevation. Do not expect these reports to correspond to what you get on MegaSquirt® unless you are at sea level.
your MegaSquirt-II™ (or MicroSquirt®) controller has the provisions for a second independent 'realtime' baro sensor. This will update your fueling continuously, which may be helpful if you are climbing the Rocky mountains or running Pike's Pike.
To add an independent baro sensor to your your MegaSquirt-II™ (or MicroSquirt®) controller, use an MPX4250AP (the standard MS sensor). Run leads from:
You do not use any caps or protection diodes. The baro sensor can be mounted to the top of the case, above the LEDs near the DB9. It should clear the MegaSquirt-II™ here, but not by much, be sure to check. You may be able to put it at the other end, if the flyback board is not in the way in your installation.
So if you have a 4 cylinder, and a spark every 180 degrees, you have an even fire. Almost all 4 cylinder engines are even fire.
However some 90 degree V6s, some V4s, and most V-Twins (usually motorcycle engines), as well as a few others, have 'odd-fire' arrangements.
For example, from 1978 to 1984, the GM V6 (200 and 229 cid) had a semi-even fire sequence, with firing intervals of 132°/108°. It is "semi" because the rod journals are offset, but not quite enough to make for even firing intervals. In MegaSquirt® terms, this is an 'odd-fire' engine, because the interval between firing can be either 132° OR 108° degrees.
Note that for release 1.000, odd-fire is only in the code as a placeholder, there is no code supporting it at this time.
On the 'EGO Control' page:
There is a bug in some older versions of the code for narrow band EGO only (more accurately, there is a 'misunderstanding' between MS-II and TunerStudioMS as to what the narrow band curve should look like). The bug doesn't allow the reported EGO voltage to exceed 0.41 Volts, regardless of the actual voltage. To fix it, set the EGO to one of the WB (DIY-WB, for example), press the OK button, and let the 1024 entries burn to your MegaSquirt-II™ (or MicroSquirt®) controller. Then shut down both TunerStudioMS and MegaSquirt. Then start them both up again and set the 'calibrate AFR table' to narrow-band - be sure to press 'okay' and let all the values burn - just because it is already highlighted doesn't mean you are done. Cycle MT and MS again, and EGO should work properly.
IMPORTANT NOTE: Do NOT burn tables ('Calibrate AFR Table' or 'Calibrate Thermistor Tables') on a running engine. Even idle is NOT allowed, because these tables ONLY exist in flash, so once a table is erased, there is nothing but garbage in there until it is re-programmed, one word at a time (which can take a few seconds). Until that reprogramming is complete, operating the engine is unsafe.
IMPORTANT NOTE: Do NOT burn tables ('Calibrate AFR Table' or 'Calibrate Thermistor Tables') on a running engine. Even idle is NOT allowed, because these tables ONLY exist in flash, so once a table is erased, there is nothing but garbage in there until it is re-programmed, one word at a time. Until that reprogramming is complete, operating the engine is unsafe.
Note that the wide band control algorithm does not use the constant step size controller algorithm that was previously used in MegaSquirt® EFI Controller, it now has a P (just proportional) control algorithm, since it gives much more reliable information than the narrow band sensor does. your MegaSquirt-II™ (or MicroSquirt®) controller computes the difference between actual and target AFR, then uses that to do what it thinks is the exact adjustment to pulse width needed to attain the target AFR. So, step size and events don't play a role at all and they are grayed out when the wide band algorithm is selected.
Note that after you select your EGO sensor type, you should go to the 'Tools/Calibrate AFR Table' dialog and select the sensor output curve.
For example, if you have a narrow band sensor, select that; or if you have a DIY-WB controller select that, etc. Then click on the 'OK' button and a file will be create and downloaded to your MegaSquirt-II™ (or MicroSquirt®) controller that indicates the corresponding air/fuel ratio for various sensor/controller output voltages.
You can also create your own custom table by entering two point on the output curve.
There is more information on how to use these settings while tuning in the Tuning section.
IMPORTANT NOTE: Do NOT burn tables ('Calibrate AFR Table' or 'Calibrate Thermistor Tables') on a running engine. Even idle is NOT allowed, because these tables ONLY exist in flash, so once a table is erased, there is nothing but garbage in there until it is re-programmed, one word at a time. Until that reprogramming is complete, operating the engine is unsafe.
Before starting your engine, you need to populate three types of tables: the VE table(s), the AFR table(s), and the ignition advance table.
However, if you already have a suitable VE table (from tuning with MegaSquirt® EFI Controller, for example), you can 'Tables/VE Table/File/VE Import' an 8×8 VE table. TunerStudioMS will correctly interpolate it and give you a corresponding 12×12 table.
So when you are in the table editor, and you do a VE Import, it will automatically interpolate from whatever size the VE table is in the file to whatever it should be in the controller. If you have a good working table in 8×8 MegaSquirt® EFI Controller, just 'VE Export' it, pop in your your MegaSquirt-II™ (or MicroSquirt®) controller and VE Import it. You are warned that this is happening, but other than that it's fully automatic.
The load and rpm bins are interpolated, thus maintaining their original distribution (if you have tight values down low, and big gaps up top in the old bins, that is obvious in the new ones). The table is then interpolated using the new bins with the same algorithm that MS uses internally (which is also used to place the "spot" on the 3D VE tuning screen).
This makes transition from MegaSquirt® to MegaSquirt-II™ much simpler for those who upgrade.
Note that you can export or import VEX files into any of these tables. Use the 'Table/XXX Table/Files/VE Table Import' to import them, 'Table/XXX Table/Files/VE Table Export' to export them. These are all saved in the VEX format, so be sure to give your saved files descriptive names. The table will import VEX files of different sizes and automatically adjust them to match the current table size.
|
You can get a base starting point for the VE table by using the 'Tables/VE Table/Tools/VE Specific/Generate Table' function of MegaTune, using the peak horsepower and torque figures for your engine. For timing, we don't have a generator written yet. The basic principles are to determine a maximum advance for your engine and work backwards from there with heuristics ('rules of thumb'):
We will use this to fill in the table at 100 kPa from 3000 rpm to the redline. From idle to 3000 rpm, we want the advance (@100kPa) to increase fairly linearly from the idle advance to the maximum advance. idle advance is really a matter of tuning, but assume 8° to 16° in most cases, with stock engines being on the lower end, and 'hotter' engines being on the upper end. So if we have a hot engine with 36° maximum advance and 16° idle advance (at 800rpm), the spark table might look like this for 100kPa:
100 16° 16° 18° 24° 28° 36° rpm 600 800 1000 1500 2000 3000Below 100 kPa, we add 0.3° per 1 kPa drop. So for example, if our total spark at 100kPa and 4000 rpm was 36°, the advance at 50 kPa would be:
and the advance at 45 kPa and 800 rpm would be:
However all of these would need to be tuned, and it often helps idle stability to limit the advance at idle to under 20°. Finally, for boosted engines, you subtract 0.3° of advance for every kPa above 100 (it's not a coincidence that this is the same factor as for the 'vacuum' adjustments). Because 101.3kPa=~14.7psi, this works out to ~2° per pound of boost. It is often the case that you want to limit the retard under boost as well, typically so that it takes out no more than about ½ of the maximum advance at 100 kPa. None of these will give you the 'right' values for your engine though, and like the VE table calculator, are just a relatively safe starting point. They should be somewhat closer than starting with an empty table, though!
|
Advance numbers can be specified in tenths of a degree (1/10°)
Setting the Ignition Options
If you are not entirely sure about your ignition settings, check the supported list for the settings you should use:
If your module isn't on the 'officially supported' list yet, you'll need to understand the relationship between the trigger offset, the input capture (falling or rising edge), and the spark out (going high or going low). There are some tip on setting these parameters in the tuning section of the MS-II manual.
In the 'Settings/Ignition Options' dialog you can select the:
For example, with the 7/8-pin HEI or Bosch 0 227 100 124 modules, the 'trigger offset' in TunerStudioMS is:
First, the line of code that uses the prediction is:
dtpred += (inpram.Dtpred_Gain * (long)(dt3 - dtpred_old) / 100);
The Dtpred_gain value is the gain percentage read in (input in TunerStudioMS above). The dt3 variable is the just-computed time delta. The drpred_old is the last delta time value.
In our case here we control ignition, which then causes the crank acceleration. So we predict the point to fire, and when the spark occurs the crank gets the "kick" to accelerate.
So ... if we have two tach points it is possible to predict into the future with simple "last interval" derivative (compared to higher derivatives) since the change in crank angular velocity is caused by our ignition event. After the explosion the crank accelerates, but hopefully we get another tach input in order to build up a new time derivative to predict where to place the next spark event.
All of this excludes changes in crank angular velocity due to compression, load variations, moments of inertia, etc. And the ignition event and subsequent expanding gases are not an infinite, short step function impulse on the crank (look up mass fraction burned and Weibe function in Heywood).
But this does illustrate the "causality" of the whole crank position problem - you do not know exactly where the crank is positioned until you get the next position pulse event. At least to the positional error of the tach circuitry. After this point the position is just a prediction w/ associated prop error until the next pulse comes in...
There is a "hidden" variable () within the code that simply subtracts the last prediction from the current tach pulse update. In other words the code uses a derivative to compute when the next tach pulse comes in, then later on the actual tach pulse comes in. The error in this is simply the subtraction. See the line of code:
What this is doing is taking the current delta_t based on the latest tach update and subtract the previous delta_t value (dtpred_old). This value is multiplied by the current RPM and divided by 16667 in order to get the variable into degrees crank * 10. So the result is in crankshaft degrees, and shows the error in the last prediction compared to the current updated prediction.
The result is placed into the spare output runtime variable. Now this variable is not defined in the .ini file so it would have to be placed there. It appears after the egoV2 variable, see the runtime variable list in the code and correlate with the ini file. Be sure to note that it is x10 units. You might find it useful to put this variable in the gauge list and the datalog.
Now - some warning on this, since this variable can be easily misinterpreted without thinking what it represents. First, note that it will always be in error whenever there is an acceleration event. The MS code does not have a psychic code mod built into it (yet) so the acceleration event has to be sensed via the tach input stream. So there will be places where the last delta_t does not correlate with the new delta_t with acceleration/decel, and there will be corresponding error. This is why it is a good idea to place your ignition events somewhere close to a point where the latest update occurred.
Second, even with a steady state where the tach pulses are the same, like from the stimulator, there will be a slight error in the derivative calculation. The one thing we discovered from this testing was with high order derivatives that having the pulses the same was causing a little introduced error term. People who have had calculus know exactly what I mean. If the first derivative does not change (i.e. the tach pulses are the same time period) then the higher derivatives will be zero - there is no rate-of-change of RPM. The way the code determines the numerical derivatives is by using time periods, and the calc method was introducing a small amount of error in exact time periods. So if one monitors the prediction error variable they will note more degree jitter when there is no change in RPM (magnitude is less than a degree) for higher derivative use. To simmer down this effect Al has put a check in his (soon to be released) code where the higher-order derivatives are not applied to the calculation if there has been minimal change in tach pulse spacing.
Third, note that this variable represents the worst-case error. Its occurs at the tach update point so the time-propagated period error is the worst here. Remember you are (or should be) firing the ignition even before this point so the time-propagated error effect is less than this magnitude.
In my mind the proper use of this variable is to monitor it on a vehicle while trying the different derivative levels. The goal is to obtain the least degree deviation for accel/decel. The physics should be such that higher derivatives should help predict accel events better than simple last-interval calculation since it takes into account the rate-of-change in RPM over many delta_t intervals - but then there will be a greater error (overshoot) during the beginning and end of an accel/decel trend compared to the last interval. Datalog and compare to see what works best for you.
Again - if you use this variable then be sure to interpret what it represents in a proper manner. This is one of those numbers where someone sees a 5 degree crankshaft error and they then tell the world that "the code has a 5 degree error" without putting it into proper constraints. Now, if there is always a 5 degree error, then there is a real problem....
What the gain value does is choose (add in) between the latest calculated time delta (i.e. 0%), or use up to 100% of the last calculated time interval. This is known as a predictor-corrector, meaning you use the last calculated time interval, or a blend of this value (corrector) versus the predicted value of the time delta.
In pretty much all vehicle setups here we want to use the last hardware tach input pulse and use the delta time between this and the previous pulse. It is desirable to use the hardware tach inputs to generate the derivative prediction (i.e. into the future for when the ignition event needs to occur). This is the best information that we have and is better than blending this in with the previous derivative predictions.
This predictor-corrector is a very simplistic form of a Kalman filter. A Kalman filter can take many sources of input data, be it a running prediction or hard input data (with different, known error sources) and generate the absolute best prediction. The key here is multiple sources of input data with their own known error distribution.
In our case, we have one input source, namely the tach hardware input, and the assumption is that each and every pulse has the same magnitude error - nothing differentiates one tach pulse for having less error than another, they have equal error.
The default predictor gain is currently 20% (v2.36 release code), but will eventually be changed to 0% as new code is released. Originally the default was 20% because it gave a small improvement in simulation studies, but it appears to hurt more than help in the real world, so the latest code defaults this to 0%.
So - when would it make sense to try to use a gain setting other than zero? Lets say you are using a VR sensor and you are triggering off of both the rising and falling zero-crossing waveform. In one direction, the VR waveform transitions rapidly thru zero, which is the direction normally used in VR triggering - and this yields a sharp, deterministic transition point. In the other direction, the signal may not be as sharp vertically and there may be a indeterminate trigger point (this is easily visualized from VR voltage output traces). So, half of the VR triggers are really accurate, and the other 50% have jitter. So this case it may work better to use some of the running predictions in the final delta computation as opposed to 100% of the input VR triggers. Note that there are many factors involved. And to implement Kalman properly there should be a corresponding error sigma assigned - the accurate VR triggers have less error than the ones with jitter. And when acceleration/decel occurs (any angular rate-of-change), a hardware input tach is the only way to know this happened, previous predictions are not very useful (unless the hardware tach had positional jitter...).
For those interested, one of the absolute best (simplistic) descriptions of the Kalman filter is by Peter Maybeck - see the "Simple example" text in:
www.cs.unc.edu/~welch/media/pdf/maybeck_ch1.pdf
It is important to note that this is the input signal as seen by the processor. In typical applications, you will be running the input signal from pin 24 through the optoisolator (4N25, U4) which inverts this signal, so you need to use the opposite of what the sensor/module puts out.
For example, the GM 7-pin HEI module takes the variable reluctor signal, and generates a 'going low' pulse when the base advance point is reached. In this case, the 'Rising Edge' is chosen, as the signal 'going low' (i.e., falling edge) is used as a trigger, but this is inverted by the 4N25 optoisolator (or VR input), becoming the rising edge of the square wave at the processor.
If your are using the VR sensor circuit on the V3.0 main board, with the
For example, with a GM 7/8 pin HEI VR sensor, which gives a positive-going transition as a trigger (most, but not all, 4 pin HEI modules use a negative-going VR trigger), attached to the V3.0 main board VR circuit, you would set the ignition input capture to 'Rising Edge', which corresponds to the positive-going zero transition for the VR sensor.
Compared to V3 main board, the MicroSquirt® and the MS-II/Sequencer™ controller:
You should set the spark output such that no current flows through the coil when the rpm=0. To do this, replace the coil with an LED tester (see step #6).
Setting the spark output one way should result in the LED being off with no rpm - that's the way you want it. If It is on, the coil is flowing current all the time, and it will overheat, and the ignition module (or VB921 or BIP373) may overheat too.
If you are using the 'high current ignition driver' on the v3.0 main board to drive a coil directly, you need to:
If the max spark duration is too long, however, then the actual dwell value gets shortened at a lower rpm, limiting the spark energy at higher rpms. Typical values are between 1.5 and 2.0 milliseconds.
Dwell is the length of time the coil charges to make each spark. It has to be long enough to make a decent spark, but too long heats the coil unnecessarily. It is in milliseconds, since the time between spark is typically a few dozen or less milliseconds. For example, for a V8 at 600 rpm, the time between sparks is 25 milliseconds. At 6000 rpm the time is just 2.5 milliseconds.
A couple of points are that few automotive coils are designed for more than about 6-6.5 Amps, and reduced coil resistance has been used to shorten dwell times as engine rpm limits have risen over the years (shorter dwells means higher rpms before the dwell is cut back), so as a result most coils are between 2.0 and 4.0 milliseconds, with a general trend towards shorter times for more recent designs and longer times for older designs (wasted spark and coil on plug can be different, of course, as they fire less often and thus don't get cut back until a much higher rpm).
For example, the older 7-pin HEI coil uses 3.5 milliseconds dwell, the newer 8-pin HEI external coil uses 2.5 milliseconds of dwell. Note that times longer than 4.0 milliseconds would mean the dwell is being reduced at as little as 2500 rpm, meaning longer dwell settings won't make the spark 'hotter'.
MegaSquirt-II™ attempts to set up a charge/ discharge cycle that charges the coil for the specified charge time, discharges it for at least the specified spark duration time, and then remains in the discharge state until it is time to start charging for the next cylinder. At high rpm, there may not be time to fit in the specified charge + discharge times. In this case, your MegaSquirt-II™ (or MicroSquirt®) controller scales down both the charge (max. dwell duration) and discharge (max. spark duration) times proportionally so they just fit within the time between tach pulses.
Note that this is all to do with physics and the properties of inductors, and not related to the VB921 (which does have a current limit of ~6.5 Amps as well)
There are four ways to set the dwell:
T = (-L/R) * ln( 1 - (R * I / E))
Where:
To save a bit of calculation, you can enter your coil resistance, inductance and current in the form below and press the "Compute Dwell" button (for the dwell at 12 Volts).
In one case, the values for a 7-pin HEI large cap set-up with red/yellow leads are:
The values give a calculated time (T) of 3.45 milliseconds.
In the car, it was found that 3.4 worked, but it was set to 3.5 to be sure of an optimal spark under all conditions. At 3.3 or less, this set-up would generate some misfires, especially under 1000 rpm. Note that the 'full DC current flow' would be 12/0.4 = 30 Amps.
The current creates a magnetic field ("charging the coil"), and a change in magnetic field creates a current (we use that to make the spark). In order for the current to increase, it must increase the magnetic field. But if the magnetic filed is already saturated, the current can't increase (without wasting the same amount of energy as heat), so the current increases more slowly (and makes the coil hot). So typically you see a quick rise while the field builds, then a fairly suddenly change in the rate of rise (but still rising) when the field is saturated.
If you plot some values from the equation below (for the 7-pin HEI example) you will see this effect:
| Amps | Time (milliseconds) |
| 1 | 0.5238 |
| 2 | 1.0659 |
| 3 | 1.6278 |
| 4 | 2.2109 |
| 5 | 2.8169 |
| 6 | 3.4476 |
| 7 | 4.1051 |
| 8 | 4.7919 |
| 9 | 5.5106 |
| 10 | 6.2644 |
| 15 | 10.7091 |
| 20 | 16.9736 |
| 25 | 27.6827 |
Note that it takes 6.3 milliseconds to reach 10 Amps, but 17.0 (2.7x) to reach 20 Amps. Similarly, the coil reaches 6 Amps in 3.45 milliseconds, but takes 8 times as long to reach 4.16 times the current (25 Amps).
If the current was left to build, it would eventually reach the full DC value - if the coil didn't burn up first, of course. Note that the approach to 30 Amps is 'asymtotic', meaning it never quite gets there and you can't enter 30 Amps in the above example, you will get an error trying to find the natural logarithm. The magnetic field strength would not increase significantly though, and the spark would not be stronger.
To set the proper current limit for the coil, you can measure the voltage across R43 (with a scope, measuring the peak voltage at the top of the rise = peak current) and divide by R43's resistance (.01 Ohm) that's the current. For example, on an in-cap HEI coil and a dwell of 3.5 milliseconds, you would get:
1.9 division * 0.020 Volt/div / 0.01 = 3.8 Amps
This works well in the car. (It takes about 5.5 milliseconds dwell to reach the current limiting of the VB921 with this coil.) The way to set the dwell is to measure this current and set the dwell to the point at which the current reaches the 'proper value' for the coil (from the spec sheet, etc.). Now the hard part is knowing what the 'proper' value for the coil is. Some coils will have this listed as a spec (try Googling). For others, you might assume the correct coil current is between 3 and 5 Amps, though there's often little evidence to choose a figure like this. If you don't know the 'proper value' then you can use trial and error to determine it (next).
Note that you can not set dwell times with EDIS, the EDIS module does all the dwell control internally.
If you have a non-standard MAP sensor (i.e., not the default MPX4250AP), then you need to do a calibration under 'Tools/Sensor Calibration'. You need to set both the MAP and barometer sensor to match the sensor(s) you are using. Press F1 while in the sensor calibration dialog to see values for some common sensors. Do NOT change the barometric correction, just the MAP and barometer sensor. You may need to edit the TunerStudioMS ini files to show the full range of your sensor.