FreeEMS Goals discussion

Official FreeEMS vanilla firmware development, the heart and soul of the system!
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 »

Distributor ignition is in fact not an output issue, it's input. You can make a distributor ignition out of anything just by splicing the ignition signals into one and running it into spark box; what is different is the system does not expect sync signal. Some CAS setups are inherently cylinder order indexing, like missing teeth trigger wheels. Others, like star wheels (or, god forbid, Kettering type points) are not.

So all that's needed really is option to start firing as soon as the trigger routine detects a spark event and not bother with sync. I don't think anyone would turn down the FreeEMS because it had this feature, but I could think of few that would if it didn't.
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 »

Knowing (at the least) crank angle is pretty core to the whole point of this exercise.

There are two questions here :

Support outputting to a distributor via a single pin and appropriate logic?
Support "iffy" input signals that only support the former question?

The answer to the first is up for discussion, but the answer to the second is a resounding NO because it would require lots of special code to handle the same things based on less information than is required for proper operation. I am 110% against special case code. Anything that gets in the way of that must get the chop in one way or another.

There is zero point even going through with this at all if it will produce the same inferior result that MS produces due to batch injection. The injection must be timed such that each cylinder at the very least sees the same exact sequence of fuel injected :

1 channel : as many shots as there are cylinders per engine cycle (2 per revolution on a 4 cylinder) per cylinder (batch mode, but even injection, suffers badly from injector opening time variance at low pulsewidths, large injectors are unusable without ugly idle characteristics)

cyl/2 channels : or 2 shots per engine cycle per cylinder (semi sequential, suffers slightly from injector opening variance at low pulsewidths, more so with larger injectors than smaller, but still works ok) (without this 8, 10, 12 cyl engines can not be run properly)

cyl channels : or 1 shot per engine cycle per cylinder (sequential, works optimally with any number of cylinders, and is strongly perferred over the others)

In order to achieve this, you must know at the least at what crank angle you are at.

There is nothing to say that someone can't take what I/we produce and gut it for dizzy/suboptimal use in the future, but there is no way in hell I will waste huge amounts of my time to produce something that A does not work well, B is already available for the same or less price than what ours will end up costing.

Is that fair? If I'm doing all the work, then I must be happy with what I'm doing or there is no motivation to do it at all. No one is paying me after all.

I certainly think it is fair, I've already spent about 20% of my financial reserves and 2 months of full time work getting up to speed with the hardware and software requirements and putting the site up etc.

I guess the point is that there are finite resources (my hours) and that I see it as a massive waste of effort, time, money to reinvent a square wheel when I could spend the time on producing a round one.

So, that brings us back to the fact that it is an output thing, as the input side is a definite requirement that defines what this project is. Whether we output to a single channel or not is up for discussion, and I can see some benefits to it myself, so if it does not compromise the rest of the code in any serious way, then I'll be including that.

Actually, you could just simulate proper operation with a one pulse per cyinder input signal. You could inject sequentially like that and the timing would be consistent, but consistently in a sub optimal place i guess. You could even go so far as to implement a dash button that switched the position of injection after startup so you could choose which cylinder number 1 was by pushing the button cylinder count -1 times max. But that would be a dirty hack at best, and I for one will not write such dirty hacky code. If others want to maintain patches for such things and update them against the rest of the code on a per release basis, by all means, they are welcome and can even have a subforum each.

In fact, I have been considering different wheel input modes and how they will integrate with the code.

Perhaps each "mode" will have its own engine_position.c file that gets dropped in place of the "main" one, and each file will have a separate maintainer. For example, I could maintain and manage merges of others code into the main line and look after X-Y wheels with second trigger and denso mode, and Sean could look after GM/Nissan mode, and Flacid could maintain 99+ Miata mode, etc. I could setup a subforum with each input having a section and someone could be responsible for each. When I put out a release each maintainer could take a copy and look at the changes and diff from the last base version, port them across to their version, or more likely, migrate their input code to the main line and do a follow up release each. This exact method works flawlessly for Linux and most GNU software whereby the core maintainers release a version, and then each distro, debian, ubuntu, gentoo, fedora, slackware, etc take the source and tweek it to work properly in their distro and then release it again. This applies to kernels and all other packages. This seems like a very workable solution to me, and won't prohibit anyone from adding anything different to the project, i.e. if you want to write a hacky dizzy/kettering plugin module, that process will be supported. The only downside is that for the non core people, and the people whos maintainer is slow and or useless, the releases will be made less frequently, with more lag, and could potentially be more buggy. Of course, I would still be available to comment on and contribute to the other formats, but they would not be my responsibility.

I am very keen for as much code as possible to be unified though, but I feel that RPM/engine position code is likely to end up highly specialised, and having massive amounts of it in a single release complicates configuration and maintenance and internal code structure unnecessarily. This is very different to what MS do, and may come as a shock to some of you, but it's a tried and true practice that works extremely well in the Linux world and I have faith that it will work well for us too. Afterall, if Joe Bloggs has a 6/7 subaru engine and wants the latest code, you can bet your arse he will update and release early for his own benefit.

How does all that sound to everyone?

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
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: FreeEMS Goals discussion

Post by ababkin »

Here is my input on the previous post:

- I am not very familiar with the dizzy way of things, so i'd appreciate if you can elaborate on the dizzy one pin thing.

- I would dispute this statement: "The injection must be timed such that each cylinder at the very least sees the same exact sequence of fuel injected". (not so sure what you mean by "exact sequence of fuel injected")
While i agree with benefits of properly timed injection events for each cylinder (even though the timing itself IMO is not nearly as important as with dwell/spark), one theoretically can achieve better responsiveness (by maintaining proper AFR at sharp transients) with altering the amount of fuel injected in the consecutive cylinders (i.e not wait for the next cycle to adjust inj PW equally for all cylinders)

- Onto the wheel decoder and splitting the work: My first recommendation would be to define the interface well. Having this well defined, will make it easy to split the work and trivialize the source file substitute during the code build. I would also advise making the definition of this interface a public process/discussion, which will almost guarantee the interface agreement among the potential unique-wheel-decoder developers.
... follow this yellow-brick road to continue on this topic.


Alex
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
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 »

Admin wrote: I am very keen for as much code as possible to be unified though, but I feel that RPM/engine position code is likely to end up highly specialised, and having massive amounts of it in a single release complicates configuration and maintenance and internal code structure unnecessarily. This is very different to what MS do, and may come as a shock to some of you, but it's a tried and true practice that works extremely well in the Linux world and I have faith that it will work well for us too. Afterall, if Joe Bloggs has a 6/7 subaru engine and wants the latest code, you can bet your arse he will update and release early for his own benefit.

How does all that sound to everyone?

Admin.
That sounds good and I agree for the same reasons. I much prefer this solution that trying to fit everything into the same container and having the same person validate everything (or not) when updating the code. If a mode has not been tested it does have a new release until it is. There's also the requirement to completely and clearly defining interfaces between the modules. To me that's a plus because it requires some design and careful planning before blindly going ahead and coding.

Jean
Mops
TO220 - Visibile
Posts: 10
Joined: Wed Feb 06, 2008 1:00 am

Re: FreeEMS Goals discussion

Post by Mops »

Hm....
That was alot of reading.
I concur regarding dropping legacy things such as narrowband o2.

All though sequential injection is superior to batch injection, i think it wont be very hard to very hard to implement. Single pot engine will require proper operation in single injector/single spark per cycle mode. Nobody mentioned staged injection of things like dual fuel in different configurations (say inject fuel and methanol while on boost using extra dedicated injector)

with sequential injection i would like to see user configurable end injection angle and fuel amount calculated per cylinder fill, not per engine cycle. that would greatly help with smoothness and reduce need for AE. I understand siamese port engines prefer something along the lines of user configurable mid injection point angle....

But generally speaking...
I think project could use input of highly experienced tunes, who worked with multiple of products out here and that have tuned variety of engines... big singles, v8's, high revving small motorbike engines, wild cam race engines, turbo, supercharged, , NOS, ITB'd, mum's stationwagon engine... all these different types and combinations present different tuning challanges and ecu features must accommodate them.

There is alot of good commercial EMS products on the market, and like every product they have the up and downs (even if the only down is excessive price). I think it would be highly beneficial to do thorough market research and see what are good things of different products out there :roll: Because I'm myself only well familiar with ms2 (standard and extra code). I heard only good thing about latest gen3 link ecu and aparently autronic has this great autotune feature (implemented in PC software) that in minutes can pretty well approximate ve map of the engine...
gearhead
LQFP112 - Up with the play
Posts: 120
Joined: Sun Feb 03, 2008 9:30 pm
Location: Chicago, USA

Re: FreeEMS Goals discussion

Post by gearhead »

Ok, I finally have had time to read through this. Let me sum one thing up which may not be too clear. With a crank wheel as a trigger, you can get crank position (theta). With Dizzy, you only get 4 positions spread over 2 crank rotations. You do not know if the crank is at 0 or 90. Getting theta as a variable is important to other things such as sequential ign and sequential inj.

Now, being able to put dizzy code on top of a generic wheel decoder may be possible. I think this is what James and Ken have done with MS2/E. It has been buggy, mainly because there have been few testers, imo. If it is desirable, someone may write a version or module or whatever to actually use dizzy as an input. Fred has not focused on it. I do not think it should be a primary function of this code, either. I do think that we should be able to sensing both rising and falling edges because there are some wheels which become truly useful which are not currently so. If you are running a 36-1 wheel, you may not need it, but if you are running a 4-1 wheel which actually has precise 40 degree windows, you then get, effectively, an 8-1 wheel *and* can use trigger return cranking....

gearhead

OT: As for performance capabilities of a single coil, It really depends on what sort of boost you are carrying out there when you start running out of charge time. If your boost has tapered off (you drive a low revving torque monster) by that time, it is not a performance liability, IMO.
gearhead
LQFP112 - Up with the play
Posts: 120
Joined: Sun Feb 03, 2008 9:30 pm
Location: Chicago, USA

Re: FreeEMS Goals discussion

Post by gearhead »

Oh yeah, I forgot to weigh in on the batch vs sequential. Sequential is a must, but you should also be able to schedule all to fire simultaneously. I do not see why this is a huge limitation to be able to deal with the full amount from 'all at once' to '8 sequential'.
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: FreeEMS Goals discussion

Post by AbeFM »

First off, to preface, anything is fair. It's your show, and you're perfectly justified in doing anything you want, including not letting loudmouth Americans use it. :-)

Not supporting dizzy as a rule seems a little silly to me, but saying you'd drop it as soon as it compramises the code for the rest of the engines does make a lot of sense. It's not worth the time, and you're right in that all someone has to do is put a toothed wheel (even just a nib on the cam) to make everything work with the "regular" code.

Now all my agreeing with everyone ends! Ha!
Re-writing and replacing code seems like a lot of work, and something that will rapidly fall apart. Sure, it sounds good, a community of folks who care, all working together, maintaining releases of code long after they had a baby and sold their opel for a minivan. In reality, I don't think it would happen. Even where it did... you wouldn't want someone like me maintaining code!

To my mind, and I want to strongly preface this by saying I have zero software production experience though I do occasionally see projects and product lines run in other industries, you'd have a set of inlcudes and a standard format. If you can't set flags and provide functions to fit in a reasonable box, then yes - you have to write it all yourself. But if you can set flags and watch ports in some standard format, that should be good enough for inclusion.

If I write a miata code that sets flags like "Running", "Synced_Crank", "Synced_Cam", "Fully_Synced" etc, and tell the main routine how much fuel to spray and when, etc... I think the maintainer could upload something that fits the standard envelope, and that version would be included with all releases until a new one is made.

This will put demands on the main code to be backwards compatible with itself. Maybe that's too strict a demand. I don't know if this is something you'd pick with an INI, at compile time, or literally all this info would be included on the ECU itself and chosen through software as in MS. But I will say I like that a lot better, it's it's much more accessable to the users. Again, not everyone with a car is also a programmer. If they can't click a few things and then go turn a wrench, you're going to take a lot of people out of the running - and perhaps the work to keep them in wouldn't be so bad.



The other, unrelated, topic - about staged/banked injection. Banked injection is SO easy to do, there's no reason not to include it. /2 fuel by X, fire injectors X as often. I think people's comments on updating fueling amounts as the motor runs makes very good sense, just the sort of thing to put the extra processing abilities of this chip into.

Lastly, staged injection, Admin and I discussed this offline, but both had other obligations and never finished. Admin's comments were that there are really only 6 injector outputs. My first take on it is you just need 8 - that covers fully sequential V8's, and (more importantly to my mind) is very flexable for I-4's as well. I would REALLY like to see something where you can turn one set of injectors on and another off, ramp one in and another out. You could use it for water injection, you could use it for methanol, just plain "race gas" (letting you drive on cheap fuel when off boost) etc etc. But independant control of the primary and secondary injectors would be needed!

The easiest way out of this to me is to bank them up in a set of 4 and a set of two. You could batch fire one set, and sequential the other. Those looking for a great idle, low emissions, and a margin of safety under power would seq the main 4, and overfuel with the remaining two in a batch fire configuration. Those who want the best power and control might be happy to idle on two bank fired injectors and run the 4 in sequential mode hard when under high boost and high demand.

If you could have a fully staged injection scheme, it might pay to also have a delay, the injectors further from the port could come on a bit sooner since the air there won't make it into the engine for a little while and the port injectors will already be spraying directly onto the valve.


Sorry for the long post, I'm not keping up!!
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 »

Firstly, another quote via email from the same guy as the last :
I think that figuring out the specific pieces of hardware to support isn't
the correct challenge. Rather, it should be the search for the correct
infrastructure that supports all of them in a general way. If you create
the correct generalized framework, then making it any of the above is no
problem.
To which I will respond :

If generalising that much comes at too high a front end OR code complexity cost or speed penalty, then it is not worth it. Which is my whole point. If it's simple, and to be honest, I haven't thought about the details of how to achieve that too much, then by all means, we will have dizzys and crappy batch fire.

On with the replies...
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 »

ababkin wrote:I am not very familiar with the dizzy way of things, so i'd appreciate if you can elaborate on the dizzy one pin thing.
with a distributor you fire one coil repeatedly, and the physical distributor (hence the name) allows the spark to jump in the right direction purely from which is closer at the time. Like I said, if it's straight forward to write a fast generic lookup for this (and it probably is...) then we will include it for sure.
I would dispute this statement: "The injection must be timed such that each cylinder at the very least sees the same exact sequence of fuel injected". (not so sure what you mean by "exact sequence of fuel injected")
Well, because I spelled out what I meant in as clear a detail as I am capable of, let me give the most extreme counter case to illustrate the point.

Fuel gets dumped in once per engine cycle, first cylinder grabs all of it with an open mouth, and is happy, cyl 2 grabs the first half of it with an open mouth and has some dwelling on the walls from last time that partially makes it in in liquid form, and partially in vapour, cylinder 3 gets none of it while its mouth is open, and gets a bunch of liquid and some vapour. Each cylinder DOES get the same fuel on the average (except during transients), however, it does not get it in the same form. One of the best things about fuel injection is that it is sprayed out in a fine mist and burns more completely meaning leaner mixtures for the same power. If you dump the lot on the walls it literally puddles and that effect is lost (worse than a carby).

Hence at the least, each cylinder should see the same amount of directly swallowed mist, and the same amount of vapour, and the same amount of liquid. this ensures an even distribution of fuel particle sizes and even burn speed and energy in each cyilnder both for max power, max econ, and smoothest idle.
one theoretically can achieve better responsiveness (by maintaining proper AFR at sharp transients) with altering the amount of fuel injected in the consecutive cylinders (i.e not wait for the next cycle to adjust inj PW equally for all cylinders)
Absolutely, however there are some trade offs to be made here that must be considered. I think this is the wrong place to discuss them. That falls under "best possible accuracy".
... follow this yellow-brick road to continue on this topic.
Thanks for starting that, there was one already for that purpose, but they can be cross linked I guess. I've posted there.

Next...
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