Otaniemi Flying Finns jumping on board the FreeEMS wagon!

[Fred]

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.

[Oskar]

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)

[jharvey]

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.

[Fred]

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.

Don't worry about that at all! See Agile Rule :

Working software is the primary measure of progress

I look forward to seeing exactly what you did and maybe swiping some of it :-)

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)

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.

Determining limp-modes in software are going to be a bitch. (if we have enough time to implement limp-modes from the first go)

Why do you want this on a race car anyway? Just curious.

Fred.

[Oskar]

Don't worry about that at all! See Agile Rule :

Working software is the primary measure of progress

I look forward to seeing exactly what you did and maybe swiping some of it

Don't worry, I'm cutting away happily.

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)

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.

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

Determining limp-modes in software are going to be a bitch. (if we have enough time to implement limp-modes from the first go)

Why do you want this on a race car anyway? Just curious.

Fred.

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.
On the road it's not that big of a issue, just takes up some time.

[Oskar]

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!

[AbeFM]

Needs More Xgate!

[Pierre6]

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!

[jharvey]

I haven't heard from these folks for a while, I'm not sure of the status.

[Pierre6]

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