FreeEMS Issues - Firmware
View Issue Details
0000256FirmwareScheduler (Inj/Ign)public2011-09-06 22:062013-05-03 13:40
Fred 
sean94z 
immediateminorN/A
closedfixed 
0.2.0-SNAPSHOT 
0.2.00.2.0 
Improvement
medium
0000256: Add Delay After Sync Loss Before Resuming Outputs
This affects all decoders, but for example, take the 24/1 decoder:

The pattern is read in, and the single input event comes in on the second RPM input, sync is obtained. The primary RPM input starts counting input events on its channel. Output events scheduled during the first part (1%-99%) get fired successfully. Then a noise pulse arrives and is caught, sync is lost, and any output events in the second part of the cycle are not fired. Then the single input event comes in on the second channel again, and we repeat.

The effect of this behaviour is to have the engine running on only 1 or 2 or 3 cylinders (for a 4) and running badly and in a biased way. On engines with sequential and COP this is the only effect, however on engines with semi or batch fuel, some cylinders will still be supplied some fuel and no ignition and so on and so forth. This can result in lean conditions or fouled plugs or washed out rings etc.

What needs to happen is that a delay between loss of sync and producing further outputs needs to be added such that after a loss of sync all cylinders get a rest for a while, and the engine stalls and is less likely to run in a potentially damaging way.

This must be implemented in a way that only affects things after a loss of sync, as opposed to during a fresh from nothing sync. If it is done any other way, starting will suffer, which is unacceptable.

There are some extensive conversations (and a lot of arguments) on this matter here:

http://forum.diyefi.org/viewtopic.php?f=8&t=1143 [^]
No tags attached.

Notes
(0001159)
Fred   
2012-01-27 16:37   
I have written code to do this based on sync points as opposed to time, however a time based version that operates at the scheduler level will also get added before this gets closed. The code that I've implemented is not finished however will be added in the next week or so, definitely.

It should be noted that in some cases it can result in a wrong sync point with noise firing things at bad times because it is not where it thinks it is. This is unavoidable on a cold sync, except by slower starting, but on a hot sync must be avoided as waiting a bit to confirm N times is very quick and the results of doing this wrong while under load are potentially damaging.

My code gives the option to tune the cold sync and hot sync confirmation cycles separately such that the risk can be taken for fast starts on a well setup car with clean signals.
(0002474)
Fred   
2012-12-10 00:28   
This is third on the list after even teeth and dis dec.
(0002626)
Fred   
2013-04-10 22:08   
Started back on this today, and got half of it done. The tricky half. Tomorrow = the laborious part, and the testing. Then I'll push it out for people to test.
(0002627)
Fred   
2013-04-10 22:11   
Test order of status listing.
(0002628)
Fred   
2013-04-10 22:12   
And back...
(0002634)
Fred   
2013-04-29 15:52   
It's working for the even tooth decoder! Semi-well-named screen shots here:

http://stuff.fredcooke.com/SyncConfirmations/ [^]
(0002635)
Fred   
2013-04-30 20:36   
Fixed and available in b61fe5c76c9121078271831981799f83517dafd6 :-)
(0002638)
sean94z   
2013-05-03 05:06   
The only down side I can see is that the "flash burn blip" will likely stall and engine at idle.
(0002639)
Fred   
2013-05-03 08:52   
You're a bit behind the ball, see last paragraph in this post: http://forum.diyefi.org/viewtopic.php?p=33788#p33788 [^]

It's always been recommended to rev the engine up slightly before burning anyway.

Assigned to you for code review and/or real world testing. Andy has been driving on it and reports no issues. Please close or reopen with reasoning.
(0002640)
sean94z   
2013-05-03 13:33   
The code looks fine :) The R1 does stall if you burn without reving it up first.
(0002641)
Fred   
2013-05-03 13:40   
Cheers :-)