Looking at one of Andy's graphs shows a well tuned engine obeying the thin curve rule, but with multiple different AFRs along the way -- AFR doesn't just ramp cleanly up the curve. One of the other graphs had a rainbow effect as you looked along the curve, but that's because the colour and y axis were both %Duty.
So in the end, we just have to trust that the tuner has entered a reasonable AFR table. The software (probably using least squares) aims for the middle of the GEGO adjustments so there's a balance between + and -. The 2d AFR table is critical to the tune so this ends up behaving much more like VEAL than I had pictured earlier. All the same, it will be updating stripes of the VE table, and that has to converge on a decent tune much more quickly than VEAL.
Ryan: At this stage my plan is only to write tuning software; the firmware will behave exactly as it does now. I'm pretty sure the tuning software will need to allow for dead time when it calculates Duty% from PW. The basic autotune style flow I have in mind is:
- poll MS for variables
- display variables graphically and save to log file
- accumulate MAPxRPM, GEGO, PW (converted to Duty -- basically (PW-deadtime)*RPM [probably worth including nsquirts/alternating in case they get change]
- work out which control point(s) are affected by that MAPxRPM value and update their cumulative GEGO error value
- once a point's cumulative error gets above some threshold, calculate new Duty and derive VE values for all cells affected by that control point; send them to the MS. The VE would be derived as in the Perl script I posted earlier.
Rob.