Hey Guys,
Just a question, but since I have installed a Nistune board, it seems as though (well seems most evident) that the 02 sample rate has slowed down,as though it does not have processing time/power it use to have and sampling slower.
How much burden is the realtime output having on cpu performance of these old slow ecus?
Cheers
Nistune using cpu time?
Moderator: Matt
Good question...
The 6802 CPU only runs at 4Mhz, so each instruction cycle ~= 1 microsecond
NIStune firmware is injected into the factory ECU code and called on each CPU interrupt. These interrupts happen quite often (esp as your CAS spins around and triggers it)
It was noticed during development that if too much time was spent in the firmware code that this would have adverse affects on the ECU and affect injection etc. We were orignally pumping out the entire consult register table (16 bytes) over USB in a loop and this didn't affect the R31 but Bryant pointed out early in the project that injection was affected on Z31 and I found so here on the bench when running that code
It was because 16 bytes x loop cycle time ~ 90 cycles = 1440 cycles. This was a hell of a lot of CPU time to steal ... about 1.5 milliseconds!
Hence the consult stream command was introduced to my firmware. This would trigger one byte output over the USB bus each interrupt. This obviously decreases resolution of consult data pumped out over the USB bus but did not affect vehicle operation. There is no measurable notice in injection when the NIStune firmware is running now.
Regarding what you have reported, after some investigation tonight I've recalculated the lastest firmware times
(a) NIStune board, not connected to PC = 64 cycles
(b) Initiate a stream command (190 cycles) + first stream byte (118 cycles) = 308 cycles
(c) Subsequent stream bytes = 123 cycles
From that investigation, might be best to fix up (b) so it only receives the stream command from buffer ... which will reduce cycle time for 1 of 17 interrupts since it is a bit big
When do you notice the O2 affected. Is it only when the software is communicating or does it happen when not connected also?
How are you measuring the responsiveness of the O2 feedback? Is this from the LEDs in the ECU flashing the mixtures?
The 6802 CPU only runs at 4Mhz, so each instruction cycle ~= 1 microsecond
NIStune firmware is injected into the factory ECU code and called on each CPU interrupt. These interrupts happen quite often (esp as your CAS spins around and triggers it)
It was noticed during development that if too much time was spent in the firmware code that this would have adverse affects on the ECU and affect injection etc. We were orignally pumping out the entire consult register table (16 bytes) over USB in a loop and this didn't affect the R31 but Bryant pointed out early in the project that injection was affected on Z31 and I found so here on the bench when running that code
It was because 16 bytes x loop cycle time ~ 90 cycles = 1440 cycles. This was a hell of a lot of CPU time to steal ... about 1.5 milliseconds!
Hence the consult stream command was introduced to my firmware. This would trigger one byte output over the USB bus each interrupt. This obviously decreases resolution of consult data pumped out over the USB bus but did not affect vehicle operation. There is no measurable notice in injection when the NIStune firmware is running now.
Regarding what you have reported, after some investigation tonight I've recalculated the lastest firmware times
(a) NIStune board, not connected to PC = 64 cycles
(b) Initiate a stream command (190 cycles) + first stream byte (118 cycles) = 308 cycles
(c) Subsequent stream bytes = 123 cycles
From that investigation, might be best to fix up (b) so it only receives the stream command from buffer ... which will reduce cycle time for 1 of 17 interrupts since it is a bit big
When do you notice the O2 affected. Is it only when the software is communicating or does it happen when not connected also?
How are you measuring the responsiveness of the O2 feedback? Is this from the LEDs in the ECU flashing the mixtures?
-
RB30-POWER
- Posts: 62
- Joined: Fri Jul 20, 2007 4:43 pm
Ok,
Well this might clarify if its just my imagination or not, but;
When the pc is not connected, is the data stream still being outputted, I was under the impression it was?
I haven't really been datalogging yet, just driving my car last few days to work without pc connected and noticed that the narrow band 02 guage (10 leds or whatever) does not seem to be cross counting as fast/often as it was (from memory) before nistune board went in. (no other rom changes or mechanical changes to effect it)
But if the nistune software only uses the ecu cpu time when the pc is actually connected I guess it can't be slower sampling then it use to be?
Drivability seems fine otherwise and 02 mixtures etc in open loop seem consistant, just seems like closed loop, i guess this is where the ecu cpu is heavily used for constant changing of air fuel ratio to 14.7:1 in realtime.
I would hate to slow down the sample rate unnecesarily and have the datalogging or realtime data becoming laggy as a result of reducing data output rate.
I certainly don't have a complaint at this stage, just noting some observation points, but maybe its all in my head...
Regards
Mick
Well this might clarify if its just my imagination or not, but;
When the pc is not connected, is the data stream still being outputted, I was under the impression it was?
I haven't really been datalogging yet, just driving my car last few days to work without pc connected and noticed that the narrow band 02 guage (10 leds or whatever) does not seem to be cross counting as fast/often as it was (from memory) before nistune board went in. (no other rom changes or mechanical changes to effect it)
But if the nistune software only uses the ecu cpu time when the pc is actually connected I guess it can't be slower sampling then it use to be?
Drivability seems fine otherwise and 02 mixtures etc in open loop seem consistant, just seems like closed loop, i guess this is where the ecu cpu is heavily used for constant changing of air fuel ratio to 14.7:1 in realtime.
I would hate to slow down the sample rate unnecesarily and have the datalogging or realtime data becoming laggy as a result of reducing data output rate.
I certainly don't have a complaint at this stage, just noting some observation points, but maybe its all in my head...
Regards
Mick
I can test this out and confirm for you... I'll use the older revision board with a romulator and switch between stock ROM and NIStune firmware ROM.
Using a scope on the O2 sensor 0-1 volt line I can monitor the waveforms and see if they are affected (frequency of change) when the firmware is uploaded
The NIStune firmware on the board will use a little extra CPU time, even when not connected (64 microseconds per interrupt) but it is tiny compared to the total amount of code that is being run so I dont think it should affect things too much
FYI you can also log the O2 sensor output in NIStune to see the wave forms. Let me get back to you on this one...
Using a scope on the O2 sensor 0-1 volt line I can monitor the waveforms and see if they are affected (frequency of change) when the firmware is uploaded
The NIStune firmware on the board will use a little extra CPU time, even when not connected (64 microseconds per interrupt) but it is tiny compared to the total amount of code that is being run so I dont think it should affect things too much
I can monitor if there increased processing time affecting the injection alterations increased/decreased from the O2 calculationsA narrow band sensor has a non-linear output, and switches between the thresholds of lean (ca 100-200 mV) and rich (ca 650-800 mV) areas very steeply. The Engine Control Unit (ECU) tries to maintain a stoichiometric balance, wherein the air-fuel mixture is approximately 14.7 times the mass of air to fuel for gasoline.
FYI you can also log the O2 sensor output in NIStune to see the wave forms. Let me get back to you on this one...
-
GZ@hybridka
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
The cpu/adc sampling time shouldnt affect how quickly the narrowband o2 sensor responds, at least not directly.
I assume you have a basic lean/rich meter piggybacked onto the 0-1v signal? The narrowband sensor produces/manipulates the voltage itself, and the CPU/ADC just samples the voltage at its own speed with a dedicated channel (non multiplexed), without affecting the signal being sampled.
You are probably just thinking about it too much..... or perhaps the o2 element itself has gone through some changes (extra carbon buildup?). Its hard to trust a narrowband o2 sensor, invest in a wideband.
I assume you have a basic lean/rich meter piggybacked onto the 0-1v signal? The narrowband sensor produces/manipulates the voltage itself, and the CPU/ADC just samples the voltage at its own speed with a dedicated channel (non multiplexed), without affecting the signal being sampled.
You are probably just thinking about it too much..... or perhaps the o2 element itself has gone through some changes (extra carbon buildup?). Its hard to trust a narrowband o2 sensor, invest in a wideband.
I managed to get a slice of time to do some testing last night. there is no affect between
(a) stock ROM
(b) NIStune ROM (not connected)
(c) NIStune ROM (connected)
I measured with a digital scope and O2 cycle times varied between 0.5 - 1 second on average for all three tests.
Was kept in closed loop @ 2000rpm @ 78 degC
Took some photos of it too. Can post later on when I get them from the camera if interested
(a) stock ROM
(b) NIStune ROM (not connected)
(c) NIStune ROM (connected)
I measured with a digital scope and O2 cycle times varied between 0.5 - 1 second on average for all three tests.
Was kept in closed loop @ 2000rpm @ 78 degC
Took some photos of it too. Can post later on when I get them from the camera if interested
-
RB30-POWER
- Posts: 62
- Joined: Fri Jul 20, 2007 4:43 pm
Thats excellent guys, that the data output process is not effecting cpu operations at all.
The sensor is old, original one from my r31 daily driver. (took the new one and put into r31 for better economy)
I'll grab a new sensor for the VL tomorrow and see how it goes.
I'm really impressed with how nistune operates so far, did a bit of tuning on the weekend and had a bit of a fiddle, works real well. The logging cell graph is the best part IMHO. Makes it so easy to log, then trim the cells that need it.
I have a WB02 wideband sensor (techedge) in the car all the time in a second 02 bung, so don't worry about that.
Thanks Again.
The sensor is old, original one from my r31 daily driver. (took the new one and put into r31 for better economy)
I'll grab a new sensor for the VL tomorrow and see how it goes.
I'm really impressed with how nistune operates so far, did a bit of tuning on the weekend and had a bit of a fiddle, works real well. The logging cell graph is the best part IMHO. Makes it so easy to log, then trim the cells that need it.
I have a WB02 wideband sensor (techedge) in the car all the time in a second 02 bung, so don't worry about that.
Thanks Again.
-
RB30-POWER
- Posts: 62
- Joined: Fri Jul 20, 2007 4:43 pm
Put a brand spanker 02 sensor in today.
Crosscounts extremely fast now and keeps mixture approx 14.8:1 according to the wideband. (Before it was sloppy/slow and between 14.2:1-14-9:1)
It even enters closed loop earlier (low temp) then it used to. (Must wait for some voltage from 02 sensor, so it knows its warm, or old sensor was just intermittant in the way it worked?)
I'll do a data log and upload the pic of the crosscounting from the 02 sensor, will be a massive difference and waveform will look alot more uniform.
The ecu seems to have no trouble controlling the gtr (444cc) injectors as precisely as it did the standard injectors (259cc).
Just a follow up question, what does all the "bits" signify in the closed loop settings in the software and what is the master value for?
I always read that the 50hex value was the temp (in degC) that it entered closed loop operation?
If you convert it to dec=80, 80degC, (which some people say) it enters closed loop before that temp, so that can't be right.
Let me know if anything is know about the above (not that its all that important) just curious.
Regards
Mick
Crosscounts extremely fast now and keeps mixture approx 14.8:1 according to the wideband. (Before it was sloppy/slow and between 14.2:1-14-9:1)
It even enters closed loop earlier (low temp) then it used to. (Must wait for some voltage from 02 sensor, so it knows its warm, or old sensor was just intermittant in the way it worked?)
I'll do a data log and upload the pic of the crosscounting from the 02 sensor, will be a massive difference and waveform will look alot more uniform.
The ecu seems to have no trouble controlling the gtr (444cc) injectors as precisely as it did the standard injectors (259cc).
Just a follow up question, what does all the "bits" signify in the closed loop settings in the software and what is the master value for?
I always read that the 50hex value was the temp (in degC) that it entered closed loop operation?
If you convert it to dec=80, 80degC, (which some people say) it enters closed loop before that temp, so that can't be right.
Let me know if anything is know about the above (not that its all that important) just curious.
Regards
Mick