Nistune Forums

It never spikes in stream mode but always does in tuner mode.

The Datascan software does not show any spikes either.

I'm doubtfull another ECU will fix the spikes in tuner mode but may be able to try that soon.

if it only spikes in stream mode, then could be a random software glitch when wrapping around through reading the registers. how often does this occur? any conditions? I'll have to try and repeat it here

Also need a list of which consult registers you are reading, and a debug log so I can translate the raw data coming in. Strange problem

Seeing as i can never feel the spike id be looking at a software issue, as mine spikes to like 6700rpm and also drops right out to 0rpm, obviously if it was a cas issue the engine would stutter or hit rev limit seeing as my limters at like 6000rpm

AFAIK i cant repeat it, its random sometimes happens twice in row, sometimes not at all, did a log the other day in stream mode and didnt see any spikes

Might have two separate problems here

TheVlGuy - yours is a Type 1 board and uses our own USB consult implementation. Yours will always run in tuner mode but using different code which actually streams the registers from the ECU. The CAS spikes are likely to be hardware caused

nanook -yours is a Type 2 board and uses factory consult. Obviously the 'stream' consult which NissanDataScan and Nistune uses in stream mode is working okay, but when we manually cycle through reading the memory address of each consult register in Tuner Mode then CAS spikes are read? This is strange, if it never does it stream mode then appears to be a bug, but difficult to determine why hence the need for the logs

Cars off the road for another week after that I will do some fresh logs.
and supply a list of which consult registers I am reading, and a debug log.

Always have rpm spikes in tuner mode, sometimes have maf spikes most obvious ones spike to 0v

I finally got a log done and emailed that to you Matt.

Consult Registers are all ticked accept battery and Knock fuel flag

Thanks

can you do a consult log at the same time as debug log?

that way I can see the spike in the consult log and grab that timestamp and look at the raw input data on the debug log

trying to find in the debug log alone is like finding a needle in a haystack unfortunately. timestamps will help me locate it straight away

okay the spikes on CAS were triggered about 3100-3200 due to the consult MSB register being used and getting out of sync with the LSB register causing artificial spike. fixed in 0.9.14.1