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