Real-time tuning revisited

02rexwi · **Joined:** Wed Jul 16, 2008 11:32 pm **Posts:** 324

Any chance of getting this going still?

samtron42 · **Joined:** Mon Feb 16, 2009 5:57 am **Posts:** 22

ok call me an idiot but umm i have to tell my idea to get it off my chest so people can yell at me LOL

#1 ideas on just soldering an added ram car in to add more ram to work with
#2 any ideas on getting a 32 bit ecu rewriting the code to be only 16bit with 16bit left over as a "ram"

i dunno i know people will bump but just tryn to help id love to see ram finally be launched already so we can put our foot up those ems guys no disrespect

nsfw · **Joined:** Thu Nov 23, 2006 2:23 am **Posts:** 2565

1) I think the RAM is actually on the same chip as the CPU itself. Not certain of this though.

2) It doesn't work that way at all... What you propose is not possible, and would not actually save memory if it were possible. Look at it this way - that would change the width of the data, but the storage requirements are based on length.

Also, it's my understanding that 32-bit ECUs already have quite a bit of free RAM. (I'm going to be investigating that in detail soon.)

wrxsti-l · **Posted:** Mon Jun 21, 2010 12:39 am

Surely a laptop is fast enough to hold the required info while tuning and then flash it back to the ECU?

Wouldn't it "only" need some custom code so that the car ran from the laptop under realtime tuning and from ECU after the flash was done?

I have no idea of the complexity involved, but wouldn't that work? Then if at anytime the laptop was disconnected during the realtime tuning, it wouldn't cause any problems, because it would revert back to normal operation running via ECU.

Just throwing out suggestions - sorry if they are not possible.

Also, what does the AP do for realtime tuning? We've already spent $200 on a cable and $200 on a wb02, I'm sure most tuners would be happy to spend another $200 on some type of device that allowed realtime tuning.

Leslie

nsfw · **Joined:** Thu Nov 23, 2006 2:23 am **Posts:** 2565

The basic idea behind live tuning is to have the ECU read certain tables from RAM rather than from ROM, which is a relatively small change. What you describe would actually be much more work.

Apparently (I haven't verified this yet) there is already code in the ECU that allows writing to any address in RAM via SSM, so this would not require any new hardware. Cobb could probably make Street Tuner work over an OpenPort if they were so inclined

.

Fiend · **Joined:** Tue Apr 24, 2007 10:49 pm **Posts:** 243

NSFW wrote:

The basic idea behind live tuning is to have the ECU read certain tables from RAM rather than from ROM, which is a relatively small change. What you describe would actually be much more work.

Apparently (I haven't verified this yet) there is already code in the ECU that allows writing to any address in RAM via SSM, so this would not require any new hardware. Cobb could probably make Street Tuner work over an OpenPort if they were so inclined

.

I've been thinking about this more and more. I personally am not overly concerned about map-switching and being able to run realtime maps. ECUFlash can flash my '08 STI in about 10-15 seconds, which is already a LOT faster than Cobb's implementation. I'm more concerned about being able to tweak maps for tuning purposes. For instance, AVCS tables, part-throttle ignition timing, injector scaling, etc would be much easier to tweak if they could be done in realtime.

From what I can see, the most likely spot to implement this would be to modify the PullxD functions such that they consult a LUT in RAM that contains a key-value mapping of ROM address->RAM address. When the function goes to look up the table values, it reads the address of the axis/data from the table header, checks the LUT to see if there is a live version of the axis/data in RAM, and then pulls the data.

I assume RAM contents are retained between ignition on/off cycles because things like the FLKC table, LTFT, etc are remembered, correct? This would allow us to create a utility that connects to the ECU, reads the livetuning LUT, then updates the utility's view of the ROM with the stored data. You could even dedicate a small section of RAM to a map name/version string for use by the utility. When the ECU is reset, the livetuning LUT will be cleared (I assume), and the ECU will default to the static table data.

I have a diagram that will better explain my thoughts, but I just have to grab some dinner.

praha-sti · **Posted:** Fri Jul 16, 2010 2:08 pm

That all sounds nice and dandy, and a lot of work!

What would be more helpful for me would be able to high-light real time tables in my ROM where there is knock (for example). You know if you do MAF logging, and then you do "update MAF" and the tables are high-lighted and changed (and you can see by real value or by %) ... seeing timing tables that way (pulled, how much) would be very useful as well.

In short, live tuning would be nice -- but better navigation/analytics would be more useful, for me..

My 2-cents. Whatever you do, I'm sure it will be useful, though.

merchgod wrote:

I've been pondering creating a standalone RAM flashing and patching utility in order to allow for real-time tuning without worrying about the future development as it relates to RomRaider. The utility would do the following:

Patch supported ROMs with RT code and map assortment that you choose (which user would then flash to ECU with Ecuflash)
When connected to the ECU, determine current map assortment and allow user to open a ROM file and flash the RT-equipped tables from the ROM file to ECU's RAM (thereby changing the RT tune).

This would allow me to create a RT tuning solution without coming up with an editor from scratch. You would simply use RomRaider to tune your ROM, save, then open that same ROM file in the utility to flash the corresponding RT tables to the car. Not as good as tuning it directly, but still should be useful.

Problem is, there's a number of different ways to implement the RT tuning functionality. Each has its pros/cons. Looking for some feedback:

Version 1 (static maps / no on-the-fly map switching)
ECU would always run off RT tables in RAM. Post-reset, ECU would copy corresponding RT tables from the ROM to RAM. Changing maps: User could select any assortment of 1D/2D/3D tables currently defined by the latest ECU defs (and a combo which would fit within the RAM hole) and utility would update their ROM for which they would flash with Ecuflash and then be able to RT tune from there. This version is similar to Cobb's setup with the exception of allowing the user to choose any assortment of RT maps.

Pros:

Allows RT tuning of any map (including 1D which would not be supported by other versions). Changes to map assortment require traditional flash.
ROM code is very compact and very straightforward (compactness relevant for 16-bit ECU which have limited code space)
Straightforward to user - no confusion on what tune is being run.
This version would be the easiest to develop the flashing utility for.

Cons:

No failsafe. ECU will always run RT tables from RAM. So, if RAM gets corrupted (from a bad write, for example), the ECU will continue to run those values and nothing can disable it except by flashing back to non-RT ROM with Ecuflash or resetting the ECU (which could be handled by the utility if it detects a problem but no possible with ROM code).
No on-the-fly map switching possible.
More difficult to test for bugs considering the number of tables added with 1D support.

[*]More time consuming (greater chance of bugs) in setting up for different ROM revisions.

Version 2 (static maps / on-the-fly map switching)
ECU has the ability to switch between RT tables in RAM and corresponding tables in the ROM. This could be done by the user on-the-fly (some combo of defogger switch/RPM for example), by the utility (user requested or if the app detects a problem with the RT tables), or by the ROM code (if it determines an error with the RT tables or post-reset). Changing maps: User could select any assortment of 2D/3D tables currently defined by the latest ECU defs and utility would update their ROM for which they would flash with Ecuflash and then be able to RT tune from there.

Pros:

on-the-fly map switching allows you to change between RAM RT maps and ROM RT maps as you drive (requires no laptop). You could have a economy tune and then switch to a performance map with some combo of defogger switch and something else while you are driving.
Allows for switching (by ECU or utility) to ROM map if a problem is detected with the RAM tables. Although this would only handle a narrow range of problems (checksum is too costly in CPU cycles to implement, plus issue with the partial write method of the ECU makes it impossible).

Cons:

Larger and more complicated ROM code.
Since we don't know how to flash the CEL, driver would not normally know when/if the ECU switched to ROM or RAM tables. "Base" ROM map would have to be conservative in case the ECU switches to it (due to an error). This could be confusing to the user (or damaging if someone put, say, a race gas map as their base map).
Take notably longer to develop for utility than version 1.
User couldn't add 1D tables to map assortment (only "injector flow scaling" 1d table would be supported and which would be added manually to ROM code).
Greater chance for bugs due to the increased complexity.

Version 3 (dynamic maps / on-the-fly map switching)
Same as version 2 except the user can change their map assortment at any time without flashing (using the utility).

Pros:

Same Pros as version 2
User could change their map assortment at any time (although if you remove a tuned RT table from an assortment, ECU would default to the ROM table).
As far as ROM code, not anymore complicated than version 2

Cons:

Same Cons as version 2
Development for utility would be more complicated than version 2 and take even longer.
May be confusing for users who may not understand that when they remove an RT map they tuned from the assortment, that the ECU then defaults to the ROM table.
May be overkill since you would still have to flash to make the changes permanent in order to move onto another assortment with what you done so far in the tune.
Reduces the size of our RAM hole which potentially reduces the number (total size) of allowable tables in the map assortment.

elevenpoint7five · **Posted:** Wed Dec 29, 2010 5:39 pm

wrxsti-l wrote:

Surely a laptop is fast enough to hold the required info while tuning and then flash it back to the ECU?

Wouldn't it "only" need some custom code so that the car ran from the laptop under realtime tuning and from ECU after the flash was done?

I have no idea of the complexity involved, but wouldn't that work? Then if at anytime the laptop was disconnected during the realtime tuning, it wouldn't cause any problems, because it would revert back to normal operation running via ECU.

Just throwing out suggestions - sorry if they are not possible.

Also, what does the AP do for realtime tuning? We've already spent $200 on a cable and $200 on a wb02, I'm sure most tuners would be happy to spend another $200 on some type of device that allowed realtime tuning.

Leslie

Just trying to spark some more interest in this by bumping the thread.

I like the laptop idea, but that is leaving a lot to chance if the laptop fails, no? I could be wrong, but I've had me laptops fail on me than ecus. There would need to be a fail-safe telling the program to shut down if it sees any issues. And telling the car to not look to the ecu, but rather the laptop, for instructions, might be impossible.

The idea of writing to the RAM area in the ecu sounds great. It's just a matter of writing code small enough in the ecu that will tell it to read the RAM or ROM tables. Then designing a program to write to RAM. I think it would be best to incorporate this into the existing RR logger so that we could still see what's going on in RT, rather than waiting until things close, then opening the logger and getting connected.

Ideas? Thoughts? People that want to help?

Andy

qoncept · **Posted:** Wed Dec 29, 2010 7:16 pm

I think querying a laptop via SSM is out of the question. The protocol isn't nearly fast enough. The data needs to be written to ram, and we need to find parts of the ram that have large enough unused blocks. And we'll have to do this per ECU revision. That's why we were basically going to forego older ECU revisions and just do the latest for each ECU.

CSXRT4 · **Joined:** Fri Apr 17, 2009 5:19 am **Posts:** 42

If available RAM is an issue I think I have a solution. You could set it up to tune sections of a table at a time. So for example the user starts a ramtune session and opens up the timing table. Romraider automatically creates 4 sections between engine load points. The user selects a section and romraider loads the ecu RAM block with its contents and sets a byte in RAM to tell the ecu which section is being ramtuned. The user tunes this section and selects a new section, romraider saves the .bin, loads the same RAM block with the new sections contents, and sets the RAM byte to reflect the new section. The ecu will revert to using the Rom contents for the previous section but you will be able to tune all 4 sections and then flash the changes to be permanent. Or you could just tune 1 section at a time and flash in between.

The RAM block could be a predefined area but would now only need to be 1/4 of the size of the table (or smaller depending on how many sections there are. Even though you lose your realtime changes in one section if you switch to another most people start conservative and tune more aggressively so it wouldn't hurt anything.

Fiend · **Joined:** Tue Apr 24, 2007 10:49 pm **Posts:** 243

There is no need to get that sophisticated (and therefore complicated) with the solution. There is more than enough space in RAM to host more than four large 3D tables and a number of smaller 2D ones.

Also, I'd NEVER trust my laptop to operate my car.

elevenpoint7five · **Posted:** Thu Dec 30, 2010 5:02 am

My biggest hurdle would be my lack of understanding of the 32bit stuff. The 16bit stuff I know pretty well, but the lack of space is a huge issue. Both in the RAM and the ROM areas. Is there anyone capable of writing a program like Merchgod was talking about in the first post that is interested in helping? If not, then this discussion is useless. I know I can't do it. The only programming experience I have is with Subaru ecus.

qoncept · **Posted:** Thu Dec 30, 2010 5:30 am

If you can make the changes in rims we can handle writing data to ram.

Here's the run down as I remember it:
- identify sufficient free blocks in ram
- define ramtune address in rom
- 1-byte switch in ram, 00 = use table in rom, anything else = use table in ram (to protect against lost data in a reset)
- determine which tables to support (dependent on free ram)

elevenpoint7five · **Posted:** Thu Dec 30, 2010 5:03 pm

Hopefully some of the 32 bit guys will get on board as well. It would be pretty easy to support a decent amount of tables for them. For the 16bit guys it might be a little more difficult. I would think KCA, WGDC, AVCS, and MAF scaling would be the 4 most important. Everything else could be setup in a base map and only need 1 or 2 changes. Any thoughts here?

qoncept · **Posted:** Thu Dec 30, 2010 5:08 pm

I didn't think any 16-bit ECUs had AVCS? I was thinking primary fueling would be a good table to have. Bill seemed to think it made sense to have a few different roms, each with a different set of RamTune tables depending on what you're tuning. For simplicity I think it would be best to avoid that if possible. What does Cobb give you?

RomRaider

Real-time tuning revisited

Who is online