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!