DIYEFI.org Forum

EDIT : this post is pretty much garbage, but the ones further down are worthwhile, this was a month and a half ago (as at 2 March) and I was still coming to grips with how the hardware worked, and the limitations of what it can and can't do speed wise etc.

Hi,

I already have some thoughts on how to go about implementing this. I have found a few patents that carry some relation to this subject, but haven't read them just yet. I would like to encourage an open discussion about the best ways to achieve this in software with regards accuracy, readability, efficiency and flexibility of usage.

I intend that the exact same algorithm be used to control dwell as fuel injector pulse width.

In this way a more specific piece of code can calculate how long the signal must last, and then pass it off to a handler to implement with a hardware address to switch and a type of switching to be done.

(end time, duration, IO, type)
for fuel : (70BTDC, 6.654ms, portX, OC)
for ign : (25BTDC, 3.5ms, portY, BB)

etc.

http://www.patentstorm.us/patents/72549 ... ption.html
http://www.freepatentsonline.com/EP1010984.html
http://www.freepatentsonline.com/6955081.html
http://www.freepatentsonline.com/6827063.html
http://www.patentstorm.us/patents/68270 ... ption.html

Have a read of those and spark up a conversation.

Admin.

Having been prompted to consider what we actually need out of this module I had a think and came up with the following :

Two synced bits :
Wasted spark sync
COP sync

One counter :
Such that we know which event we are on relative to our reference event

Two status bits :
Which phase (first pair of strokes, or second pair of strokes)
RPM valid flag such that fueling can begin asap in a multi small shot manner.

Two values :
RPM for obvious reasons
Current delta RPM with various smoothing or not.

The hard part if its done generically is going to be "recognising" the wheel from an arbitrary start point and a generic description. This may not be possible. If it's not, we will need a separate piece of code for each type of wheel.

With the above information we can easily implement good timing sensitive injection and ignition schemes.

Admin.

I am not a firmware guy, but one thing I have noted is that MS2/E takes a long time to sync when running as COP. There are a number of reasons why, but one thing to consider is to run the spark in wasted spark mode (crank sync - firing 2 coils simultaneously) during cranking then run as COP when it comes out of crank. This behavior can, potentially, lead to other possibilities such as determining cylinder order from a single wheel and some clever use of current draw on a given coil as well as the use of a cam sensor.

Gearhead

As I keep saying to everyone, "by design". Note the wasted sync and cop sync bits present in that list? The code that does the setting up of the spark events and fuel events will check that and schedule appropriately for the current sync status. There are a lot of patents about how to do that sort of recognition. The EDIS one talks about it too. Specifically they do it only at start up. Continuing to supply fuel without spark is not a good plan the rest of the time though as it will lead to backfires.

Using our two sync bit status (combined with an output of rpm that is always used for some form of fueling below a certain rpm set point) will also allow the engine to run in wasted spark mode naturally without configuration changes provided that its not seeing any signals on the second input.

Admin.

OK, for the benefit of those not familiar with the basic input requirements of an engine control system I've decided to try to attempt to sum it up in plain english. My ability to do that is fairly limited, so feel free to ask questions if things are not clear.

Because most engines we are targeting are 4 stroke ones, the engine rotates twice per engine cycle. The ramification of this is that for a sequential injection or coil per plug ignition system a reference signal from the crank shaft is not enough. One from the camshaft which turns only once per engine cycle is also required.

The electrical signal that arrives at our two inputs is of a high/low digital form. Because we are using two input capture pins for this, precise timing information about when the rising and falling edges of the teeth/windows arrive is available.

Because we are planning to target a large number of unique styles of these triggers a generic algorithm is highly desirable.

Although it would be simple to implement a system based on an even number of teeth on the crankshaft and a single phase signal from the camshaft, this is not going to be particularly useful in the long run, or even the short run really. By far the most common type of crankshaft signal is 35 teeth spaced at 10 degrees separation of leading edges with a space where another tooth might have been. This missing tooth provides reference information for us to base our initial rpm and position readings from (wasted spark mode with no camshaft signal and twice as many injection events as normal of half the length.

This document contains a diagram of a common 36-1 wheel and a discussion of how it's used.

http://www.google.com/patents?id=tBAIAA ... l#PPA65,M1

And its counterpart

http://www.google.com/patents?id=wHsGAA ... g#PPA56,M1

This one discusses how to determine the location of the engine based on a single missing tooth.

http://www.google.com/patents?id=pC04AA ... ronization

This one shows another style of wheel that we could encounter :

http://www.google.com/patents?id=-HQQAA ... ronization

As I attempted to articulate above, our intention is to use a single algorithm and a set of data to "decode" these varied signals and schedule time critical events from them. It is intended that such an algorithm would take as input a series of relative widths from edge to edge such that it can compare what it is "seeing" with what it is expecting to see.

I invite you to share your thoughts on implementing this system as it is somewhat fundamental to what we are trying to achieve.

The alternative is a mess of different chunks of code that are specific to particular vehicles and require complex configuration that is highly application dependent. Obviously we would like to avoid this at any reasonable cost.

Admin.

Cross linking closely related threads :

http://www.diyefi.org/forum/viewtopic.php?f=8&t=73

Admin.