RomRaider

How does c0bb do it? I've never had any issues editing the MAF/injector latency/injector scale on the fly with their setup.

That's because the ECU is always running the RAM tables, regardless with their setup. This would be similar to the version 1 in the OP. However, if we are going with map switching, we have the capability to switch to ROM maps at any time which isn't an option with the Cobb-type setup. The advantage to that is future on-the-fly map switching as well as dynamic table selection with version 3.

I think the only issue that could potentially occur if we don't switch to the ROM tables during a write, is a partially written table if the laptop/app were to lock-up in the middle of the write, cable gets disconnected, etc. This is probably why you don't hear any issues with Cobb's RT setup (although I don't know how their app handles these types of errors).

Actually it is an option with Cobbs Street tuner V1 sorta. All you do is select the realtime map or base map you want, and load it to while connected to the ecu. When you load either the base map or realtime map only the realtime tables (which Cobb has preselected for you ) actually take effect. Your base does not change in the ecu. Also I have noticed that even though the current target (cell) you are on in the map shows it is changed on the laptop. It does not change right off in the ecu. You either have to go above or below that target. Once you leave that target or cell the new values seem to take effect. There is nothing that tells you when the new values are applyed either. Exsample: You load a new map and you are currently at load colume .76 at 3600 rpm in the primary fuel table. Your old map had a target of say 13.0 and the new maps target for that cell is 14.0. You will run 13.0 until you leave that cell even thou it says 14.0. When you return to that cell it will then run the new maps target. Hope this helps Just wish I could do more.
Jeff

That would be more complicated and less user friendly than just temporarily switching to ROM maps.

Really, there are 4 options:

1. Revert to ROM tables during write.
pros: If base map is conservative/close to RT tune, this is a very safe option. Write failure would cause no issues and user could not force the ECU to run the problem real-time tune no matter what.

cons: If under load and base map is notably different, could result in a stutter (say injector flow scaling in base map is different) or possibly problems (say you pulled some timing in the RT tune due to knock, but left it in the base map). Requires user to make sure they have a proper base map installed.

2. Keep running RT tables during write.
pros: no worries about base map tune being different. Best for dyno tuning in some ways.

cons: a write failure could possibly result in a partially written table which the ECU would continue to run. Would rely on the user realizing there was a problem and taking action to reset the ECU/clear the tune (assuming the issue is a connection problem in the middle of a write).

3. Temporarily copy and run current RT table to be overwritten to "staging" area in RAM and only switch to new table when write is verified.
pros: solves the cons of #2/#3

cons: greatly reduces the number/size of tables that can be real-time tuned at any given time. Much more complex to set up.

4. Write changes a table a time and revert to the corresponding ROM tables a table at a time.
pros: partially solves issues with #1 as only the currently written table would revert to ROM values.

cons: potentially not as safe as #1 as if another table is overwritten inadvertently, the ECU would immediately run those values. A write failure relating to enabling/disabling individual tables could cause an unpredictable combination of running ROM or RAM tables.

Any chance of merch releasing what he did have working? Maybe if the OS scene made a large enough donation????