Final Word On RB25DET knock sensors?

[Torque]

Hi,

what is the (current) recommended setup of the 2 RB25's knock sensors?

Disable one? Or use the 2 in parallel?

[Matt]

The best solution for reliability and consistency is stub them both out ...

1. KNOCK SENSORS

Okay from my investigations with the 16 bit Z32 ECU which use the same SR20 style donut knock sensors, I found it was flicking between knock/regular maps continuously on the bench with both hooked up

Different ECU hardware to the 8 bit but the 16 bit with same style knock sensors - they are too senstive. Same would apply but not so badly with 8 bit hardware, only keep one connected. The Z32 RB25 document in about v6 was updated (last year) accordingly in regards to only using one knock sensor

If you then find that with a single knock sensor connected the ECU is switching maps then stub out knock sensing altogether. We now recommend in the v7 document to stub both sensors out.

Now from the below was a thread on advising against using the Z32 ECU for RB25 based on Staos (Hypergear in Vic) experience using a Z32 16 bit ECU. We do advise since v2 of the Z32 RB25 document only to use 8 bit ECUs but Stao had a 16 bit ECU fitted, not by myself either
http://www.skylinesaustralia.com/forums ... __st__2140

This thead started from here when Stau used an unsupported 16 bit Z32 ECU. Therefore I was not aware he was using for an RB25 contrary to the postings people have subsequently made in the thread. The thread turns follows on into two further pages of arguing

In regards to tuning my only guess without further information was that the knock sensors were causing the ECU to change the maps accessed and pulling more timing and perhaps the maps were messed up in the ECU.

Lets get this straight it is not a nistune issue as much as an incompatibility between some Z32 ecu's and the R33 car itself, we have done about 20 or so (upto 400rwkw) and of those 20 about 6 give major headaches (r32 nistuned ecu worked so its not the cars), since i cannot differentiate the exact problems between ecu serials and r33 model series1, 2 or 2.5 i have stopped doing them, Stao's latest issues were the 16bit ecu.

The problem here is that I had no communication about these issues (email/phone) to run through the problem on the vehicles. The only indication was the thread and by then it was too late. Those that did have issues to rectify the problem before they went to the R32 ECU and Nistune instead

The solution here is to completely remove the knock sensors by stubbing them out to avoid consistency issues with tuning, and to ensure TPS is correctly set inside the software

2. DATA CORRUPTION (or lack of)

This is from the above thread.

I always get data corruption issues on the test car, and with the new illustration car it does all sort of random strange things and knock map is not responding to the tune. The test car goes onto the dyno every week so the data in it gets changed quite so often, I'm not sure if that causes the issue. I believe the boards or what ever the ecu its originally made for is ok. The Z32 ECU and nistune chip on R33GTST just didn't work probably on my cars. Which it's also the reason trent stopped doing those.

It appears from further questioning that Nistune on the PC is reading reading back the maps with spikes. This does not normally occur unless something was not being used correctly in the software. The boards do not have a tendency to corrupt unless the wrong address file was used or a different base image is loaded in. Only other corruption which is possible is electrical spikes from high spike sources such as cheap HIDs, high ignition coils etc getting into the ECU but that usually affects communications and running. Only then, performing a burn is necessary to make that permanent. This problem is low probability but on my list.

This is why we never went for battery backed SRAM boards to avoid this issue. Solution for this is to checksum the code area and verify the code area matches that before allowing the burn.

3. TPS SENSOR (S1 RB25 only)

From customer 4 Apr 2012:

More people have problem with idle speed engine ones run correctly AFR is good next time to rich AFR going to 10. when engine going to idle speed more time stabilize idle sped rpm.

The other problem with Z32 on RB25 is the lack of a TPS switch which the Z32 ECU expects and the RB25 doesnt have.

However the Z32 ECU like SR20s appears to learn the TPS idle position and adjustment of the TPS may be necessary. Checking inside Nistune the TPS idle/off idle indication over a series of starts will resolve this issue

Z32 TPS due to being self learning (also the ECR32 RB25 ECUs are the same after trying to patch that firmware last week) have extra code for enabling/disabling the TPS idle trigger.

HCR32 doesnt have this self learning code which is why the TPS trigger frimware works well with this ECU for RB25s

Perhaps investigating further and removing self learning all together could be an exercise, but if the self learning works and is reliable without the switch then those changes are not required. This is only applicable for S1 RB25 as S2 has a TPS idle switch

[Torque]

Hi there,

Thanks for that ..

I recall that issue Stao had, actually I exchanged a couple of PMs with him.
Also I know at least one person with the 16-BIT ECU and he has no issues.

As for the knock sensors the Z32 has just one of them, so using the 2 RB25's sensors might trigger false alarm.

I am inclined to disonnect just one sensor (the front one) as a test.

I do get switchovers to knock maps, and on the fly ignition retards. But I don't know if this
is due to real knock events or the ECU listening to ghosts.

I might do a test by setting up a map with very mild ignition advance and a A/F of 11 or so.
If I get knock detection I will disconnect one sensor and repeat the test.

Cheers ...

[Eric]

> As for the knock sensors the Z32 has just one of them, so using the 2 RB25's sensors might trigger false alarm.

> I am inclined to disonnect just one sensor (the front one) as a test.

As Matt writes, the R33 RB25 uses a different (newer) type of knock sensor.
It seems from many tests, these sensors are too sensitive for the Z32 ECU resulting in false knock detections.

The Z32 has an older type of knock sensor and unless you have the option to swap the knock-sensors on your car over for genuine Z32 ones, it's best to disconnect them completely and bridge the knock sensor pin on the ECU with a 1 Mohm resistor.

-Eric

[Torque]

Hmm ... that would be too bad.
I mean ridding the ECU of all it's elaborate protection routines by removing the sensors.

But thanks for the input I will try to source a Z32 knock sensor.

Are these sensors the same for 8 and 16 bit ECUs?

Also isn't it possible to tweak the ECU a bit by (un)setting the knock flags?

[Eric]

nissan partnr. for the Z32 sensor is 22060-30P00

it's the same for all years (and 8 bit / 16 bit)

[User_Name]

So is the best solution to just not use the knock sensors at all by adding the resistor or to bridge the pins between the two and only have 1 connected to the engine? This is my daily driver so ridding the knock sensors seems kind of "dangerous".

Thank You.

[Matt]

Knock sensors are used for two purposes
- Remove some ignition timing when a given knock count is monitored by the ECU
- Switch between high octane and low octane fuel and timing maps when different octane fuels are being used. This is particularly the case in Japan where you can run 100 octane fuel and lower levels so it then sticks to a particular map based on the fuel being used by using the knock sensors

If you properly tune the vehicle so that under high boost conditions you are not getting any knock (and then even pull additional timing to add an extra margin of safety) then you are removing the reliance on the knock sensors so can afford to stub them out. I've added the internal modifications required to the Z32 ECU to the latest Z32 RB25 guide on the website. 470k ohm are the resistance for SR20 knock sensors but upto 1 Mohm is reported to work fine also