spikes or surges while logging (hptuners)
spikes or surges while logging (hptuners) basically, i wanted to see if anyone knew what this was or is this normal with hp tuners.
LEts say i start loggin and i have the chart display open or any other chart. Ok, im logging fine and then, i get this spike that affects al fields. Meaning, every parameter just spkes either p or down to the max levels and its very brief. Not a long hit but as soon as you see it, its gone. Also, sometimes there will be multiple spikes back to back but i have only seen three grouped together. It happens very eratic, cant seem to see anything that corrilates with the spikes....
does anyone know or has seen this? IS this caused by a short in my wiring or is this normal?
thanks
LEts say i start loggin and i have the chart display open or any other chart. Ok, im logging fine and then, i get this spike that affects al fields. Meaning, every parameter just spkes either p or down to the max levels and its very brief. Not a long hit but as soon as you see it, its gone. Also, sometimes there will be multiple spikes back to back but i have only seen three grouped together. It happens very eratic, cant seem to see anything that corrilates with the spikes....
does anyone know or has seen this? IS this caused by a short in my wiring or is this normal?
thanks
Probably packet drops, sometimes the bus is very busy
and sometimes it isn't, I think comms settings may have
to do with this and I know for sure, slow hardware does
(I have machines as slow as 100MHz and they do this a
lot while 266MHz does it only occasionally and my "good"
600MHz machine, not at all). On the 100MHz PC and
earliest software versions I used to be able to reliably
(heh) make it drop comms altogether by going WOT.
I always log with just the table view open, that also
cuts down on the processor overhead / real time event
response (like serial packets showing up) latency I think.
and sometimes it isn't, I think comms settings may have
to do with this and I know for sure, slow hardware does
(I have machines as slow as 100MHz and they do this a
lot while 266MHz does it only occasionally and my "good"
600MHz machine, not at all). On the 100MHz PC and
earliest software versions I used to be able to reliably
(heh) make it drop comms altogether by going WOT.
I always log with just the table view open, that also
cuts down on the processor overhead / real time event
response (like serial packets showing up) latency I think.
Also, sometimes the PCM needs to address a certain issue with other control modules, so it will show up like a dropped cell. Say for example the BCM needs the PCM "attention", the PCM drops what it is doing to tend to the BCM's issue. It could show up on the scanner if your lucky, or it might be something that the scanner can not log.
make sense. Initially, i thought, a dreaded, that tere was se kind of electrical problem. Though i shouldnt rule that out until im 110% sure, im gonna try just logging around with just one table and see what i find.
I believe my current laptop is within the gigahertz range of processing speed. Not sure, but the latency problem could be the problem. Also, flame throwing SS has a point and im gonna try a few setting changes to see if i can mazimize or actually minimize the amount of process occuring in the background when logging with hptuners.
Thanks, do you think, which i feel that it may have an effect, that the spikes may screwer the averages taken when logging for LTtrims for example? Since these spikes are recorded, i elt that im not getting an accurate reading when this i occuring.
I believe my current laptop is within the gigahertz range of processing speed. Not sure, but the latency problem could be the problem. Also, flame throwing SS has a point and im gonna try a few setting changes to see if i can mazimize or actually minimize the amount of process occuring in the background when logging with hptuners.
Thanks, do you think, which i feel that it may have an effect, that the spikes may screwer the averages taken when logging for LTtrims for example? Since these spikes are recorded, i elt that im not getting an accurate reading when this i occuring.
I get that problem too. Im on a P4 1.6ghz laptop. I get it almost everytime I scan, I get a full drop in most of my signals for a split second. Im just used to it now. But pisses me off when it happens on the dyno.
Dixit
Dixit
yeah, i hear ya!!! I tried just a one table at a time, closed all other applications without causing any runtime problems and i still the same spkes!!
Oh well, i guess we have to live with it. But im just bothered that these spikes get recorded and then must lter you original averages, meaning, though minimal, your numbers arent 100%. oh well, im just anl like that i guess!!!
Oh well, i guess we have to live with it. But im just bothered that these spikes get recorded and then must lter you original averages, meaning, though minimal, your numbers arent 100%. oh well, im just anl like that i guess!!!
