LOL @ Abe's comments!
And I'm only a terrorist when I'm behind the wheel of a car! :-)
Let's try to keep this on topic from now on ey? Sweet!
Fred.
Otaniemi Flying Finns jumping on board the FreeEMS wagon!
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
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!
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!
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
The hardware is now in the final stretch. Some of the thinner wiring still to go, otherwise done.
Hopefully will be getting the board made in 1.5weeks.
Software is moving along. Regretfully I have been hacking up the FreeEMS code quite a lot. Our software will in no way be compatible with FreeEMS. Basic file and variable structure is still the same though so maybe stuff can be moved over if useful.
Getting good injection amounts calculated at idle is going to be tricky. We will be using much shorter injection times at idle then the injector opening time.
The damn controller is VERY slow, I don't think it will be able to do [edit: corrected below; at the moment looks to be ok] a whole ign&inj calculation loop per engine work cycle at max rpm. ...when is fast ever fast enough (Xgate code perhaps, or maybe some monster controller for the next version)
Determining limp-modes in software are going to be a bitch. (if we have enough time to implement limp-modes from the first go)
Hopefully will be getting the board made in 1.5weeks.
Software is moving along. Regretfully I have been hacking up the FreeEMS code quite a lot. Our software will in no way be compatible with FreeEMS. Basic file and variable structure is still the same though so maybe stuff can be moved over if useful.
Getting good injection amounts calculated at idle is going to be tricky. We will be using much shorter injection times at idle then the injector opening time.
The damn controller is VERY slow, I don't think it will be able to do [edit: corrected below; at the moment looks to be ok] a whole ign&inj calculation loop per engine work cycle at max rpm. ...when is fast ever fast enough (Xgate code perhaps, or maybe some monster controller for the next version)
Determining limp-modes in software are going to be a bitch. (if we have enough time to implement limp-modes from the first go)
Last edited by Oskar on Wed Jul 08, 2009 12:50 am, edited 1 time in total.
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
One note about the injector thing, using OV protected FETs like the PIP3104 should allow for a much more precise control of the injector at low duty cycles. When using shunted inductive driving techniques, you have to dissipate the inductive energy in a decaying logarithmic manner. When turning off the injector, you are generally in a fairly horizontal region of the injectors decay. This causes the tolerance brackets to open significantly. Lets say +/- .25ms. Now on a 50% duty at 100ms cycle, the delivery vs predicted is off by about .25%. So not a big deal, and easily adjusted for by other feed back systems. However, at 10% duty, your actual delivery vs predicted delivery varies by 2.5%. This increased variation makes it hard for feedback systems to compensate for the variation.
By using an OV protected FET, you dissipate that energy in a linear fashion, not an exponential decay. This means you are not on a horizontal pattern, but a downward slope. This means your +/-.25ms tolerance, can be decreased which then decreases the variation at low duty cycle, and allows you to use one injector instead of multiple injectors, ect.
As for the rise time, using pulse and hold, will keep you in at a fairly linear rise, and the tolerance brackets should be fairly narrow.
By using an OV protected FET, you dissipate that energy in a linear fashion, not an exponential decay. This means you are not on a horizontal pattern, but a downward slope. This means your +/-.25ms tolerance, can be decreased which then decreases the variation at low duty cycle, and allows you to use one injector instead of multiple injectors, ect.
As for the rise time, using pulse and hold, will keep you in at a fairly linear rise, and the tolerance brackets should be fairly narrow.
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
Don't worry about that at all! See Agile Rule :Oskar wrote:Regretfully I have been hacking up the FreeEMS code quite a lot. Our software will in no way be compatible with FreeEMS. Basic file and variable structure is still the same though so maybe stuff can be moved over if useful.
I look forward to seeing exactly what you did and maybe swiping some of it :-)Agile wrote:Working software is the primary measure of progress
I wouldn't say *very* slow, but I agree that it won't be doing a whole calculation loop at max rpm between 2 cylinders. Then again, why does that matter? It doesn't *really* matter.The damn controller is VERY slow, I don't think it will be able to do a whole ign&inj calculation loop per engine work cycle at max rpm. ...when is fast ever fast enough :) (Xgate code perhaps, or maybe some monster controller for the next version)
Why do you want this on a race car anyway? Just curious.Determining limp-modes in software are going to be a bitch. (if we have enough time to implement limp-modes from the first go)
Fred.
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!
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!
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
Don't worry, I'm cutting away happily.Fred wrote:Don't worry about that at all! See Agile Rule :
I look forward to seeing exactly what you did and maybe swiping some of itAgile wrote:Working software is the primary measure of progress
Well it does have a more power then a desktop cpu had 20years ago, with a whole lot more functions. But fast is never fast enough; hence very slowFred wrote:I wouldn't say *very* slow, but I agree that it won't be doing a whole calculation loop at max rpm between 2 cylinders. Then again, why does that matter? It doesn't *really* matter.The damn controller is VERY slow, I don't think it will be able to do a whole ign&inj calculation loop per engine work cycle at max rpm. ...when is fast ever fast enough (Xgate code perhaps, or maybe some monster controller for the next version)
Doing a whole loop per event would mean no nead for transient corrections (with their errors), when combined with fast enough sensors and clever sensor reading timing.
Limp modes are especially important on race vehicles, you don't want to have to stop and diagnose a sensor or wiring issue in the middle of a race if the software could be made to function with the issue.Fred wrote:Why do you want this on a race car anyway? Just curious.Determining limp-modes in software are going to be a bitch. (if we have enough time to implement limp-modes from the first go)
Fred.
On the road it's not that big of a issue, just takes up some time.
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
Ahem...
I had made a small (really quite minor) 10x calculation error in how many usable clock ticks we have between cycles.
Our main electrics guy promptly didn't believe it would be so tight so I calculated it again
There should definitely be enough ticks available to make a full loop between cycles with low-fat code.
But I still think the controller is very slow!
I had made a small (really quite minor) 10x calculation error in how many usable clock ticks we have between cycles.
Our main electrics guy promptly didn't believe it would be so tight so I calculated it again
There should definitely be enough ticks available to make a full loop between cycles with low-fat code.
But I still think the controller is very slow!
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
Needs More Xgate!
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
Hi guys!
How did this project worked out? Did they build their ECU's? Are there documents i can read about their hardware/firmware design?
Cheers!
How did this project worked out? Did they build their ECU's? Are there documents i can read about their hardware/firmware design?
Cheers!
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
I haven't heard from these folks for a while, I'm not sure of the status.
Re: Otaniemi Flying Finns jumping on board the FreeEMS wagon!
Guys,
I had contact with Oskar. He gave me this link: http://off.tkk.fi/Ohjauselektroniikka.pdf. But my finnish isn't that good Somebody here keen to translate it to english?
Pieter
I had contact with Oskar. He gave me this link: http://off.tkk.fi/Ohjauselektroniikka.pdf. But my finnish isn't that good Somebody here keen to translate it to english?
Pieter