rusefi.com

a bit offtopic: do you know of any cheap clone of the newer version with integrated analog analyzer?

kb1gtt wrote:I believe you can set an input as a trigger, then the analyzer will record before and after that event by a certain amount of time.

I don't think it will be logging before that event (although that would be nice). Any proofs?

I'm back home and can do more testing tomorrow. I have a simple 2 channel digital storage oscilloscope and a 2 channel analog oscope. I can look at spark signals on the board, and maybe try to couple to the spark plug wires and look for weak sparks. Any suggestions on specific tests to run?

I may be off base, but it seems like instrumenting the rusefi firmware place to look at the problem in real time. Although doing that could change timing to move or change the problem.

I found this reference when looking for information on diagnosing misfires:
http://www.underhoodservice.com/tech-feature-detecting-misfires-in-obd-ii-engines

... Most engine control systems with OBD II monitor the speed of the crankshaft between cylinder firings to detect misfires. The powertrain control module (PCM) notes the relative position of the crankshaft via the crankshaft position sensor (CKP) each time a trigger pulse is sent to the ignition system. If the crankshaft does not rotate a certain number of degrees between cylinder firings, the change in rotational velocity indicates a misfire must have occurred.

It is feasible to instrument the timing code to detect when a misfire has occurred and log any relevant state to the sdcard?

I did a quick test with the DSO to capture the two igniter signals that are driven from the Frankenso board, rev'ed to about 3000 rpm sitting still. Here are more pictures when I was out driving before this and only looking at one igniter signal. It looks odd that the pulses are not constant height, and they ramp up or down.

Here is a video capture of a TS dashboard when I was sitting still, tried to rev up to 3000 rpm and hold.

[video][/video]

Varying heights of the pulses when zoomed that far out is likely a scope issue not a signal issue. Do you see this kind of variation in height when you zoom in?

Yes theoretically software should detect misfire but practically the firmware is not there.

I like that your idle is much more stable than the http://rusefi.com/forum/viewtopic.php?f=5&t=1047 but on the other hand you are really rich on idle and the AFR is jumping a lot at 3k - I think a better tune is needed before we look into anything. Better tune at idle and better tune at 3K

Have you tried autotune from a registered version of TunerStudio?

hm. now i see what a missfire is.
it's a pity you don't have MAP or MAF readings on your video. what is used in your config to controll idle (i'd check idle control pins with analyzer, as my ears tell me it looks more like if someone just adds and removes air.

Yes, been doing autotune, still learning how to use it. I adjusted target AFR's and got less rich now.

Worked on getting AC going since it's really hot here.
Jared, yes, the variation seems to show at faster scan times also. I'll look at it more after awhile, and try the analog scope.

Here is another video to chew on with better afr numbers, sitting still with AC on. (Thank God for AC)

[video][/video]

There is a blip in afr at about :30 that felt like a misfire. At about 1:20 to 1:30, I felt vibrations like running rough or else misfire, can't really hear it.

Suggestions welcome on things to try here.

Thanks @russion for the quick fix for the injector miss fix from yesterday. I tested it out and now idle is complelte smooth in my testing.

But, I'm still seeing hesitation when cruising at around 60mph, about 3000 rpm. Here is a sample of a test run. At time :10 to :20 there are a few "blips" in the AFR the correspond hesitation. This starts at cruising speed, 60mph, and seems happen when going up a hill, map value has gone up some. Any ideas?

[video][/video]

please post this log file

I've got the same issue. Could be too easy, but Andrey, did dou apply the fix in the debug or the release file? I'm running the debug and still hesitant at 3000rpm, even with the TURBO!! on

@ I am turning in the "Please post your logs" robot

Thommm wrote:Andrey, did dou apply the fix in the debug or the release file?

Same code & logic, only different compiler options. Really doubt this makes any difference especially with our simple trigger signal.

Thommm wrote:even with the TURBO!! on

please elaborate

russian wrote:please post this log file

Yes, sir.

I see RPM spikes with MAP spikes without TP spikes? Should not MAP change go together with a TP change?

I guess we need a shorter log which is more focused on the problem - this log has too much stuff on it. Turning the ECU on/off would reset the rusEfi SD card log.

russian wrote:I see RPM spikes with MAP spikes without TP spikes? Should not MAP change go together with a TP change?

I guess we need a shorter log which is more focused on the problem - this log has too much stuff on it. Turning the ECU on/off would reset the rusEfi SD card log.

Here are few shorter logs. Something is odd with the TP data though. It looks like TP values are not correct when the engine is running. On the first log I test out throttle range watching the gauge in Tunerstudio. With key on before starting, I can see the TP gauge move like expected from 0 to 100%. But after starting, the gauge only shows 0 to 2% or so, seemingly random low values. That was on log #045. The other two logs are on a stretch of road where I can cruise at 60 for about 3 minutes, and there are some small hills. Usually I can feel a few hesitations when accelerating through gears. After reaching 60mph at about 3000 rpm, there are usually a couple of blips, then smooth a little while. Seems like going up a hill is more likely to hesitate.

tomiata wrote:Usually I can feel a few hesitations when accelerating through gears...Seems like going up a hill is more likely to hesitate.

Engine load the common piece? Let me open the logs.

tpsinfo and analoginfo in console to troubleshoot TPS since that's easily reproducible while in the garage I guess?

Can you somehow correlate the log sections with the hesitation?

You are very lean for seconds sometimes but that looks usually while coasting?

I will drive my miata this weekend but it's pretty flat here. The only curious thing is these little RPM spikes.

Any chance for a laptop to record logic analyzer?

russian wrote:tpsinfo and analoginfo in console to troubleshoot TPS since that's easily reproducible while in the garage I guess?

Can you somehow correlate the log sections with the hesitation?

You are very lean for seconds sometimes but that looks usually while coasting?

I will drive my miata this weekend but it's pretty flat here. The only curious thing is these little RPM spikes.

Any chance for a laptop to record logic analyzer?

Some of the points of hesitation are noticeable as small spike in AFR.
In file rus047, time=266.9s, 307.2s, 309.3s,
Yes, lean sections are coasting down a hill. I don't have a logic analyzer, but I see they are cheap on ebay. I can get one but will be about two weeks since I'm going out of town.

TPS is reproducable, I'll look at it with console and send data.

tpsinfo and analoginfo in console to troubleshoot TPS since that's easily reproducible while in the garage I guess?

Console data for analoginfo and tpsinfo throttle closed, wide open, and closed again:

2016-06-30 20_59: EngineState: confirmation_analoginfo:10
2016-06-30 20_59: EngineState: analogInputDividerCoefficient: 2.50
2016-06-30 20_59: EngineState: WARNING: ADC: print input is not configured
2016-06-30 20_59: EngineState: ADC is not assigned for hip9011
2016-06-30 20_59: EngineState: ADC is not assigned for fuel gauge
2016-06-30 20_59: EngineState: TPS ADC1 slow PA1 adc=0.16/input=0.41v/divider=2.50
2016-06-30 20_59: EngineState: ADC is not assigned for pPS
2016-06-30 20_59: EngineState: CLT ADC12 slow PC2 adc=0.95/input=2.37v/divider=2.50
2016-06-30 20_59: EngineState: IAT ADC11 slow PC1 adc=0.92/input=2.32v/divider=2.50
2016-06-30 20_59: EngineState: fsio ADC4 slow PA4 adc=0.00/input=0.00v/divider=2.50
2016-06-30 20_59: EngineState: AFR ADC13 slow PC3 adc=2.50/input=6.25v/divider=2.50
2016-06-30 20_59: EngineState: fast enabled=Yes
2016-06-30 20_59: EngineState: MAP ADC6 fast PA6 adc=0.98/input=2.46v/divider=2.50
2016-06-30 20_59: EngineState: ADC is not assigned for A/C sw
2016-06-30 20_59: EngineState: ADC is not assigned for HIP9011
2016-06-30 20_59: EngineState: Vbatt ADC14 slow PC4 adc=1.28/input=12.25v/divider=9.55
2016-06-30 21_01: EngineState: confirmation_tpsinfo:7
2016-06-30 21_01: EngineState: tps min (closed) 56/max (full) 592 v=0.41 @PA1
2016-06-30 21_01: EngineState: current 10bit=56 value=0.00 rate=0.00
2016-06-30 21_01: EngineState: confirmation_tpsinfo:7
2016-06-30 21_01: EngineState: tps min (closed) 56/max (full) 592 v=4.33 @PA1
2016-06-30 21_01: EngineState: current 10bit=592 value=100.00 rate=0.00
2016-06-30 21_01: EngineState: confirmation_tpsinfo:7
2016-06-30 21_01: EngineState: tps min (closed) 56/max (full) 592 v=0.40 @PA1
2016-06-30 21_01: EngineState: current 10bit=54 value=0.00 rate=0.00


Throttle % gauge tracks correctly.

closed, then WOT, then closed - tpsinfo outout looks right. Was rusEfi console gauge showing the right thing?
Does TS gauge something different from what rusEfi gauge shows in same situation?
Heck, what does the LCD show?

So where is the problem if any?

Sorry, I posted that too quick. The rest of the story is when engine is running no tps changes for closed, open 5 to 10%, gauge does not move either:

2016-06-30 21_17: EngineState: tps min (closed) 56/max (full) 592 v=0.39 @PA1
2016-06-30 21_17: EngineState: current 10bit=54 value=0.00 rate=0.00
2016-06-30 21_17: EngineState: confirmation_tpsinfo:7
2016-06-30 21_17: EngineState: tps min (closed) 56/max (full) 592 v=0.39 @PA1
2016-06-30 21_17: EngineState: current 10bit=54 value=0.00 rate=0.00
2016-06-30 21_17: EngineState: confirmation_tpsinfo:7
2016-06-30 21_17: EngineState: tps min (closed) 56/max (full) 592 v=0.41 @PA1
2016-06-30 21_17: EngineState: current 10bit=57 value=0.23 rate=0.00
2016-06-30 21_17: EngineState: confirmation_tpsinfo:7
2016-06-30 21_18: EngineState: tps min (closed) 56/max (full) 592 v=0.36 @PA1
2016-06-30 21_18: EngineState: current 10bit=50 value=0.00 rate=0.00

Can you please do the same thing but with a multimeter and the wire going into the ECU? I am wondering if that's an electrical problem with the signal or a software problem with reading the signal.

This is weird. Looking at pin PA1 on discovery, since it is easier to get to, with engine not running I see voltage swing from .17v to 1.7v from closed throttle to open. With engine running, no change when pressing pedal. I need to check my wiring where I got 5v for the tps pot. I'm busy for the next couple of weeks and will check it after that.

I got a logic analyzer delivered today, and did a quick test tonight.

I see an injector miss in the time when I feel hesitations. See 2 missed pulses on injector 2.

Log file is large again, time period from this log is in this section of the run: On an earlier run, I caught a single miss on injector 1. It's a bit of a challenge to capture these when driving.

This is very valuable data, really appreciate the effort to get it!

Again we see individual fuel misses. It's not trigger synchronization that's good news, it does not affect spark that's good news as well. I wonder if I have not fixed the previous issue completely or if that's a different problem. I will go look into the differences between fuel and spark scheduling.

Ah damn it! The problem persists. Wonder if we should start a separate thread for this missing injector pulse issue?

I had a look in the code to see if I could see anything obvious...
In handleFuelInjectionEvent() there are a couple of error catches
Where do these warning get displayed/logged? Is it possible to check if either of those are being popped?

Dial0 wrote:Ah damn it! The problem persists. Wonder if we should start a separate thread for this missing injector pulse issue?

We should have a while ago, probably too late now

Dial0 wrote: Where do these warning get displayed/logged? Is it possible to check if either of those are being popped?

These were only going to the rusEfi console/rusEfi text log file. I've just added warningCounter as TunerStudio gauge so TS logs would now have the counter logger, same would be logged with rusEfi own on-board logging. Just the running counter, not the specific information on which warning was displayed. Now that I am typing this I will go add a field for last warning code, and I need to make all codes unique.

On the other hand suspect the issue is not there - that's because only one injection is missed, not both injections of the same engine cycle. Need to double-check with the code, but I suspect that invalid injectionDuration value would make both injections not happen, not just one.

I wonder if routing inj2 to something other than pe2 would help pinpoint the problem (may be switching with inj1?)

puff, thats an interesting idea! I am pretty sure firmware issue but why not.

Injection order does not matter this much especially with batched injection so Tom if you can ppease flip output pins in configuration. Just let me add last warning code into firmware.

How does swapping the injector pins help? I've seen the missed pulse happen on either one. See the 2 screen shots above.