MicroSquirt.com read only forum (Jan.15,2018)

Not to beat a dead horse (altho that would look funny) but those that haven't seen my log, this is the exact same thing for me - 32ms pulse width for one instant....

exact same thing for me - 32ms pulse width for one instant....

m0ntecarloss/wes kiser/mops,

Has anyone experimented with the input signal lag factors to see if this is related to spurious input signals that are too quick for the datalog to capture?

Lance.

I will try that. Just to clarify, high lag factor essentially equals no damping, and low lag factor equals alot of damping, correct? What is the "lower limit" as to how low you can take a lag factor without turning it into an unresponsive slug? I am mainly speaking of the map sensor, as I am using tps for almost nothing (map dot accel).

Wes,

Yes, that's right - low numbers slow the response, high numbers speed it up. 100% is no lag at all. There's more on this here: http://www.megasquirt.info/ms2/configure.htm#lag

It's hard to say exactly what is the threshold for too slow, but I'm sure you'll know it when you get there... Certainly in most cases 50% should be fine, and even considerably lower will probably work for most people, most of the time.

Lance.

lance wrote: Has anyone experimented with the input signal lag factors to see if this is related to spurious input signals that are too quick for the datalog to capture?

Lance.

No I apologize, I should definitely have experimented more before posting. I only get to play on the weekends and unfortunately the vehicle is not here for me to check this out. I'll post later if someone else doesn't get to it first. I had not thought about the lag filtering..

lance wrote:

exact same thing for me - 32ms pulse width for one instant....

m0ntecarloss/wes kiser/mops,

Has anyone experimented with the input signal lag factors to see if this is related to spurious input signals that are too quick for the datalog to capture?

Lance.

ah, you are tEh sHiZ !!!

i'll try it out tonite and see "huh" is going on
mind you... i never seen a spike on my datalogs
just at some rpm/map my engine oscilates between ~11 and ~16 afr for no aparent reason.... (with ego corr disabled... ego corr makes it even worse...)

oh, um.... abouther question.
I'm not using dual table, shich means that I use single table only. however in my logs PW1 and PW2 are different... they follow close together but often +-10% different.... is that normal ??? does PW2 have any meanign in my case (as i use single table only) ?

I tried a smaller lag factor, and the syptom didn't show up on the way home (but it did not do it frequently). My original map lag factor was 65, changing this to 40 made the car difficult to drive in traffic (map dot accel). I bumped it up to 50, and this felt fine.
Something else I tried was unplugging my map sensor, and seeing what happend (car off). The map spiked up to over 200kpa, and then slowly bled down to the 150 range before I plugged it back up. So this means any hardware problem that could cause no map signal could cause this. Because of the magnitude of the spike, the only signal that I think could cause it (as a response to an input) is the map. I understand this could be anything from my sensor ground to an interupt to the 5v vref, to anything in between.
I will keep the lag factor low and see if the problem stays away.
Again I reitereate I have not seen an input out of line, simply speculating that the only input that could shoot pulse width up that high is the map spikeing way high (enabling my max mapdot value, in addition to the obvious 200 plus kpa).

however, if you shoot outside your map (i.e. map higher than the highest map bin), i.e. when you unlug your map sensor... i'm not sure what happens then. i believe somebody mentioned that when you go off the map it will go into fuel overrun mode (same like when map is below the lowest map bin)...



can anybody confirm ??

It did it twice on the way to work today, so the increased lag factor didn't do the trick. Of course after I got the laptop powered up and burstlogging it didn't do it anymore. Also, if the moderators feel this is more of a troubleshooting issue, please feel free to move it.

I caught it again on a burstlog on my way back from a meeting. Everytime it is the same. Around 3000 rpm, and a pulse width spike to 32 ms. Again, I caught not a single blip in input data. I raised the map lag factor back up to 60, as dropping it made the car run bad and didn't seem to help. Would something to possibly try (just for diagnostics purposes), be to drop the maximum table value for VE at that point (to an unreasonably low number) and see if the magnitude of the spike changes? I understand that it is possible for these spikes to occur between logging samples, but I think it is a bit odd I catch the pw spike evertime, and never catch anything on the input. Thanks again.