Real-time knock event recording

merchgod · **Joined:** Thu Mar 30, 2006 2:38 am **Posts:** 5336

I've been pondering a feature that I'm pretty sure I'll be able to implement. You've probably noticed the "knock signal #1" parameter that you can log. You might have heard that it is worthless to log because the snapshot of this parameter through logging is too slow to get an accurate idea of knock. What we can do, however, is add code to the rom to record this knock signal in a table in ram and not miss any of the knock events. This would be a 3d table of engine load verses rpm. Everytime a knock signal is present, the cell corresponding to the current load and rpm range would increment by 1. We could make the 3d table as large as we need (maybe about the size of the base ignition table) and allow the user to change the load/rpm ranges.

Once this is set up, all you would need to do is drive your car - no logging necessary. When you want to check out the knock events, simply hook up your laptop and read the table. Note, that this table is similar in concept to the ecu's fine learning table which adds or removes small amounts of timing across load/rpm ranges. However, this table is small and slow to populate (that is, not every knock event results in a fine correction). Our table will record all knock events, whether they result in fine learning corrections or not and will have greater resolution, giving you a better idea of where you are encountering knock and how persistent it is.

turbo022 · **Posted:** Tue Jan 16, 2007 4:28 pm

Sounds like a great idea! I dont like the fact that parameter we currenly have to log knock is sub par at best. The one thing that I really miss about having my UTEC is that when a knock event did occur it flashed the CEL. Maybe once a way to figure out how to illuminate the CEL we could incorporate this as well.

merchgod · **Joined:** Thu Mar 30, 2006 2:38 am **Posts:** 5336

Yes, it would be easy to illuminate the CEL upon the occurence of knock if I can figure out how to light up the CEL at will, which I haven't had any luck with so far.

NeverLies · **Joined:** Mon Jul 31, 2006 5:50 pm **Posts:** 47

Same here, no luck yet with the CEL ...

drees · **Posted:** Wed Jan 17, 2007 7:57 am

That would be a great tool to have in addition to being able to view the ignition learning tables.

Double Phister · **Posted:** Thu Jan 18, 2007 12:17 am

That would be one very cool feature. I use a knocklite so flashing the CEL isn't of much value to me. But being able to record the total number of events on a 3D table would be perfect for daily drivers.

Could you reset the table without a full reflash? Kinda like c0bbs reset ECU feature?

merchgod · **Joined:** Thu Mar 30, 2006 2:38 am **Posts:** 5336

Double Phister wrote:

That would be one very cool feature. I use a knocklite so flashing the CEL isn't of much value to me. But being able to record the total number of events on a 3D table would be perfect for daily drivers.

Could you reset the table without a full reflash? Kinda like c0bbs reset ECU feature?

Yes, since ram is cleared during a flash, the table would be cleared as well. After I get the new Ramtune code tested this week, I'll likely experiment with this next until we can start testing RamTune with RomRaider test builds.

tinywrex · **Joined:** Sun Feb 12, 2006 7:10 am **Posts:** 90

this looks interesting to me, MAF voltage limit check

Code:

 ais     #-2             ; Add Immediate Data to SP
ROM:0001AD04                 pshm    Z               ; Push Multiple Registers
ROM:0001AD06                 tsz                     ; Transfer SP to IZ
ROM:0001AD08                 bclr    3, Z, #0C0h     ; Clear Bit(s)
ROM:0001AD0C                 brclr   byte_2111F, #1, loc_1AD26 ; Branch if Bits Clear
ROM:0001AD12                 ldd     rMAFV           ; Load D
ROM:0001AD16                 cpd     fMAFVLIMITCEL   ; Compare D to Memory
ROM:0001AD1A                 bcs     loc_1AD22       ; Branch If Carry Set
ROM:0001AD1C                 bset    3, Z, #80h      ; Set Bit(s)
ROM:0001AD20                 bra     loc_1AD26       ; Branch Always
ROM:0001AD22 ; ---------------------------------------------------------------------------
ROM:0001AD22
ROM:0001AD22 loc_1AD22:                              ; CODE XREF: sub_1AD02+18j
ROM:0001AD22                 bset    3, Z, #40h      ; Set Bit(s)
ROM:0001AD26
ROM:0001AD26 loc_1AD26:                              ; CODE XREF: sub_1AD02+Aj
ROM:0001AD26                                         ; sub_1AD02+1Ej
ROM:0001AD26                 brclr   3, Z, #80h, loc_1AD48 ; Branch if Bits Clear
ROM:0001AD2A                 ldaa    byte_2153F      ; Load A
ROM:0001AD2E                 cmpa    byte_2B90F      ; Compare A to Memory
ROM:0001AD32                 bcs     loc_1AD42       ; Branch If Carry Set
ROM:0001AD34                 bset    byte_20208, #2  ; Set Bit(s)
ROM:0001AD38                 bset    byte_20004, #2  ; Set Bit(s)
ROM:0001AD3C                 bclr    byte_20028, #2  ; Clear Bit(s)
ROM:0001AD40                 bra     loc_1AD58       ; Branch Always

the BSET 3,Z,xxx is interesting, you will find it in other places where DTC checks are involved
and the BSET byte_20004,#2 is setting the actual DTC code in RAM

you must think in REVERSE! :lol:

merchgod · **Joined:** Thu Mar 30, 2006 2:38 am **Posts:** 5336

tinywrex wrote:

the BSET 3,Z,xxx is interesting, you will find it in other places where DTC checks are involved
and the BSET byte_20004,#2 is setting the actual DTC code in RAM

you must think in REVERSE! :lol:

I've seen the 0x20003, but it is only used on some of the DTCs. Also, the CEL is on when the test mode connectors are connected and the engine is running so we should see the same bit set in this circumstance, but a lot of those that I suspected by looking at the DTC thresholds are not used in that case.

Do you have scoobyspy ready? I really need something I can write to ram with. I've been testing now by having some test code clear or set a bit based on whether the defogger switch is off or on. But this is a PITA as I have to flash everytime I wish to try a different address.

TEREX · **Posted:** Thu Mar 01, 2007 7:32 pm

This sounds like an AMAZING feature! My evo friends all have knock sensor values in their logs that I am very jealous of. Instead, I get to infer it from timing corrections

-Cory

gabedude · **Posted:** Thu Mar 01, 2007 7:54 pm

+1 for the knock feature.

Hurricane123 · **Posted:** Thu Mar 01, 2007 9:24 pm

Being able to log knock would be great, especially stored in a 3D table .... excellent idea.

Also having the CEL flash would be super ... no extra hardware required.

Would this be considered equal in sensitivity and usefulness to a knocklink or other AM detection?

Jeff

gabedude · **Posted:** Thu Mar 01, 2007 9:29 pm

Hurricane123 wrote:

Being able to log knock would be great, especially stored in a 3D table .... excellent idea.

Also having the CEL flash would be super ... no extra hardware required.

Would this be considered equal in sensitivity and usefulness to a knocklink or other AM detection?

Jeff

It would be a better replacement for a knocklight even as it logs the knock events in a table as well as flashing your CEL. Great idea.

merchgod · **Joined:** Thu Mar 30, 2006 2:38 am **Posts:** 5336

I haven't done too much more with figuring out how to illuminate the CEL on demand as I'm waiting on way to write to ram without having to flash test code. But I was thinking about the knock event table and what might be useful would be to duplicate the fine learning stored corrections in ram at a much higher resolution. That is, when the ecu is writing changes to the fine correction table in ram, the value is duplicated in a much larger ram table with ranges of engine load and rpm whose midpoint would approximate the load and rpm axes on the base timing map.

ejsportcom · **Joined:** Thu May 04, 2006 2:53 pm **Posts:** 110

+1 for this logging feature

RomRaider

Real-time knock event recording

Who is online