Re: New VW-Porsche EFI under development

Ant, I have had constant experience with air cooled VW's since 1977. The system is an attempt to keep the good and replace the rest with the best solutions available.

More information is being place on the site as it develops. I wear so many hats my head is real smooth. Trying to work longer on each thing to avoid the cap changes.

It is too early to suggest a price. The system has been designed for maximum value for the money spent.

The system is running, however much testing and detail enhancement is required. I want to go to market without a bloody nose.

Could you suggest in detail possible headaches? I will add them to my test plan. Dave

If I was to develop an engine management system for doing FI and ignition, that's where I'd start as rotational position would be the high priority hardware interrupt and essentially the 'server' with the FI system being able to figure-out what to do next in the CPU idle time. Are you writing the code in assembly or more high-level like C? Just wondering.

I was wondering this for a long time... Is there any validity to the theory about swapping the throttle control from air valve that the fuel is then metered to, to a throttle-by-wire method where throttle position controls fuel amount delivered that the air is then metered to instead? I think it would avoid the situation where your in full O2 feedback on the highway and the system is trying to lean for fuel economy, but might go too far lean and you lose some power and you increase the pedal, and end up fighting the economy mode (did we go too far or does the driver just want more power?). Throttle-by-wire wouldn't really have that, would it?

excellent. Interrupt-based is the way to go.

I'm more a theorist that a practitioner :) I code for desktop systems, not embedded. Would love to apply the free-time that I wish I had to messing around with an embedded EMC design.

I thought about using MicroC/OS-II as the RTOS and making it in C++ just for the fun of it:

class Cylinder { public: Cylinder(int degreesOffset); };

class Engine { Cylinder C1; Cylinder C2; Cylinder C3; Cylinder C4; public: Engine : C1(0), C4(180), C2(360), C3(540) () { Run(); } };

Maybe one day after I build the T4 upright conversion I really want for my bug, I'll get around to it...

Whoa, hold it now. You define all engines to be 4-cylinder and

4-cycle. Not good.

Here's the physical properties of a chevy V-8. 2-cycle would just operate on a single turn of the crank, not 2, so there's only one TDC which simplifies the need to know which TDC of the crank starts the cycle.

class Engine { Cylinder C1, C2, C3, C4, C5, C6, C7, C8; public: Engine : C1(0), C8(90), C4(180), C3(270), C6(360), C5(450), C7(540), C2(630) (); };

Sorry to have confused you, I was just sketching the physical properties of a vw engine in code. In the future, I won't post source code bits to a non-computer language newsgroup. I made no mention of how a timing service relates to it.

I can see some obvious wrongs with letting the cylinders define their own timing curves, if I did it that way: vacuum advance and knock retard should really be global as well as the curves. The issue with cylinder #3 running hotter was addressed in the Bosch 009 by retarding the timing on #3 a few degrees, which probably isn't applicable in a new design. Who knows though.

What the CPU is supposed to actually do is a much better way for me to theorize on this than some OO vision, anyways.

Like take the knock sensors.. I was thinking of some fft processing on the digital stream to measure the energy at resonance (high Q band-pass). I read that the resonance of knock is directly related to the bore size and is around 5kHz or so. And I would think, to be most accurate, the moment in the cycle for taking a sampling should only be when knock could occur to avoid noise from other sources like valve tick and such (another client of the timing service, BTW). IOW, just sample at the places you know knock will occur and ignore everything else. The windowing would be something like -35->0, (-35->0)+180, (-35->0)+360, and (-35->0)+540

Does that sound to you like a good basis for a knock detector design?

I wrote an asteroids clone game once. I did all the calculations in degrees for easy thinking on my part, but the drawing calls all took radians. So by the end of it, I wasted a lot of effort bridging back and forth. I see your point... give up rotational position and think divisional moments in time to achieve those positions which can interpole between the flywheel teeth ticks.

By dwell, you mean the charge time to get the field up in the coil? Which, I assume is probably constant? Never built a CDI system..

Optimizing is done during a test phase to validate a theory. I'm guessing the valid windowing points are in that vicinity and after the ignition event has fired up to full compression. On a vw engine, I guess 2 piezos would be best: one for each cylinder head rather than one in the case (?)

I need a stereo wave file for testing this idea. one channel has the piezo full band, the other has TDC ticks. Run the engine over advanced under load to make it knock and record it... Sounds like a fun programming problem I can play with isolated on a desktop..

David, Great job! You understand well!. Dave

On Mon, 01 Sep 2003 13:43:29 -0700, David Gravereaux left Mt Vesuvius in a state of jealous awe as he began spewing from the mouth thusly:

Just keep an eye out for those "black helicopters." I want to believe...

-- Travis '63 VW Camo Baja...

your enemies. It messes with their heads.It doesn't take a very big person to carry a grudge.

About your question on your website regarding board manufacturers:

I had good luck with them back around 95 when I needed a quick prototype of a pc board for a meeting with a client. They got me the prototype in 2 days from the gerber plots. I can't say how they are nowadays.. But they saved my butt and the company got the contract!