settings for enrichments

[floppy]

Should you disable AE and GEGO while tuning the initial VE map?

I have been through several mods now and Megalog has been an awesome tool, I may not have made it to the light without it!!

Is there a different graph for WB o2?

Thanks (really!),Mark

[LT401Vette]

You should not have to disable Gego or Accel enrichment. MLV takes the approach of filtering records that have conditions that may invalidate the accuracy of the predicted values. This includes when specific Engine bits are set (Accel Enrich, ASE, Warmup), then also user selected conditions like RPM and MAP limits. If any one of the filtering criteria is met, that record will be ignored durring the analysis.

Accel enrich - Accel enrich log records are filtered and ignored by the VE Analysis engine.
So if you step through your log record by record in MLV, watch where you slammed your foot to the floor. The Accel indicator will be on, each of those records will not be used in VE Analysis, then continue steping forward the number of records you have WB delay set to +1. That is the first AFR value that will be used in VE Analysis after the accel enrich event.
With the WB delay set correctly, most impact of accel enrich inaccuracy will be ignored.
Also consider this, with Accel enrich on, there could be some residual over rich records, but if Accel enrich is disabled you have the same potential for some residual lean records. I think it is in your benefit to let VE analysis correct some of the impacts of accel enrich, if you really feel there is a section where accel enrich is causing excessive residual rich record, you should probably consider lowering your accel enrich for that area.

Gego - Gego is factored into the VE Analysis formula. Say the current table VE value for a single calculation is 50 and Gego is 110, 55 will be used as the actual VE value. If Analysis determines that it was lean for that record, the 55 value will be increased accordingly and added as a weighted recommendation. So by running with Gego on, you benefit by having both the ECM learned correction and the current O2 to use as input for correcting the table, instead of just the current O2 output. Having both is better, especially with a NB O2 sensor. So while I would recommend leaving Gego on with either a WB or NB sensor, I highly recommend leaving it on for a NB.

For the curious - The formula used for correction is in the MSGraph.properties file:

Code: Select all

AFR_recommendedCellValueFormula=(cellValue*[Gego]/100*[AFR(WBO2)+WBafrOffSet]/afrValue)+(cellInterpolated*[Gego]/100*[AFR(WBO2)+WBafrOffSet]/afrValue)/2

You can likely read through it an see what is happening, but a couple of key points:
- 4 VE table cells will be analyzed for every record not filtered.
- Each of the cells will be assigned a weight that is equal to it's contribution to the end interpolated VE value. This is the same weighting that is displayed as a tooltip when viewing a log file with your table displayed.

In the above screenshot the current record has
MAP=48
RPM=1325
This means the the actual VE value used will be interpolated from the 4 cells highlighed in yellow. The 45% in the tooltip above represents the weighting for the MAP=50, RPM=1500 cell. The total weighting for the involved cells will equal 100%



- Back to the formula, There are 2 primary approaches to calculating the optimal value being used and then averaged. By breaking the formula down, we can look at both components independently.
The Cell Value approach in the 1st section:
(cellValue*[Gego]/100*[AFR(WBO2)+WBafrOffSet]/afrValue)
Takes the specific value of each of the 4 cells and corrects it using Gego and AFR. In other words, if the record being analyzed appears 10% lean, a recommendation will be added to each of the individual 4 cells that is 10% higher, with the associated weighting.
For Example using the above 4 cell diagram, the top left cell value of 23 would have a recommendation of (23/0.9) 25.555 with a recommendation weighting of 0.35

--
The Interpolated value Approach for part 2 of the formula works a little different:
(cellInterpolated*[Gego]/100*[AFR(WBO2)+WBafrOffSet]/afrValue)

This uses the weighted interpolated value of the 4 cells as the seed value for all 4 cells. In the above picture, the weighted interpolated would be:
(23*.35)+(35*.45)+(30*.09)+(32*.11) = 30.02
So using this formula the correction for the record will be applied to the interpolated value (30.02) and that same recommendation will be added to all 4 cells with the cells contribution weighting. Using the same example of that record appearing 10% the top left cell would have an added recommendation of (30.02/0.9) 33.35 with a weighing of .35

--
Both of these methods were used alone in some earlier versions of MegaLogViewer and each method has strengths. The Cell value approach is maintains the cell relative value even when VE Analysis only views it from one side, meaning there are log entries where a cell is the top cell in the 4 cell interpolation, but no records where it is the bottom cell. However, the Cell interpolated approach aids in smoothing the table.
With the help of many in testing, I found a hybrid approach to work best. Thus the above full formula calculates each cell both ways and applies the average with the associated weight. This seems to give the benefits of both methods.

This formula is read from the MSGraph.properties file, so if you wish to experiment, you can edit it there.
applies the interpolated value to all 4 cells with the impacted weight

[floppy]

Thanks Phil!!

That is the same direction that I had been thinking but was looking for confirmation.

I will log with AE on and see how it handles a light throttle lean tip-in. I have been hesitant to work on AE on while trying to get the VE table set accurately.

Have you ever had the AFR table in VE ANALYSIS go to erratic settings? I thought that there was a problem with MLVV itself so i had not been using it and then I happened to go to the AFR table setting in MT (WB02) and found the setting were crazy, not only the AFR's but the KPA and RPM also?? Reset it and it has been working fine since.

While I'm asking Q's do I need to restart the datalog after I have saved and loaded the new MSQ?

Can I edit the code so that it will ignore the idle parameters? or maybe I need to ensure that the AFRsettings in that area are correct?

Thanks again, Mark

[LT401Vette]

Once you burn a new MSQ, you should start a new datalog, the old data will cause VE analysis to apply the same corrections to the already corrected table, so it would be wrong. If you don't use a new data log you can use a time filter to filter the part of the file before you burned the new tables, but that is too much for me to keep track of . I'd just start a fresh.

I haven't had the AFR table go erratic, it shouldn't. VE Analysis references the AFR table but should not change them.

Having correct AFR's at idle is a good start, but often you will make tweaks to the idle area that you do not want VE Analyze to change. You can set an Min RPM filter to avoid VE Analyze from looking at idle range data. One thing to watch here though:
Say you have VE Bins at 1000 RPM and 1400 RPM
You set the Min RPM in VE analysis to 1200 RPM

Even with the 1200 RPM Min, the 1000 RPM Bins can still be altered. The data log entries for 1200 RPM will be included in analysis and they would be interpolated values from the 1000 and 1400 RPM Bins, so the corrections will be applied to both.

The filters filter the input data, they do not filter the correction points.

If idle Bins are changed where you have them setup as you want, just multiselect the cells after analysis, right click and select "Revert to Previous"

By holding the mouse over any cell after analysis you can see what the original value was and how much data was used to determin the new value.

[floppy]

I'm covered on the idle filter, they are set at 600 and 1100 which is just where I would like it to stop.

I just updated to the new version, did you just add the filters? sounds lame but I may have not seen them on the monitor that extra runs on becuase I can't pull it up the page far enough.


What are EGT and the ports signifying?

My AFR will spike up to 21.99 for no apparent reason when nothing relevant seems to be changing except that portb and EGT seem to follow it quite closely???????? I'll send a log and an MSQ if you care to look.

It hesitates for a split second and continues on with no change in PW, RPM, MAP, TP, or TPACC.

So what would happen if you were to analyze a log taken while running autotune tried it and it seemed to work, the step and authority are both set to one. Would it progressively analyze with autotune?

Thanks Phil, Mark

[LT401Vette]

The filters have been there, but 2.52 changed the layout of the dialog so they wouldn't go off the bottom on low res screens.

EGT is meaning less if you don't have an EGT sensor & circuit. Port d is a set of bytes that indicate various things. They are defined in the msns-extra.h header file. For 29t:

Code: Select all

;Port A
;  PTA0 - FP
;  PTA1 - FIDLE
;  PTA2 - Output 2 (X5)
;  PTA3 - Output 1 (X4)
;  PTA4             X3
;  PTA5             X2
;  PTA6 - Flyback
;  PTA7 - Flyback

;Port B (ADC inputs)
;  PTB0/AD0 - MAP
;  PTB1/AD1 - MAT
;  PTB2/AD2 - CLT
;  PTB3/AD3 - TPS
;  PTB4/AD4 - BAT
;  PTB5/AD5 - EGO
;  PTB6/AD6 - "X7" spare, EGO2, fuel pressure or 2nd MAP
;  PTB7/AD7 - "X6" spare, EGT

;Port C
;  PTC0 - Squirt LED  or coil a
;  PTC1 - Accel LED   or coil b or HEI7 bypass
;  PTC2 - Warmup LED  or coil c or output 4
;  PTC3 } multiplexed shift { or coil e
;  PTC4 } light outputs     { or 2nd trig input

;Port D
;  PTD0/~SS - unused  or coil d
;  PTD1/MISO - nitrous in / table switch
;  PTD2/MOSI - knock in / coil f
;  PTD3/SPSCK - launch in
;  PTD4/T1CH0 - Inj1
;  PTD5/T1CH1 - Inj2