Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000391FirmwareScheduler (Inj/Ign)public2011-11-15 13:522012-04-05 00:32
ReporterFred 
Assigned ToFred 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version0.2.0-SNAPSHOT 
Target Version0.2.XFixed in Version 
Summary0000391: Provide Various Options For Sched/Ign Timing During Starting
DescriptionThere are, at least, three ways to do this, the two obvious ones are:

 - Battery Voltage to assumed RPM table - then schedule normally
 - Battery Voltage to fixed delay post event + fixed event to schedule from

Both require a threshold RPM to go back to normal scheduling during the ramp up out of starting.

Another strategy could be map apparent RPM to Real RPM over some range with the final high end value with an implicit meaning of 1:1 and then stop using it after that and revert to raw RPM.
TagsNo tags attached.
FirmwareVersion
Issue TypeNew Feature
Risk of Breakagehigh
Attached Files

- Relationships

-  Notes
User avatar (0001202)
Fred (administrator)
2012-02-15 18:57

Duplicate created 0000523

Add Programmable Cranking Scheduling Mode Of Some Sort

Preston's much loved hotel requires more love while starting. It's currently doing linear scheduling which works great for anything with a better pattern, but not for something with a simple pattern. With a simple pattern events scheduled for the slow part of the cycle are early compared to reality creating a kick back effect and potentially destructive forces on the engine.
User avatar (0001204)
Fred (administrator)
2012-02-15 19:33

This problem is fairly complex. Fixing 0000137 will help improve it, but not very much, in some cases that will actually make it worse!

The problem is that the scheduling is based on an average speed and needs to be based on the average for the period involved, which is a section of a complex shape. Fortunately there is enough time to do complex calculations on it as it's only an issue at very low engine speeds.

On the other hand, tuning it would be extremely difficult, so a simpler approach is likely preferable. The computer scientist in me wants to engineer it to perfection, but the pragmatist knows that no one will be capable of using it or actually use it, even if they do know how to.

Imagine an N cylinder engine with a single edge to schedule from for each cylinder. A decoder cycle consists of a single period over which the following four things happen:

engine spends a bit of time going fast
engine spends a bit of time slowing down
engine spends a bit of time going slow
engine spends a bit of time speeding up

The end result is something like a sine wave.

Now, if you take the average, and you schedule something to finish just before the start of any given cycle (ie final end time distance from start time = (1 to N) * period of 1/N of a cycle, then the schedule is perfect!

However if you schedule over the fast 1/4 to 1/2 of the part cycle, then you end up with your event firing at a very wrong angle, very late.

Likewise, if you schedule over the slow 1/4 to 1/2 of the part cycle, then you end up with your event firing at very wrong angle, very early. This is the issue.

A very early spark while cranking is VERY bad for your starter motor.

The only real solution to this problem that is simple and straight forward is to fix 0000137 and time the signal such that the end point is fired from something very close to TDC. IE, place the signal edge at around 10 BTDC and time the engine to be that or later timing while cranking.

Nevertheless, a solution could be developed to handle the issue; though it would be complicated.

Note, dynamic dwell also affects this, so the simple solution must include a fixed dwell AND fixed timing based on a small 3d curve of BRV and RPM, or something like this.
User avatar (0001208)
Fred (administrator)
2012-02-19 11:30

I just realised that we could improve the situation without overly complicating the tuning by adding a model of a cranking speed by way of a default (but tunable) curve shape and scaler for that shape. We know which part of the cycle the pattern/input events are in because of the decoder offset so we could skew our scheduling based on the angle required and the part of the cycle that it would fall within. You'd still need some reference to battery voltage for the scaler otherwise it would only be close at one batteryV and/or temperature.
User avatar (0001388)
Fred (administrator)
2012-04-05 00:32

Tonight I implemented a hack to get the hotel working correctly. I think most or all of the above is way way too complicated. We need to get the pin on and the coil dwelling well early and then force it off at the exact moment of receiving the input signal other edge. In any case, it's running fine and starting better than ever, so this is a good start.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker