RomRaider

Has anyone had a look at how the knock control works ?

For example, what is the relationship between:

vBETAA
vBETAB
vBETAC
vBETAD
vBETACAL
vBETAW

etc. etc.

How is it determined that it's time to switch to the low octane trim map and how does it make the decision to switch back to the high octane trim map?

There are so many knock parameters in RAM. Which are the best ones to log? I know vKNCNT is handy but I'm also wondering what the best parameter to display current/live knock intensity (how badly it's knocking at any given time regardless of which bank or cylinder) and any other handy knock related parameters?

I still haven't managed to find the byte with the bfREGGAS (High-octane 0/ regular 1 judgement) bit in it with much confidence but I'm presuming this one tells you which timing trim map is currently in use?


Here are some more. Has anyone determined more detailed descriptions for some of these?

vKP - A knock index number by the frequency
vKS - Knock index number
vKSR - A former compensated knock index number
vRKS - Knock index number
fKNOCK - Knock flag
bvBETA - Knock control value
vBETAA - Knock control learning value
vBETAB - Knock control learning value
vBETAC - Knock control learning value
vBETACAL - In front of the limiter, the amount of knock control
vBETAD - Knock control value for the high-octane/regular judgement
vBETAW - Knock control value
vKDBIDX - Knock detection inside variable
vKDL - Knock frequency element
vKDLMON - vKDLMON
vKDLW - Knock frequency element
vKNCNT - The number of knock counts
vKNKSL - Knock slice level
vKNOCKCYL - A label for the monitor by knock judgement cylinder
vKP - A knock index number by the frequency

Also a parameter to monitor for current timing correction in degrees due to knock control would be great.

What is "knock advance"? A slow advance when on the low octane map to "test the waters" and slowly discover if the fuel has been changed to high octane?

I'm not sure what BETAA and BETAB are yet but it looks like these two values determine how much weight each has to influence BETAC:

mADVWA - A BETAA weight coefficient for BETAC
mADVWB - A BETAB weight coefficient for BETAC

Interestingly, ZB060 has 50% in each. 6Y303 and CF48D has 100% in mADVWA and 0% in mADVWB. VC264 has them the other way around.

The other important thing we need to do is get some control over where the knock learning takes place.

In my case, 95 RON is only advantageous over 91 RON at high load therefore the low and high octane maps will be the same at low and medium load. What I do not want happening is the knock control switching back to the high octane map if running regular fuel just because the car isn't getting driven to those high load cells where the differences occur at the time. I ONLY want the learning to take place at high load.

This may be what mTPCHK, mNCHK and mNCHKC are for?

mNCHK - Region A, B judgement speed

I wonder if BETAA is a learning value from a particular rev range and BETAB is the learning value from another, determined by mNCHK?

I've learnt a lot about the knock control over the past few days and most importantly, how my VC264 differs from other ROMs. Knock control isn't the first thing I've noticed over time where VC264 implements strangely complex extras that are not on other ROMs.

Where I was originally stuck was looking for mfREGGASI but VC264 does not appear to have it. I can see the checks on ZB060 but not on mine.

VC264 has an extra instance of each mMKLMRTR and mMKLMRTH map, 4 in total, all with identical contents. Which ones are used are chosed by bit 0 at 0x63d.

VC264 has an extra vBETAA and an extra vBETAB RAM parameter. The same 0x63d bit 0 determines whether just the 2nd of each is used or if all of them are used.

I'm thinking the 0x63d bit 0 is a switch to enable or disable separated knock learning for each bank. It is disabled.
Edit: 0x63d 0x1 (bit 0) appears to be mfFLNBRN (Lean burn). VC264 must have fully separate knock stuff for lean burn on and off.

vBETAA is the initial knock learning value in the RPM zone below mNCHK. vBETAB is the initial knock learning value in the RPM zone above mNCHK. mADVWA determines how much weight vBETAA has in determining vBETAC. mADVWB determines how much weight vBETAB has in determining vBETAC.

On VC264, mNCHK is 400rpm, mADVWA is 0% and mADVWB is 100% therefore it is set up to only use a single learning zone, vBETAB.

mREGJG "A weight coefficient for the BETAD calculation" - I'll look into this tomorrow night. I think this is probably one to determine vBETAC's weight on vBETAD. If vBETAD falls below mREGJL, fuel mode switches to regular (with regular trimming map). If vBETAD gets above mREGJH, fuel mode switches to high octane fuel mode (with high octane trimming map).

On VC264, mREGJG is set to 0. I think this is where Nissan have disabled the high/regular octane functionality in this ROM. Also mREGJL is set to -32 so it would need a lot of repeated knock to get to that. ZB060 is set to -5. On these engines, there is around 5 degrees between what 91 RON can handle and what 95 RON can handle so I will probably end up setting mREGJL to -5 and play with mREGJH to ensure it gets back into the high octane map fairly quickly after filling with 95 RON.


My car is currently tuned for 95 RON. My plan is to first put an appropriate trimming map in the regular fuel trimming map and leave the high octane one as-is then just drive the car and monitor bfREGGAS, vBETAB, vBETAC, vBETAD. If I'm getting negative values in vBETAB and C but not D and it does not drop back into regular octane status, I will increase mREGJG to 100% and try again. If vBETAD starts working but it does not go negative enough and does not drop back into regular octane status, I will change mREGJL from -32 to -5 and try again. I'll then fill the car with 95 RON and tweak mREGJH to make sure it returns to high octane status within 5 minutes or so of driving.


I still need to learn more about controlling where learning takes place, likely involving mADVN1, mADVN2, mADVTP1 and mADVTP2 as well as if the "knock window" in the timing trim map has anything to do with knock learning or only knock sensitivity. I do not want knock learning taking place in areas where the high and regular octane trim maps are no different to each other.

It turns out that vBETAC and vBETAD may be completely separate. I'm not sure what vBETAC is used for at all.

It looks like vBETAA and vBETAB are individually multiplied by mREGJG to create vBETAD. I can't make out if it takes the worst case of vBETAA x mREGJG and vBETAB x mREGJG and uses that for vBETAD or if it somehow uses both.

I think my ROM is at the point where I may not need to know any more about it and just use real-world testing and logging to make it work how I want it to. I still think the 0 mREGJG value is probably the only thing that Nissan used to disable the regular/high fuel learning functionality.

The car barely ever gets driven and is nearly full of 95 RON in it so I might unhook a fuel line and pump it into my other car so I can test this one with 91 haha.

Yea knock logic is quite complex with tons of undefined RAM parameters. I’d recommend datalogging vBETACAL, knock count, and vKSR (old, but the main representation of knock strength. Still trying to figure out proper scaling for vKS. Also, hopefully those are the right variables I’m thinking of haha)

Eventually I’ll step through knock logic, but it’s not a concern for my NA ZQ running 93 octane, so it might take a while. (Currently working on more fueling functions) But you’ve seen to done quite well on your own! Just wish I had more to share on the topic But basically watch your deviance from MBT. IIRC, vBETACAL is constantly calculated, but is only applied within the knock region. So if you notice a decent deviance from MBT when no other compensations are occurring, it’ll probably be the vBETACAL value. Z’s have wideband knock sensors with extremely sensitive knock strength slices, so Z’s really shouldn’t ever miss actual knock. (If my understanding is correct) But narrowbands might have more of an issue due to the added noise.

Thanks. So is vBETACAL just vBETAC but after a limit has been applied to it (if applicable) and it's the value that's applied to current ignition timing?

I'm guessing vBETACAL is generally only a negative value if in the high octane map and it can be negative or positive if in the regular octane map, but its positive value would be limited by the difference between the high and low octane maps so it doesn't advance past the high octane map value?

I haven't managed to find vKSR or vKS on my ROM. I can't find anything similar enough to anything on VC264 on ZB060 to make the connection.

I'm not sure how well separate high and regular octane modes would work with my engine because the difference between what 91ron and 95ron can handle (or already at real-world MBT) is only 4 degrees and only in a small window. Here is an example of both timing trim maps I intend to run and one showing the differences between the two (knock windows removed from view).

I think I've found these. Have you seen vKS values on a running RAM dump from your car?

I think I've got vKS_R#1 to vKS_R#6 which all 6 have huge 32-bit values where first byte is 0x80, 2 empty 32-bit spaces (reserved for 8 cylinders) then vKSR_R#1 to vKSR_R#6 with 6 very low 32-bit values close to 0 then another 2 empty 32-bit spaces reserved for 8 cylinder models. Is that what you have?

So vKSR_R#1 to vKSR_R#6 is effectively knock strength cylinder 1 to 6?

Yea that sounds about right. The vKS values should be massive, while the vKSR values are reasonable. But the issue is, vKSR is an old value according to the description. The knock RAM parameters are called weirdly and Ghidra f*** up a ton of the RAM parameters, so things are quite confusing to try and understand. But I've had no issues just using vKSR for knock strength. If the cylinder vKSR value exceeds the knock slice map value for said cylinder, it sets one knock count. At least, that's what appears to happen. Can't really verify because we're limited to THREE damn 32-bit RAM parameters thanks to the wonders of K-line. So I can't really log much of anything useful. Would be lovely to be able to datalog each cylinder's RAM values for knock slice + vKSR + vKS + knock count (single) and see whether vKSR is truly a delay and if so, how much of a delay it has. But for now, I'm going to have to eventualllly try un-fudging Ghidra's knock logic disassembly

I just presumed "former compensated" means it is a value that has previously been compensated rather than "former" meaning that it's been replaced by something newer.

I'm hoping to get an idea of the range between the maximum values seen during knock-free operation and the values of a fairly bad knock and hopefully just define them as 16-bit values in the two middle bytes of each vKSR for example. We don't need to see general noise values, nor do we need to see the difference between a bad and an extremely bad knock so hopefully limited minimum and maximum values by defining as 16-bit would be OK. Generally there are only one or two cylinders that have a likelihood to knock most easily and it varies between engines so once the two cylinders that are most likely to knock can be determined, just those two cylinders can be defined into unused CID 12xx CIDs as 16-bit values after determining which bytes to use to get a useful value range. I wonder if there are smaller rescaled 16-bit or even 8-bit values for knock strength per cylinder somewhere.

Really, there's nothing we can do that will be worth the effort apart from CAN-bus datalogging. K-line is just terrible for datalogging anything useful. At least, for someone like myself who actually enjoys logging massive amounts of data. MegaLogViewer HD makes sorting through immense amounts of data a breeze, so there's never "too much" data

Whenever CAN-Bus logging gets figured out, it'll certainly speed up disassembly tremendously. I have tons of unknown RAM parameters that aren't in the A2L that need analyzed, but just haven't been capable of testing out due to the garbage maximum packet size of K-line. I mean, I suppose I could take three unique datalogs of JUST three 32-bit RAM parameters per log and try figuring out how they relate, but this would sacrifice any sort of RPM/TPS/Load indicator in the process. So I'll take my full RAM dump and chill with that until further development can be made with CAN. Recently defined some of the first SID request JSR's, but I'm not very eager to dive into protocol nonsense.

Here is a log of one vKSR cylinder (the "loudest" cylinder) without any conversion applied.

https://datazap.me/u/bradsm87/vksrr2-lo ... =2209-3534

Here is a log of cylinders 1,2 and 5, logging the 3rd byte of each 32-bit value only. This gives plenty enough range, even when applying a formula to zero out all values above 200 to clear out the slightly negative signed values.

https://datazap.me/u/bradsm87/cylinders ... =5446-6744

The original 32-bit values are signed but the most negative they go is little spikes and they're around -20 on this scale at worst which is just noise. The highest values were 24 for cylinder 1, 45 for cylinder 2 and 25 for cylinder 5. Having a range up to 200 on this scale is still plenty. Edit: Actually big knocks would probably go big in both directions but it'll be easy to see where there is knock regardless.

The conversion in the A2L is X/256. That's handy because raw values using the 3rd byte only are already running this scale! Based on this log, mTSL being the threshold of this value to add a knock count looks right to me.

We could probably do away with the need to zero out the negative values by using vKS instead of vKSR but zeroing out the top values doesn't matter to me for now.