Injector control logic (AKA design for Alex :-p)

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Injector control logic (AKA design for Alex :-p)

Post by Fred »

A particular injector is scheduled from a particular tooth at any given time.

If the pulse starts after the edge from which you are coding (and it must be definition) and an engine cycle is longer than the pulse then it is simple, you schedule the start event at X time, and at X time it switches on and schedules the stop event. no problem.

For this basic scheme to work well, pulse width needs to be limited with a min and a max.

In the RPM ISR :
In the case of pulse less than min, you do not schedule the injector at all.

In the InjectorIRS :
In the case of > max, you set to max (this is a large number, 50ms at the moment)
In the case of < min, you set to min (this should never occur as this is far less than any injector dead time, and the fact that this code is running at all indicates that you were intended to schedule more than min anyway, so min is a good approximation)

As RPM increases the switch off time comes close to the tooth, and eventually passes it, some time after this, it passes the start time.

The following logic should take care of those situations :

On the leading edge of the "trigger" tooth, you look at where the stop time is set at.

If it is closer to your time than the trailing edge, you set a bit to schedule the next start on the trailing edge.
If it is after that, but before the start of the next pulse - switch off code time, you set to self trigger the next start time from the switch off block
If it is after the next start time :
If pulse width is greater than min you set the start time now and change to rising compare
If pulse width is shorter than min, you set the start time and change to switch off

This situation may change with strange advance values, but the best approach to that is to schedule from the correct tooth based on that figure and available teeth.

I'll code this up now and give it a test. I have a strong feeling that it should behave very well :-) If not, I'll analyse it further.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Injector control logic (AKA design for Alex :-p)

Post by Fred »

The min and max limiting works perfectly. On with the other issue :-)

EDIT : Bringing RPM up slowly till the signal just falls apart and then backing off slightly till it recovers yields 472Hz (2360RPM exactly) which when the period is multiplied by 24 gives 50.847ms per engine cycle which is my predefined max pulse width of 50ms plus some error plus some code run time. This confirms my observations with some basic math :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Injector control logic (AKA design for Alex :-p)

Post by Fred »

I've realised that because only the trailing edge of VR sensors is worth watching anyway, and the tooth width varies with rpm (at least in time, if not angle too) that the best approach is to check the state in the previous tooth and decide what to do now or in the next too then. that way the tooth verification logic can stay in the leading edge code and the scheduling can stay in the trailing instead of having both in each which would A be ugly, B not even work.

Code written for optical sensors would operate differently to this, but for VR this seems like the way to go.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: Injector control logic (AKA design for Alex :-p)

Post by ababkin »

Lol @ the thread title

first off some general notes. According to my top-down (as opposed to bottom-up) mantra, lets start with injection requirements. Then couple it up with ignition requirements and factor out the common part. (then put the common part into decoder/scheduler)

For instance you've mentioned differentiating between rising and falling edges. If both indeed could be use reliably (the key word here), we can abstract away with this rising/falling distinction and simply represent it like a wheel having double the amount of teeth (with all the benefits that fall out of that, like better precision/timing accuracy/faster updates)
Also lol @ "tooth width varies in angle". I sure hope teeth don't get smaller as RPM goes up ;)
Variability of tooth width in time terms is expected and is actually what we need to measure and use.

I'll be honest, i dodn't understand half of the explanation in the first post ;) maybe you can make a diagram and a more elaborate explanation (for challenged like myself)
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Injector control logic (AKA design for Alex :-p)

Post by Fred »

ababkin wrote:first off some general notes. According to my top-down (as opposed to bottom-up) mantra, lets start with injection requirements.
This IS top down...
For instance you've mentioned differentiating between rising and falling edges. If both indeed could be use reliably (the key word here), we can abstract away with this rising/falling distinction and simply represent it like a wheel having double the amount of teeth
VR = NO, see the alpha 99 thread on msextra.com to understand why. Also, more teeth doesn't = better from an ISR perspective. for smaller tooth count wheels that is a good way to go, for 36-1, 60-2 which are almost always VR, not only do you not want to do that, you can't do that.
Also lol @ "tooth width varies in angle". I sure hope teeth don't get smaller as RPM goes up ;)
No, they get longer as RPM goes up... (yes by angle!!)
Variability of tooth width in time terms is expected and is actually what we need to measure and use.
http://www.thankscaptainobvious.net/
I'll be honest, i dodn't understand half of the explanation in the first post ;) maybe you can make a diagram and a more elaborate explanation (for challenged like myself)
Unfortunately I have to develop it. Sadly this leaves little time for explaining it when the source will be available after each and every iteration of dev.

In other news, using the previous tooth to self sched will only work at or above 100 rpm on the denso wheel if not using flash timer multi interrupting methods. Maybe i should skip straight to those now. It would mean very flexible timing indeed. Infact, fuel timing trim will be somewhat limited without such a scheme too. Hmmmm

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Injector control logic (AKA design for Alex :-p)

Post by Fred »

Just for you :

Control pulse width to 1us
Control timing of pulse start to the same
Control it based on a signal arriving on a crank or cam measured with the same timer
Control it with a timer of fixed period = 7 - 52ms
Control it when the period of things we need to switch is significantly longer than that period

See above for solution/detailed design... (or part there of)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
gearhead
LQFP112 - Up with the play
Posts: 120
Joined: Sun Feb 03, 2008 9:30 pm
Location: Chicago, USA

Re: Injector control logic (AKA design for Alex :-p)

Post by gearhead »

Admin wrote:VR = NO, see the alpha 99 thread on msextra.com to understand why. Also, more teeth doesn't = better from an ISR perspective. for smaller tooth count wheels that is a good way to go, for 36-1, 60-2 which are almost always VR, not only do you not want to do that, you can't do that.
Admin, your comment about VR for all 36-1 and 60-2 wheels applies to 'stock' and it is not always applicable. Chrysler Neons use a hall with their odd wheel. There are others. I run a 36-1 with a hall and I have run a 60-2 with a hall. They can be fast enough and are 'the way to go', IMO, if you can fit one or adapt one. 0 speed resolution, simpler circuitry, less headaches with 90+V signals on the board, etc. All that and you get both edges if you want. Allegro ATS665, Honeywell GT1 Honeywell AS443 with neodymium magnet on the back side, etc...

Gearhead
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Injector control logic (AKA design for Alex :-p)

Post by Fred »

That is true, but at 36 - 60 teeth, there is zero need for it really. And the bulk of them are VR aren't they?

Mazda engines run just fine with 4 window CAS units :-) 10degree resolution on the crank is way good enough for me :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: Injector control logic (AKA design for Alex :-p)

Post by ababkin »

Admin wrote:That is true, but at 36 - 60 teeth, there is zero need for it really. And the bulk of them are VR aren't they?

Mazda engines run just fine with 4 window CAS units :-) 10degree resolution on the crank is way good enough for me :-)
still don't understand why you adamantly dismiss this as not needed. The way i see it, the more teeth there are, the less you have to rely on the time-per-tooth extrapolation to come up with accurate time-to-wait-after-tooth for scheduling.
If i'd go as far as creating my own EMS, i'd find the courage to change the crank sensor :lol:
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Injector control logic (AKA design for Alex :-p)

Post by Fred »

Because one edge of 36 or 60 teeth is well in excess of the VAST majority of automotive engines on this planet. Including many extreme power examples. It's nice, but it's a mental nice, not a practical nice.

Bare in mind that I am 100% FOR doing this on low tooth count optical/Hall sensors etc with well defined timing.

Writing code that OPTIONALLY uses both edges for a 36-1 or 60-2 when most of them are VR and can't use it and the balance will gain no real and practical benefit from having it seems like a total waste of time to me. What do you say to that?

Where is the pragmatist in you Alex? Totally absent? I thought I was a purist/idealist, but you are rapidly making me look tame :-) :-p
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply