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:

Re: FreeEMS Goals discussion

Post by Fred »

jbelanger wrote: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.
Give me a hug! lol (jokes!!) Awesome, I think its a good way to do it.
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.
Yes, and in a week or two when the experimentation is over, the design will begin (it has already, but more formally and publicly and completely) and that is where your and others roles become crucial! I'll have to kick my trusty German friend into action about then, as he has some ideas about code structure etc and how not to do it and I want his (valued) input on this.

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

Mops wrote:I concur regarding dropping legacy things such as narrowband o2.
Excellent, then it's just a matter of knowing what to do and what to not do. Also, drop is the wrong word, never pick up is more accurate, remember, this is totally from scratch.
All though sequential injection is superior to batch injection, i think it wont be very hard to very hard to implement.
True, but having the ability to control the number of shots of fuel per cycle is not in the game plan, thats another "if" etc that we just don't want.
Single pot engine will require proper operation in single injector/single spark per cycle mode.
The same math that handles all the other engine types can handle this without mods as I see it. As I said above, I wasn't clear about that, and I tried to explain that that is not what I meant.

Then again, perhaps FreeEMS needs a name change? FreePCMCSCOPEMS = free performance car multi cylinder sequential coil on plug engine management system might be better :-p

Once again, if doing it right = doing without those special case minority (in 2008) groups like dizzy types, then so be it. I doubt that will be necessary, but some level of it might be. We'll see.
Nobody mentioned staged injection of things like dual fuel in different configurations (say inject fuel and methanol while on boost using extra dedicated injector)
ahhh, another stingy dual fuel type, see here for a discussing on the ins and outs of staged operation and what it means to hardware usage and have your say (please!??!) http://www.diyefi.org/forum/viewtopic.php?f=8&t=76
with sequential injection i would like to see user configurable end injection angle and fuel amount calculated per cylinder fill, not per engine cycle.
Already on the cards, but thanks :-) I'll start a thread discussing the ins and outs of calculation timing soon for you and alex to read, and everyone to discuss.
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....
Provided the end time can be tuned in a 3d map rather than fixed or based on rpm then Jean and Co will be ok. The resolution of that map is up for debate I guess, but 8x8 seems reasonable for such a fine tuning measure? (start a thread to discuss this requirement if you feel the need to discuss it)
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.
Do invite such people that you know to join in, but please be sure to let them know that this is still a private affair not to be linked around until I clear it with some important people (some of which should get their a into g and email me back, including me who should do what he said he would..).

However, covering ALL types of installations is not and was never on the game plan, going as broad as possible while still maintaining the core ideas of highly accurate control in a timed way is in the game plan. If those things don't push us off course, by all means, but if they do... (let them hack it apart for their own purposes and create a "low-res" branch later)
aparently autronic has this great autotune feature (implemented in PC software) that in minutes can pretty well approximate ve map of the engine...
"auto tune" belongs outside the EMS and will never make it into any code released by me. There are a large number of very good reasons for this, but here is not the place to discuss them.

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

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.
It would be nice to one step further and know engine position, but I think crank angle and phase boolean combined with a COP/seq synced boolean are a better choice because it allows the code to work correctly when that info isnt available (at startup, or when only using crank)
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.
What they have done is try to read the dizzy signal with the wheel decoder. I personally think that is a waste of time and won't try to do it at all, but a plugin that does dizzy mode only with dizzy input only is fine and would be REALLY easy to write :-) Running dizzy over the top of a decent wheel like 36-1 is also easy, but doing it with the EXACT same code as the other modes might be less easy, we will see.
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.
I already have code that works like this to echo the input from the JimStim to a pair of LEDs, it is not difficult to do at all, but the key here is configuration at compile time and or through and interface and managing that with a view to simplicity and bug free operation. I think using both edges of any generic VR input for a X tooth wheel is a bad idea as if the teeth are not correctly dimensioned then the high pulse could be much shorter (or longer) than the low pulse. For an optical or hall sensor, this makes good sense though. Hence specific code for specific cars idea above.
you then get, effectively, an 8-1 wheel *and* can use trigger return cranking....
I have a request to everyone to try to use industry standard and scientific terms, however, if common terms fit the bill, use them instead, the first example is "theta", theta is just "an angle" I think we should stick to calling it crank anglular position or just crank angle, not "theta". Secondly, what the hell is "trigger return cranking" and which trigger, returning from where? to where? I really don't understand, and that especially seems to me to be highly MS specific language. There is a LOT of MS specific language used in the MS project, and I would like to steer clear of all of it that is only used there. Things that are common outside of MS, sure, but "trigger return" ?? what's that?

Also, there won't be a cranking mode if I can help it. That is ugly and non-generic too. Either the map will be larger RPM wise to handle "cranking" and "idle" or we will use a non-table tuning method, the latter being my preference. i.e. arbitrary points in space.
If your boost has tapered off (you drive a low revving torque monster) by that time, it is not a performance liability, IMO.
I'm not convinced those fit in the same sentence together :-p there is a reason Ferrari use 12 cylinders for 6 litres and not 8 like the LS2. That reason is performance. Performance could be misunderstood. 500hp and 500Nm are not performance, they are power and torque, performance is a package and relative thing for a given cubic capacity. Thats even more OT though :-)
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'.
For a start, there will be no 8 cyl sequential without bit banging. Secondly, the latter is required for those times when supplying fuel without sync, i.e. while initially cranking to ensure a reasonable amount of fuel is induced.

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

8InchesFlacid wrote: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. :-)
Thank you :-) It's only my show until I do less than half of the work though. I have to say, the ...Americans... bit cracked me right up, many of you do have a propensity to talk a lot, but thats a non-issue, it can be quite entertaining. I don't want to exclude anyone in particular from here at all. BTW, the fact that it is GPL, like MegaTune, and MegaTunix means that I have no right to disallow your use of it at all. You can take and change it etc till your heart is content.
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.
Exactly.
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.
Exactly.
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!
If done well, and I will try very hard to do it well, it won't be a lot of work at all. It will be pretty close to a one off code writing exercise to read one or two inputs and generate one to 24 outputs from them. If the interface is fairly complete in the first place then other changes shouldn't affect this at all and its just a matter of compiling and running it on your engine to ensure it still works correctly before releasing your branch. Literally, copy file across to new release, build s19, run on engine, release. Ideally, you would want to check the changes to the rest of the code to ensure that they don't affect your branch, but given that great interface, that should not occur.
To my mind, and I want to strongly preface this by saying I have zero software production experience......that version would be included with all releases until a new one is made.
As Jean said so well up above, if I can't test it, how can I release it with any certainty that it's any good? Therefore someone that can test it ON A CAR should do the release for that branch, EVEN if they dont do anything except configure and build and install and drive. (which should be all that is required most of the time anyway)
it's it's much more accessable to the users. Again, not everyone with a car is also a programmer.
Maybe not, but, this is DIYEFI.org, not SMDfactoryEFI.org, and all "users" will be expected to pull their weight in some fashion or other. Nothing will come on a plate from here, only from various "distributors" that choose to support a certain type of vehicle/feature/hardware for their own interest and or profit. It's a 5m task for you to configure, compile, install an s19 and take it for a thrash round the block :-) why not you maintaining it? even if I write it?
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.
Once again, just because I don't release XYZ code, that doesn't mean that it won't be released and clickable by someone else for someone else an hour after I release... Demand vs. Supply, If there is demand for miata code, someone will step up to the plate :-) Consider all the time you've spent posting about your miata issues (a LOT), consider what might have taken place if you had spent all that time learning the code and trying stuff out yourself on the fly and finding a solution? You would have one, even if it wasn't compatible with the rest of the code... Time better spent? I think so.
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.
Most likely yes. Once again though, if it gets in the way... then no. But, it shouldn't.
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.
I really need to do a thread for you, Alex, and Mops etc about this. Maybe I'll do that now.
Lastly, staged injection, Admin and I discussed this offline.........etc. But independant control of the primary and secondary injectors would be needed!
See next comment :
The easiest way out of this to me is to bank them up in a set of 4 and a set of two.
= special code/config = no, also, sequential or go home :-) see this thread : http://www.diyefi.org/forum/viewtopic.php?f=8&t=76
Sorry for the long post, I'm not keping up!!
Not a problem, it would have been easy if not for all the others who also got off their arses and had their say :-) Thanks to all of you for that!!

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 »

Thread for Mops, Alex, Flacid and others to discuss their thoughts on when to run various calcs for key things :

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

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

I'm a little worried that too much weight is being put on the occasional if statement. It can be kept reasonably generic, and still run very fast.

At full tilt, I get 22 us / degree. (7500 rpm). If you're talking about avoiding a 10 us total delay, you might have a point - though of course any fixed delay wouldn't be an issue. A ten ms delay could keep the motor from running. But you get a min of 1000 clock cycles per degree, so after figuring in some preserved latency... Maybe the occasional if statement wouldn't be too bad. If you're accuracy is better than 1/10th of a degree, do you buy yourself anything? Is it worth trading capabilities for that?

I can tell you that 1/100th of a degree resolution at full revs will NOT be a faster car than the same car with water injection, higher octane fuel, etc etc at 0.2* accuracy.
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 »

8InchesFlacid wrote:I'm a little worried that too much weight is being put on the occasional if statement. It can be kept reasonably generic, and still run very fast.
The thing is, it might not be one if, it might be a dozen of them etc. It could quickly grow out of hand.
At full tilt, I get 22 us / degree. (7500 rpm). If you're talking about avoiding a 10 us total delay, you might have a point - though of course any fixed delay wouldn't be an issue. A ten ms delay could keep the motor from running. But you get a min of 1000 clock cycles per degree, so after figuring in some preserved latency... Maybe the occasional if statement wouldn't be too bad. If you're accuracy is better than 1/10th of a degree, do you buy yourself anything? Is it worth trading capabilities for that?
I haven't said this explicitly until now, but consider the 60 tooth crank wheel, and consider ALL the other stuff that the code will be trying to do in the background (control fans, shift lights, tachos, send datalogging, etc etc etc etc. Once you look at the full picture there is a LOT to do. also, lets do some math (been meaning to do this for a while) :

20000rpm (bikes/bike engines in cars!!!)
60 teeth one interrupt each
40MHz

= 2000 clock cycles per tooth to do everything, now, it doesn't matter that you only do some things on most teeth, you need worst case, so you need to A sample the inputs B lookup the tune C calculate the advance, pulsewidth, etc D figure out if this tooth is the right one to schedule from E do that scheduling F update various runtime properties E etc, mean while, for each revolution you need to run at least 4 interrupts per firing event that all take cpu cycles too. At the same time, latency of running those interrupts is crucial for accurate spark and fuel timing etc.

All of this MIGHT be possible if running asm code, but even then its marginal. Doing it all in C makes the challenge even more difficult. EG, a function call alone in either asm or C uses between 8 and 20 cpu cycles (assuming single cycle instructions) which is why functions in our core fast code are a big NO NO. (hear that Alex :-p). 20 is 1% of 2000, and thats best case for the worst case that we were analysing...
I can tell you that 1/100th of a degree resolution at full revs will NOT be a faster car than the same car with water injection, higher octane fuel, etc etc at 0.2* accuracy.
0.5degree timing is enough, 0.1 would be nice but is excessive, but we should aim very high and fall high :-)

Does that help a bit?

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

Admin wrote: ...consider ALL the other stuff that the code will be trying to do in the background (control fans, shift lights, tachos, send datalogging, etc etc etc etc. Once you look at the full picture there is a LOT to do.
Fans, tachos, etc are very close to free. Maybe not free, but very close to it. Since chips like the MS-II and even MS-I run pretty high res code and do all this without running against a hard wall of CPU time, I bet we can too.
also, lets do some math (been meaning to do this for a while) :

20000rpm (bikes/bike engines in cars!!!)
60 teeth one interrupt each
40MHz
Certainly aiming high there, with what I dare say is a useless number of teeth on an unrealistic rev limit, but for the sake of argument, let's stick with it. I admit I'm curious to see some logs where there are 60 teeth recorded where date from a 36 tooth wheel wouldn't have worked just as well! No reason to have something that runs worse but more accurately.
= 2000 clock cycles per tooth to do everything, now, it doesn't matter that you only do some things on most teeth, you need worst case, so you need to A sample the inputs B lookup the tune C calculate the advance, pulsewidth, etc D figure out if this tooth is the right one to schedule from E do that scheduling F update various runtime properties E etc, mean while, for each revolution you need to run at least 4 interrupts per firing event that all take cpu cycles too. At the same time, latency of running those interrupts is crucial for accurate spark and fuel timing etc.
Why do I have a sense this isn't strictly true? If one or two if statements can save you from having to calc all that stuff... I think for most of the teeth, you're just going to write down the time you saw it at somewhere, and move on. Calculating all that every time is going to get quite intensive, and likely not needed. It seems a place where a little intelligence could save you a lot of calculations you're not going to use anyway.

Also, the latency isn't nearly as big a deal, on most events you're going to just record when something or other happened. One the ones where you do something, it'll be a pretty rigid set of commands, and the latency should be fixed that leads to a firing event, and therefor can be dealt with.

When any interupt occours, the first thing you do is write down when it happened. Then you see if there's more to do. If not, you move on, short interupt. If so, you have the time written down, and you base your firings on that.
0.5degree timing is enough, 0.1 would be nice but is excessive, but we should aim very high and fall high :-)
As long as aiming high doesn't actually aim quite low - to give up other capabilities for accuracy you won't use seems a bit off.
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 »

It does not matter if you can go if(blah){} because the time that blah is true, you MUST finish all of that code before the next tooth arrives. So yes, you save cycles on most teeth and the rest of the code gets to run, but your code for the tooth that does need it must run in the same time window regardless.

20k is realistic, 60-2 is realistic, both at the same time is not, but it's still possible. 10k and 60-2 is a real engine though.
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 »

Admin wrote:It does not matter if you can go if(blah){} because the time that blah is true, you MUST finish all of that code before the next tooth arrives. So yes, you save cycles on most teeth and the rest of the code gets to run, but your code for the tooth that does need it must run in the same time window regardless.
Unless this happens to be the missing tooth. But that is probably not a real situation where (blah) would be = missing tooth.
Post Reply