Finally understanding knock / detonation detection on ca18det

Nistune topics specific to the 6802 cpu

Moderator: Matt

Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Re: Finally understanding knock / detonation detection on ca18det

Post by Matt »

I am using the Z32 ECU for testing the firmware updates. I got it working with the Z32 ECU as far as collecting and reporting the knock information, which is good. I got it displayed in the last version of the software with using the updated knock reporting firmware

I also then decoded the R34 RB25 ECU (for my skyline) and was able to work out the similar knock routines and decode the knock information. This vehicle is required for my final testing, since it is difficult to simulate knock signals on the bench

So far in the Nistune software, I've updated the parameters to display extra knock information that I have collected. This part works (but is slow)

CA18 is an earlier uncommented disassembled ECU code is different again, so that reverse engineering etc has not started. I continue with what I have so far

The problem with the Z32/R34 ECU so far is the consult stream is not fast enough in its current format to report the knock sensor data fast enough for that knock sensor information to be useful...

Some of the existing parameters for FP1/FP2 were added as extra memory addresses (high gear flag, dwell pulse reporting, Add TPS, Flex fuel value, Fire/fuel/enrich/boost flex add values, boost duty). These are only available in 'tuner mode' since I read each memory address and then report it

Individual memory reads is currently how the knock information is being read out (17 additional memory reads)

So doing individual reads in tuner mode is slow, and the above is also not available in the standard Nissan Consult stream (which is usually a table of upto 40 registers, depending on which ECU)

A redesign of the Nistune protocol, and new consult tables are now required. Then also the software needs an update to use this. Then there is the other issue of where to put the table in the limited memory space of these ECUs

I've put together a design of a new consult address register table, and will store this in spare NVRAM space. The ECU will then read all the parameters in the address table, and put the values in another area of NVRAM. Then it needs to run through them all, and put them out of the consult lines.

I'm half way through this. The prototype code has been done, but there are issues with the firmware and I've got stuck with it, so moved on to other work (read: always busy). I need to get back to this one but need to also finish up the FP1.1/FP2.1 firmware testing for the SR20 models and then get back to this afterwards
Post Reply