Strange Coil output behaviour

[unfgr]

I scoped the output of STM32F4 board in a variety of rpms and noticed that on coil #1 every other pulse the falling edge offsets by 0.4ms
the trigger is set as 12-3 and bellow i have some screenshots.
Have you noticed anythng similar?

As you see the dwell is varying by 0.2ms every other pulse for coil#1 only

Console ScreenShot

Console.jpg (440.41 KiB) Viewed 18465 times

2 Diferent Captures indicating the offset (time/DIV:2ms), previous and next pulse falling edges are allways rock solid!

Scope 1st Capture

capture1.jpg (262.68 KiB) Viewed 18465 times

Scope 2nd Capture

capture2.jpg (265 KiB) Viewed 18465 times

[AndreyB]

Just got home & it's around midnight here, consider this a preliminary response:

-1) yes, there are limits to what kind of load rusEfi can currently handle. but there was some work done investigating what affects performance and here are some hints in no particular order

0) compiler and debug/release matters a bit
1) at I know the trigger is just 12-3, but 9K is high and this plays a factor
2) having engine sniffer/sensor sniffer enabled matters a bit. performance could be better if those are disabled. could be better to disconnect console altogether.
3) probably the biggest one - signal simulation itself is heavy. for some tests, I run two discovery boards - one producing fake signal, another one running engine logic
4) another big one: index==0 currently has more calculations, that's why there are tricks like non-zero 'engineConfiguration->ignMathCalculateAtIndex'. Will add more comments explaining this parameter tomorrow morning
5) 'triggerinfo' command shows some metrics - which operation takes how many CPU cycles. try 'triggerinfo' and look for the variables it is printing at the end of the message

A better response once I wake up & get breakfast

[AndreyB]

New comments in the code:

Code: Select all

	/**
	 * At what trigger index should some MAP-related math be executed? This is a performance trick to reduce load on synchronization trigger callback.
	 * offset 1648
	 */
	int mapAveragingSchedulingAtIndex;
	/**
	 * At what trigger index should some ignition-related math be executed? This is a performance trick to reduce load on synchronization trigger callback.
	 * offset 1524
	 */
	int ignMathCalculateAtIndex;

to be continued

[unfgr]

All right, i managed to get my hands on a Logic Analyzer and scopping at 200KHz revealed some good info.
The RPM was set at a very high of 12k (the problem persists even on 1k rpm and scoping that high makes it possible to have a lot of samples with smaller memory amount), set on 4-cyl wasted spark, trigger custom 12-1

The problem of ignition offset every other pulse is verified and only happens on coil#1 (4,51ms<->4.89ms period)

One more problem (which i'm 99.9% certain has nothing to do with the previous problem) is showing to affect both Coil outputs, look at the last pulse of coil#3 (Channel 2 - 4,75ms) and the equivellent pulse on Coil#1 (next to last Ch1 - 4.93ms) they both offset by +0.04ms from the expected values (4,71ms->4,75ms & 4,89ms->4,93ms)

Logic Capture 200k

LogicCapture.jpg (86.52 KiB) Viewed 18398 times

*ps
Look at how coil#3 behaves at 12k rpm, isn't it beautiful????
As i said current code (and this MCU) can deliver the accuracy we need, it's just a matter of weeding out some bugs here and there,

[unfgr]

Update #1

Notice 1) the fact that there is no sync loss, so, every other pulse "steals" 0.2ms by the previous [or next] pulse, or maybe gives 0.2ms to previous or next pulse [assumption: coil#3 period of 4.7ms is correct]

Notice 2) it is always 0.2ms, no matter what rpm, if console or TS is running etc, that makes things easier....????

"Irrelevant" notice) Why measured crank cycle is 9.4ms and not 10ms?????

[AndreyB]

Why measured crank cycle is 9.4ms and not 10ms?????

I would start from here. You probably want 600 rpm or 1200 rpm (not 1000rpm) to have an even engine cycle duration. Disable self stimulation and look at the precision of trigger signal generation as the first validation step, Without all the coils and injectors, how happy are you with trigger simulation precision.

[unfgr]

How do i disable self stimulation?

[AndreyB]

disable self_stimulation command

[unfgr]

Something very strange is happening here......

I'm getting verified readings from logic analyzer and oscilloscope that crank cycle time is 9.7 - 9.8ms @ 6000 RPMs but both the console and TS are reporting exactly 6000 RPM.

Hmmmm, time to bring in JimStim and an Arduino as extrernal Stimulators

[AndreyB]

Here's how it looks here.
Neon03 config, rpm 1200

rpm 6000


'set_engine_type xxx' command fails for me now, too tired to troubleshoot at the moment. 'set_engine_type 26' is test_engine.cpp which is the simplest trigger purposely created for testing.

[AndreyB]

PS: do you change any parameters after rusefi reboot? Or do you have them saved in flash so that you can test right after 'reset' button?

[unfgr]

I'm saving the configuration to flash (through TS)

Going to try the neon trigger pattern later today

[RasPL]

I have same issue with 60/2 trigger and when ignition angle is set to ATDC (i.e -5deg) which is not a normal for petrol engine (if you have idle control by ignition angle that can happens)
When ignition angle is BTDC all is ok.

[AndreyB]

I am not sure if this is a performance or functional issue, but I am now able to reproduce it as well.

With just 600 rpm I suspect that this is a functional bug and not a performance one. Now the fun of fixing it

https://sourceforge.net/p/rusefi/tickets/229/

[RasPL]

same problem now for injector #3

[AndreyB]

See http://rusefi.com/forum/viewtopic.php?f=5&t=929&p=16749#p16567

I believe that it is not the best approach to test with high RPM, one of the most complex triggers and self_stimulation. In order to isolate different issues from each other, it would be nice to
a) work with external signal source (maybe a second discovery)
b) start by confirming that everything works functionally (i.e. with lower RPMs) before pushing into the performance grey zone.

Since you are insisting on testing with self_stimulation and engine sniffer turned on, please do the math how many cpu ticks are available to handle each signal front @ 6000 rpm with a 60/2 trigger. Then divide this by the cost of JMP in stm32f4.

[RasPL]

ok so trigger 36/1, 900rpm, dwell 4.0ms only one coil, injection simultaneous 0.80ms chartsize 100, enabled self_stimulation, injection angle -180

triggerinfo

Code: Select all

synchronizationNeeded=Yes/isError=No/total errors=2 ord_err=2/total revolutions=4083/self=Yes
2015-10-20 17_49: EngineState: gap from 1.50 to 2.50
2015-10-20 17_49: EngineState: primary trigger input: PC6
2015-10-20 17_49: EngineState: primary trigger simulator: PD1 OM_DEFAULT freq=900
2015-10-20 17_49: EngineState: trigger error extra LED: NONE OM_DEFAULT
2015-10-20 17_49: EngineState: primary logic input: NONE
2015-10-20 17_49: EngineState: secondary logic input: NONE
2015-10-20 17_49: EngineState: zeroTestTime=13 maxHowFarOff=152760576
2015-10-20 17_49: EngineState: advanceLookupTime=2135 now=1840189825 fuelCalcTime=4435
2015-10-20 17_49: EngineState: ignitionMathTime=102 ignitionSchTime=1995 injectonSchTime=1855
2015-10-20 17_49: EngineState: mapTime=7515/hipTime=0/rpmTime=625/mainTriggerCallbackTime=9368
2015-10-20 17_49: EngineState: maxLockTime=0 / maxTriggerReentraint=1
2015-10-20 17_49: EngineState: maxEventQueueTime=2111001
2015-10-20 17_49: EngineState: hipLastExecutionCount=0
2015-10-20 17_49: EngineState: hwSetTimerTime 403
2015-10-20 17_49: EngineState: totalTriggerHandlerMaxTime=282232

[AndreyB]

ok so trigger 36/1, 900rpm, dwell 4.0ms only one coil, injection simultaneous 0.80ms chartsize 100, enabled self_stimulation, injection angle -180

I see a screenshot. I am failing to understand what exactly is the statement here...

[RasPL]

injection time when cyl1 is at TDC 0.89ms not a 0.8

[AndreyB]

Perfect.

Test conditions:
trigger 36/1, 900rpm, dwell 4.0ms only one coil, injection simultaneous 0.80ms chartsize 100, enabled self_stimulation, injection angle -180
(a script with rusEfi commands would be better for reproducing this in the future)
measurements via engine sniffer.
result: injection time when cyl1 is at TDC 0.89ms not a 0.8

Q1: can we now move from self_stimulation to a wire from simulation physical pin (PD1 by default) to physical input pin to see if that makes any difference?
Q2: can we now disable engine sniffer, disconnect from console and look at the signals via logic analyzer to see what is the cost of engine sniffer?
Q3: can we now move to external signal from a jimstim or another discovery or maybe PC audio output if that would work?

[RasPL]

now the same but injection angle changed to 170 looks like stability problem occurs if injection or ignition is "touching/crossing" engine cycle end

Q1 with wire is the same
Q2 unfortunnly i don't have now my DSO in home
Q3 i don't have external trigger generator, i can make one using arduino

[AndreyB]

i don't have now my DSO in home

http://rusefi.com/forum/viewtopic.php?f=13&t=938#p16730

[RasPL]

I'm checking code again and again i can't find from where this problem comes

[AndreyB]

I'm checking code again and again i can't find from where this problem comes

That's normal and expected

1) what is the simplest scenario where you can reliably reproduce the problem? at what RPM?
2) can you reproduce the problem with the simulator running on a PC?
3) did you get debugger set up? openocd works for me.