FreeEMS Goals discussion

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:

FreeEMS Goals discussion

Post by Fred »

Hi,

I was prompted to share my thoughts on what exactly we are trying to achieve by a potential new member. It then occurred to me that I hadn't formally stated that anywhere so far. So I've decided to have a discussion (hopefully with some participation of others) about what the goals actually are.
  • Simplicity of configuration (None of the legacy features that were put in MS because of deficiencies in the base design)
  • Modern engines only (or old ones adapted to be modern (I own several 50's and 60's vehicles, but they will get port injection and wasted spark or coil per plug))
  • Accuracy and proper operation (Not batch mode and max of two shots of fuel per cylinder per engine cycle only on V8, V10 and V12 engines only because there are insufficient pins to do more properly)
  • Lots of I/O for features like boost control etc etc etc.
  • Lots of I/O for features like datalogging of intercooler efficiency, vehicle behaviour, etc.
  • Clear readable extensible code (Download and try to decipher the ms2 base code, then try ms2e, its better, but not good)
  • As a consequence of 1 and 6 LESS bugs and quirks and therefore more reliable operation
  • Exceptional value (Through always having a real to the bones DIY option available, and good competition in sales of kits if that occurs)
  • Truly free open source in hardware and in software
The reason for number 2 is that low performance installations with distributors and batch injection are very well catered for already. MS2E does a fantastic job of making those engines run well, and IMO they have no real need to use anything else. On the other hand, there exists no affordable accurate controller that can drive injectors sequentially and coil per plug ignition and still have sufficient I/O for the other functions required on such high performance engines. This situation is unlikely to change in the near future outside of this web site. Hence targeting the sector where they the users are not well looked after only. Also, for me it will be more satisfying to go in this direction because its somewhat idealist and purist to do so. At the end of the day, absolutely any engine can be configured to work in a high performance way. The modifications to do so are not very hard at all :
  • Add a supported high accuracy crank wheel
  • Add a single tooth cam trigger for syncronisation
  • Add one coil, lead, and ignitor per cylinder or cylinder pair
  • Add an injector to each cylinder and individual wiring to each
By far the hardest part of that is the cam/crank wheel installation. That is still something a light engineering firm can do for a reasonable price though.

Feel free to comment on what I have and suggest alterations and additions.

Thanks for your time,

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
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Re: FreeEMS Goals discussion

Post by KW1252 »

Good good!

Definite goals are important to keep the design process in line and predictable.

I think though there should be timing options for two-stroke and rotary engines, even if the traditional crank case induction two stroke is becoming history on most applications.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS Goals discussion

Post by Fred »

In the case of the rotary, the trailing spark will be able to be handled by the fully independently adjustable ignition timing code. As for the 2 stroke, can you name a single common performance application for it? If so, can you describe how its requirements differ from any other case? If the answers are yes and yes, then, why not! :-)

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: FreeEMS Goals discussion

Post by Fred »

I've read up on 2 stroke principles and as far as I can tell, we'd just have to inject and ignite twice as often for them. In which case, it's going to be simple to add that in later if anyone wants it. I've just edited the first post to reflect the "market" segment that we are aiming to please. I changed a couple of points in the first list and added an explanation of why that is the target audience. I hope that clears it up for anyone else reading it.

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
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Re: FreeEMS Goals discussion

Post by KW1252 »

2-stroke is still doing great in the sport snow mobiles, and it isn't too long ago when did in motorcycles too; the first version of FreeEMS might be a bit too bulky for most motorcycles, but it's still a possibility.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS Goals discussion

Post by Fred »

I've been having a serious think about engine types and configuration options.

I've broken it down to the following variables :
  1. Combustion events per engine cycle
  2. Revolutions per engine cycle
  3. Number of coils
  4. Number of ports/injector channels
  5. Capacity of air swallowed per combustion event
  6. Flow rate per injector channel (primary)
  7. Staged injection on or off
  8. If staging on, flow rate per injector channel (secondary/staged)
Possible values for these in the same order are :
  1. rotary 1 per rotor, 2 stroke 1 per cylinder, 4 stroke 1 per cylinder
  2. rotary 1, 2 stroke 1, 4 stroke 2
  3. rotary 1 per rotor/2 per rotor, 2 stroke 1 per cylinder/1 per 2 cylinders/1 at all, 4 stroke 1 per cylinder/1 per 2 cylinders/1 at all
  4. rotary 1 per rotor/1 at all, 2 stroke 1 per cylinder/1 per 2 cylinders/1 at all, 4 stroke 1 per cylinder/1 per 2 cylinders/1 at all
  5. rotary capacity divided by rotor count, 2 stroke capacity divided by cylinder count, 4 stroke capacity divided by cylinder count
  6. Half the capacity of swallowed air per combustion event to double the capacity of swallowed air per combustion event
  7. On or Off
  8. Typically half the capacity of swallowed air per combustion event to exactly the capacity of swallowed air per induction even, but potentially up to double the capacity of swallowed air per combustion event for a very serious beast
Using these configuration parameters and no others, I believe it should be possible to cover most high performance installations. (including siamese injection (with staging))

Now, it has been suggested to me that keeping dizzy mode (1 at all) and TBI mode (1 at all) are beneficial if only for swapping from carb/dizzy to full control in stages. I would strongly prefer that they were not included (wasted spark and 2 shots per cycle are welcome mainly because of 8,10,12 cylinder engines and startup efficiency reasons). A distributor is only good for about 6500rpm on a Naturally aspirated 4 cylinder engine, add serious boost and you can cut that to 5500. Without CDI (which I am not a fan of anyway, but has its place) That is the extent of dizzy performance. As previously stated, there are plenty of options out there that support low performance configurations already. My response to the dizzy for stages of install argument is that if the user wants to retain dizzy control while switching, then it would be better for a number of reason to retain the points/stock ECU to operate it also.

A large part of the desire to not support special cases with special code is to keep the code fast, and clean. If something like rotary, 2 stroke, siamese can be incorporated in one clean algorithm then I am all for supporting it. If it can't then I am not all for supporting it. For example, if single point injection is left in, the same algorithm will be controlling it and there will be no option to squirt less than the number of combustion events. this will render injection control fairly poor indeed but fuel mixtures in the manifold much more consistent.

It was suggested that (and I may have said this somewhere) that I am "not interested in supporting dizzy/TBI". I would like to take this opportunity to clarify this as that is not what I mean. How I feel is this : I am actively interested in NOT supporting dizzy/TBI because they are extremely low performance modes and offer no benefits during normal high performance operation. I feel the same way about narrow band O2. i.e. I am interested in explicitly NOT supporting it because it is as good as useless and will only add complexity etc for no benefit and potential headaches.

I welcome your input and debate on this topic. Although I am a dirty purist in many ways, I do try to be reasonable, and if you have a good reason for what you say, I will listen. If I disagree, I will argue the point, but I won't take it personally, only purely technically. I want the config to be simple, and I want the modes of operation to be clean and optimum. For me dizzy and TBI do not fall into those categories for a number of reasons.

Thoughts?

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
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Re: FreeEMS Goals discussion

Post by KW1252 »

I'd find it not good to exclude single coil and injector. The code shouldn't make a difference whether running single or a bunch, and doing so would exclude two minor, but realistic targets; small motorcycles and karts. Using two ECUs side by side promotes more complex wiring, and keeping the stock ECU necessitates the use of OEM sensors, which can be a problem.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS Goals discussion

Post by Fred »

Ah, my apologies!

When I said exclude "1 at all" I meant for applications of 3 cylinders or greater where 1 isn't the output of cyl count /1 or cyl count/2. So for 1 cylinder 1 = cop = sequential and for 2 cylinders 1 = wasted spark (even fire) and semi sequential.

Is that more clear?

Thanks :-)

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
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: FreeEMS Goals discussion

Post by jbelanger »

Hi,

As my first post I hope I'm not being too critical but here goes.
Admin wrote:Using these configuration parameters and no others, I believe it should be possible to cover most high performance installations. (including siamese injection (with staging))
I'm glad to see that you're planning to include siamese port injection. That's going to be nice for the Mini fans. :)
Admin wrote:Now, it has been suggested to me that keeping dizzy mode (1 at all) and TBI mode (1 at all) are beneficial if only for swapping from carb/dizzy to full control in stages. I would strongly prefer that they were not included (wasted spark and 2 shots per cycle are welcome mainly because of 8,10,12 cylinder engines and startup efficiency reasons). A distributor is only good for about 6500rpm on a Naturally aspirated 4 cylinder engine, add serious boost and you can cut that to 5500. Without CDI (which I am not a fan of anyway, but has its place) That is the extent of dizzy performance. As previously stated, there are plenty of options out there that support low performance configurations already. My response to the dizzy for stages of install argument is that if the user wants to retain dizzy control while switching, then it would be better for a number of reason to retain the points/stock ECU to operate it also.
People have been running 8000+ rpm with a dizzy on a boosted engine. I'm not sure where you got the above limitations but they don't reflect reality for many people. Having said that, I agree that it is possible to keep the current spark method when doing a new installation in stages.
Admin wrote:A large part of the desire to not support special cases with special code is to keep the code fast, and clean. If something like rotary, 2 stroke, siamese can be incorporated in one clean algorithm then I am all for supporting it. If it can't then I am not all for supporting it. For example, if single point injection is left in, the same algorithm will be controlling it and there will be no option to squirt less than the number of combustion events. this will render injection control fairly poor indeed but fuel mixtures in the manifold much more consistent.

It was suggested that (and I may have said this somewhere) that I am "not interested in supporting dizzy/TBI". I would like to take this opportunity to clarify this as that is not what I mean. How I feel is this : I am actively interested in NOT supporting dizzy/TBI because they are extremely low performance modes and offer no benefits during normal high performance operation. I feel the same way about narrow band O2. i.e. I am interested in explicitly NOT supporting it because it is as good as useless and will only add complexity etc for no benefit and potential headaches.

I welcome your input and debate on this topic. Although I am a dirty purist in many ways, I do try to be reasonable, and if you have a good reason for what you say, I will listen. If I disagree, I will argue the point, but I won't take it personally, only purely technically. I want the config to be simple, and I want the modes of operation to be clean and optimum. For me dizzy and TBI do not fall into those categories for a number of reasons.

Thoughts?

Admin.
As I've said before, I think that if you can do more, you can do less. While the single spark/injection output are special cases, they are really not complex to implement. The difference between a 4-cylinder engine with four spark outputs and a 4-cylinder engine with a single spark output is that in the latter case, you toggle the same output instead of 4 different outputs. The same is true for injection. If you want to check if you have overlapping dwell, in one case you divide the available time by 4. I don't think this is a lot and it allows more flexibility with little cost (in my mind).

I am well aware that little cost items when in a large number become too much but I don't think this is one item where there is a need to cut. I agree that we may not want to give a choice for the number of injection pulses and other dizzy/TBI specific items for the sake of keeping the config simple. But that is also the job of the user interface and a lot of effort could be spent on that to have things as simple and clear as possible. I mean with 90 possible I/Os on the CPU, it won't be simple unless the interface is very well organized.

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

Re: FreeEMS Goals discussion

Post by Fred »

Hi Jean, welcome aboard :-)
jbelanger wrote:As my first post I hope I'm not being too critical but here goes.
There is no such thing provided that it is done constructively and intelligently.

I welcome (encourage even) criticism! It's a narrow minded foolish person that thinks they have all the answers! There is no way any project of this complexity can be done well with 1 or 2 people making all the decisions. Always feel free to put me in my place :-)
Admin wrote:Using these configuration parameters and no others, I believe it should be possible to cover most high performance installations. (including siamese injection (with staging))
I'm glad to see that you're planning to include siamese port injection. That's going to be nice for the Mini fans. :)
Well, the thing is that I would not be keen if it involves a special case configuration in core code. As it happens, when you generalise out all engines as I have above, the same code can deal with that as is required to deal with all other types. And that is a step in the right direction with a more general and elegant solution that covers more setups. Covering more setups with ever decreasing circles of complexity is not my idea of a good system.

Although it may have been obvious to less intellectually challenged persons, to a mere mortal like myself I had to scratch my head quite a bit to forget cylinder count etc and notice what it actually was that we cared about.
People have been running 8000+ rpm with a dizzy on a boosted engine. I'm not sure where you got the above limitations but they don't reflect reality for many people.
How many cylinders? On 3psi with restrictive ports and cams? or 30psi with a nice pentroof chamber and large cams? with or without CDI? At what AFR? with which fuel? How about spark plug gap? gapped to some stupidly low level per chance? (that is the dirtiest of hacks IMO, gap should remain full and the ignition system should be upgraded to remove any spark blow out occuring)

You have close to 3ms dwell for a 4 pot at 8k :

http://www.google.com/search?hl=en&safe ... tnG=Search

...which might work OK at low pressure ratios with average cams/ports etc, but for a 6, its 1.5ms :

http://www.google.com/search?hl=en&safe ... tnG=Search

Which is inadequate at best without dirty horrid hacks like gapping plugs down.

Peak spark voltage/energy requirement occurs at peak cylinder pressure which on normal modern OEM style engines is in the 4 - 6k mark. You can spin higher and higher and unless you up the boost to compensate you won't get more cylinder pressure, only less.

There are differences between "can be done" "works" "works well" "should be done" "will support this" etc

Anyway discussions about why dizzys suck belong in this thread.

Discussions about whether to support them belong here.
Having said that, I agree that it is possible to keep the current spark method when doing a new installation in stages.
Excellent. Also, if someone is happy with gapped down plugs and marginal dwell with consequential low - moderate (relative) ignition probability (it's never a sure thing), then there are plenty of options for them. I really think that for moderate performance setups, MS2+V3 is a good option. What the future holds for the MS brand though is what I fear. I doubt that a sequential controller for under 300us will be available from that camp ever. That's not to say that no one will modify future FreeEMS code to do things that I personally wouldn't recommend or want to, but I'd like to shunt them in the right direction even if it narrows the audience somewhat. BTW, I went from non running to 4 cyl COP from scratch and from no wiring to running in 2 days! It's just not that hard to do it right.
As I've said before, I think that if you can do more, you can do less.
Can you explain that a little more please?
While the single spark/injection output are special cases, they are really not complex to implement. The difference between a 4-cylinder engine with four spark outputs and a 4-cylinder engine with a single spark output is that in the latter case, you toggle the same output instead of 4 different outputs. The same is true for injection. If you want to check if you have overlapping dwell, in one case you divide the available time by 4. I don't think this is a lot and it allows more flexibility with little cost (in my mind).
I agree that it isn't complex to implement, but why even allow an option that gives substandard performance when there are lots of ways to get substandard performance. I tend to think that people will do what they need to to use a good product. For example until James and Ken were kind enough to release the first alpha ms2e 2.0 code I was going to use EDIS (YUCK!!!) because I couldn't have a dizzy in my application (and because dizzys are no good at 11:1AFR and 27psi with good flow anyway). There is no way I'd choose to use EDIS, but I went out of my way to obtain those parts from the other side of the world for the ability to use MS2 in my application. Therefore I think if you say "no dizzy support" though people may grumble, once they install dual post coils and stop changing points, caps and have shorter leads, in the long term the ones that grumbled will be thanking you for making them do it "right".
I am well aware that little cost items when in a large number become too much but I don't think this is one item where there is a need to cut.
It's not a need, but rather a desire.
I agree that we may not want to give a choice for the number of injection pulses and other dizzy/TBI specific items for the sake of keeping the config simple.
Excellent. For dizzy it makes sense for a mild 4 cylinder engine only, above that it makes NO sense at all. For fuel channels it makes even less sense to use only one channel even on a 4 pot (says the guy with that config on his engine, blushes). At 7k you have 17ms and if you remove 4 of those for opening and closing you have only 3/4 of the flow you could have had. If you remove 8 of them.... it just gets silly.

What we are discussing is in effect backwards compatibility. How many software projects have been crippled by that? Java is a well known example of something that is severely penalised by backwards compatibility. There are many more. Supporting an antiquated outdated design like a distributor when a simple choice between fire once per event or twice per event could be done seems almost criminal to me.
But that is also the job of the user interface and a lot of effort could be spent on that to have things as simple and clear as possible. I mean with 90 possible I/Os on the CPU, it won't be simple unless the interface is very well organized.
That needs to be dealt with very carefully. I have some ideas on how to approach it (see the firmware wishlist), but no good way to implement it and translate to a UI.

In summary though, a feature needs to have a set of port requirements, and a port needs to have a set of properties, and overall there needs to be A way of keeping track of what is used up and what is available.

Thank you very much for your input!
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