RomRaider

This would be awesome.

I am tempted to learn to program just help out here! I want knock detection in a sweet, sweet 3D table! No logging required! Just dump the ram to a computer. That is beyond great--constant knock logging! But I'm thinking a n00bie programmer messing with RomRaider is like bringing the distruction I bring to my own engine to everybodies engine. Sort of like poorly tuning everyone's car....I think I'll stay away

Merch.... how accurate do you think the feedback correction is for tracing knock? I know it has a delay but maybe a snapshot of the first displayed negative correction would be close enough to determine the onset of knock? Or record all values less than negative 2 (just to filter out some phantoms)... I know my BOV from time to time will cause a negative correction. Its LOUD and kinda blows in the direction of the knock sensor....

I think if all 3 methods would give you a slightly different perspective on knock and would be useful in tuning. The problem is available ram. You couldn't run all 3 and RamTune as well. Perhaps a special RamTune version that only allowed the Base Timing or Timing Advance map along with the knock event recorder would work. Here's 3 ways the knock recorder could be implemented (all 3d tables rpm/load):

1. Feedback correction - records the max feedback retard in a 3d table. Disadvantage would be that you wouldn't know how many times the correction had occured. For example, you might see -2 in a particular rpm/load cell, but was that applied once or 50 times? The delay might also show feedback correction in adjacent cells if your load and/or rpm was rapidly changing at the time of knock.

2. Knock signal - This would increment the memory byte by 1 in the corresponding rpm/load cell whenever the knock signal was set. This would indicate reoccuring knock and would solve the problem with #1, but it would not indicate the relative duration of the knock as #1 would.

3. Fine correction - duplicates the fine correction values in a larger table in ram. This would give you an idea of the relative lack of knock in partciular areas in addition to knock prone areas. Probably the most useful by itself, although there are number of conditions that must be satisfied before fine correction values are changed and its hard to say how complete the picture would be.

Is the space issue in the ROM an issue because of the added processing code for doing all 3 or is it an issue because you would not want to have 3 tables? Maybe a combination of of #1 and #2 as a compromise would work? Use the byte in the table as a bit mask. First 5 bits describe the knock count and last 3 tell you the average correction in this location. Since you know what the count is in any particular cell, you can adjust the average everytime it is "touched" based on current knock correction. That would mean that each cell could only record up to 32 knock counts and the max average correction recorded would be 8. Or, instead of average, record the max. Am I way off on this?

Yeah space in the rom is always an issue. Plus there's only about 1kb of ram to work with. That is already just barely enough for effective real-time tuning. So, some kind of custom RamTune setup for this would have to be done - probably used temporarily by users and only allowing for Base Timing as an RT table. The Base Timing table takes up about 300 bytes. So, you could have 700 or so to work with. The axis ranges would not be stored in ram, so you only have to deal with the data. So, these 3 tables (8-bit data) would fit in a ram, but the additional code would be a problem for some roms.

I was thinking that an easier way would be to simply have the ecu write the fine correction table to our unused ram while upsizing it and change the axis ranges. This would require no additional code and only 64 bytes of axis data. This might actually give us a more accurate picture as the ecu will not advance fine correction in a particular cell consecutively. However, if someone has a detonation problem outside the range of rough correction, the increased resolution of the fine correction table would not retard timing over the wider range of load/rpm as it did before.

Ok, although not always active, much slower, and much less accurate probably, whats to stop us from doing this on the logger end of things?

Have the logger keep a running tally of knock events. Record load and RPM when knock signal is present, record load and rpm when feedback correction is present, populate a list. Also use the logged learning to populate a table with the highest learned values. I know its way slower and less accurate than doing it real time in the ECU but this might be a solution to have the functionality and not use RAM but still record real time knock events for the most part..... ??

Logger transmission rate is not fast enough to track the knock signal making it essentially worthless to log. It might also miss feedback correction at times if that were a loggable item.

The feedback correction seems to stay around for several logger cycles after the onset of knock, so I think thats definately possible to capture with the logger. To interpret it fully will be another challenge. I do agree about the knock signal, but if the functionality was there I'd grab it when it does get seen by the logger just for some additional data. Its definately by no means spot on accurate but it seems like it would be helpful from what I've seen out on the road so far.

Hey merchgod, is reading the ignition fine learning tables as simple as reading from the appropriate address range from the ECU? I'm itching to get some sort of historical knock feedback and figure that adding an interface to the logger that lets you read/display 2-d tables and the ignition learning tables from it would be a good start since it doesn't require mods to the ECU code itself.

Yes, it is that simple. Although, it should be represented as a 3d table. So, for simplicities sake, let's say the fine correction columns (load) table was 1.0, 2.0, 3.0 and the fine correction rows (rpm) was 1000, 2000, 3000. Let's say that the fine correction table starts at 0x0 and each correction is byte sized. If the ecu decided to make a fine correction change, it would first compare rpm against 1000. If rpm was less than 1000, then the row value would be 1. If it was >= 1000 but less than 2000, then the row value would be 2. If it was >=2000 but less than 3000, then the row value would be 3. But, as you can see, if rpm >=3000, the row value would be 4. The same is done for load. The row and column values are multiplied and the value is stored at fine correction start address + (row value * column value). So, it is a 3d table with load and rpm as the axes. But these are ranges, so it would be a 4x4 tables, not a 3x3 table. Example 0-1.0, 1.0-2.0, 2.0-3.0, 3.0+. If you could set it up to read the fine correction rows and column table in rom, it would be more useful.

For the 16-bit ecus, it is 64 bytes long (8x8).

bumping a great idea here!

i used to use a utec and i miss knowing when the knock is occurring on a regular basis from the CEL flashing, if that could be added it would be great. otherwise i may look into whats involved to add a knock light.

and further, the idea of logging when knock has occurred would be great. i was actually just talking about logging difference between RomRaider that i use and a friend who has a cobb streettuner and his setup did seem a bit more straightforward and easier to make sense of in places. one of which was a knock table he can reference just like whats being discussed here, and it sounds like a great addition to RomRaider.

possible addition with ramtune? and any word on this wonderful next release thats on the horizon?

The table that you see in ST is the fine learning knock table is what you are individually logging in RomRaider when you log 'Fine Learning Knock Correction', so that is nothing new and it is a feature of the factory ECU, not something that was added. RomRaider's logger doesn't support displaying all the values in table format, although I imagine that is something that could probably be added in the future. The problem is that fine correction is determined and applied across fairly broad rpm and load ranges so it is not as useful as you would think it was in determining past knock, at least with any precision. The ideas in this thread were to hack the rom to record knock events without the need to be actually logging and to more closely pinpoint where the knock occured.

Pulling down the learning tables would be pretty awesome.

Maybe I need to start learning some Java.