RomRaider

I've been using the standalone logging feature of my Tactrix cable and absolutely love the resolution it provides. Unfortunately, I seem to be having a problem logging Knock Correction, 1 byte at address 0x22. The value is always 63.5. I've confirmed that my conversion expression is correct and I know of at least one other user that has the same problem.

Here is the definition in Logger.xml:



At first I thought it might be a signed versus unsigned byte issue but that wouldn't make sense either. What am I missing?

I'm datalogging on an 08 STI. The other person I've been talking to has an 08 STI as well.

Thanks!

AFAIK, on 32bit ECU you log "Knock Correction Advance (4-byte)*". Is that parameter available to you when you start the logger?

Leslie


P.S. Are you using the very latest RR Logger Defs (HERE)?

Well, 63.5 using that conversion is h'FF. That's the SSM parameter. 0x22 isn't the actual address, just an offset used by the SSM routines to call a function that 'fetches' the actual value from RAM.

After looking at the 08 STi rom, 0x22 isn't a supported parameter, the SSM function just returns h'FF from ROM.

So, you'll need to use the following to get KC advance:


BTW, KC advance IMO is a pointless parameter to log. Keep it simple and use load/rpm to interpolate the timing maps, and IAM to calculate KC advance, then check it against Ignition Total Timing to see if any other compensations are applied.

If you're looking for an actual measure of the ecu correcting knock, the above will suffice, but FBKC is much easier to watch during a log as a failsafe.

Unfortunately, the ECU doesn't support reading of extended parameters (memory addresses) over CAN. Colby has a patch for ECUs to enable this but I'm still using Cobb AccessTUNER Race maps and logging with Tactrix standalone (or RomRaider for extended parameters.) Therefore only FLKC is available, not FBKC.

K-line is just too slow for me; CAN logging provides 12-15Hz (or more) sample rates whereas K-line is a measly 3-4Hz on my 08 STI. You can miss a lot with such a slow sampling rate.

I'm almost tempted to convert my map to ECUFlash, dial it in using Colby's CAN fix, then switch back to Cobb (for live tuning and real-time maps.)

Thanks for the info guys.