calibrating AFR table

[boosted 89]

Just a question and hopefully not an issue.

I was having issues with the O2 sensor reading on Megatune (8 gauges on screen) until I went over the manual again
and realized I hadn't calibrated the AFR table. So I calibrated the afr table with the engine off(used innovate LC-1 default)
and clicked on OKAy..loaded up and tadda gauge reads my WB figures. I also have a WB digital gauge to determine if the values in megatune are the same..which they seem to be very close...here's the situation though...I was running the
vehicle at idle and was going over some of my inputs to megatune when I happened apon the calibrate AFR table and found nothing was reading in the display(thought it would say Innovate LC-1 default)so I clicked on the tab..drop down menu came up and I clicked on Innovate LC-1 default again and hit okay..did the same thing as last time and the megatune still showed my O2 reading on the O2 gauge. My question is (now that I reread the manual again tonight) did I potentially screw something up trying to reload the calibrate AFR table when the vehicle was running( I know I know..dumb a$$ forgot the warning)..or is it fine because I had already loaded it before with the car not running??

Thanks for the help.

Chris

If I did screw up...how do I undo my screwup?

[kjones6039]

Not worry!!!

There are some calibrations that should not be done with the engine running. I have calibrated the AFR many times with the engine running. Let's see what the experts say but IMO you have probably not hurt anything.

Ken

[boosted 89]

That would be a big relief. I finally got the car running well enough to take it down the street and all seemed well..I definetly need to do some tuning but it didn't stumble on acceleration , but lacked power for sure. Wide band also showed
pig rich at close to WOT and 15 psi boost..low 9's. Thanks for easing my mind.

Thanks
Chris

[Bernard Fife]

Chris,

The issues with burning while running is that to burn the flash memory, an entire block must be erased first, and then re-written. With flash, this is much slower than re-writing RAM. The net effect is that during the flash burn process, the table have no sensible numbers in them, and this could potentially cause the engine to run badly or even damage itself.

If the engine runs fine after a burn, then you can be confident there are no issues.

In case you are wondering why this doesn't affect the user settings when you burn them, it is because the controller keeps two copies of the user settings: one in RAM that is used directly by the code, and one in flash memory that retains the values in the power is shut off. Since the values used are always in RAM, and we can write individual values to RAM (and very quickly), the flash burn issue doesn't come up - it can proceed in the background without affecting the values the controller uses.

So the flash burn issue only affects the thermistor (CLT, IAT), O2 AFR table, MAF table,CAN outmsg tables which are not duplicated in RAM.

Lance.

[grippo]

So the flash burn issue only affects the thermistor (CLT, IAT), O2 AFR table, MAF table,CAN outmsg tables which are not duplicated in RAM.
Lance.

Right, and they are not duplicated because there is typically way less ram in EMS processors, so you have to save it for data that is really needed. The tables in question are large and they are not tuning tables, they are what they are, and should only need to be loaded and burned one time, as opposed to a ve table which you may need to tune for many days while the engine is running.