The VeeCU

[GordonTurner]

Everything is connected.

[WesRagle]

Hi Guys,

I'm back from vacation. While away I spent some time reading and trying to plot a way forward. My main reference for ECU specific information is this book:



A couple of sticking points I'm trying to figure out:

1) What I envision is a system that is implemented "According to Hoyle". That is to say I don't want a lot of unknowns floating around that get "baked in" to the VE table. So, I need fuel injectors that are perfectly characterized. In need dead time (as a function of voltage), the non-linear region of the flow curve (just as the injector opens), and the linear portion of the flow curve. I haven't determined how to get that information. I'm afraid I will have to generate the information myself. That will take some time :-( Anyway, if done correctly, changing injectors will only involve entering the correct information for the new injectors, not a lot of mucking around with the VE table.

2) I don't have a dyno. I need to be able to vary load at a given RPM to build the VE table. The author points out, in a couple of places, that VE for a given RPM is linear with load. That implies that if I had a variable pitch prop I could make two (maybe three) runs at different pitch settings, stabilize at a given RPM, adjust Lambda to 1, record the fuel injected, and calculate VE at that RPM and load. I could then fill in any missing data using linear interpolation.

So, where do I get a variable pitch prop without breaking the bank? IVO? Has anyone used an IVO on a VW? Do you think an IVO would be OK for ground runs? The guys at IVO seem to think they are OK for VWs.

Thanks,

Wes

[WesRagle]

Hey Guys,

I've been polishing up the ignition code. The finished code will have a "watchdog timer" that will reset the CPU within 5 mSec should it lose it's way for some unknown reason. There will also be an R/C constant on one of the spare I/O pins to allow for a warm boot (no CRC of the code segment) if the watch dog triggers. I don't think there is a good way to prevent a bad timing pulse if the watchdog triggers, but I want to ensure that there is no bad timing pulse when the system restarts. Before leaving the ignition code (for now) I simulated a watchdog event by tapping the reset button.



Each edge of the center trace represents a blade. The system is initialized to eEngineStopped state with the ignition coils de-energized. If both blades are seen within 2 seconds, the eEngineCranking state is entered and the ignition coils are energized. Once two blades are seen on the same channel and the RPM is greater than 650, eEngineRunning state is entered. During engine cranking, the coils are fired TDC. In this example during engine running the coils are fired 45 Deg advanced. As you can see, the system first fires on the third blade after reset. That occurred at TDC as the system spent one blade in the cranking state. Subsequent ignitions occurred at 45 Deg. advance. No bad pulses. Good enough for now. On to injection.

Wes

[Frankart]

When I read your first post, i thought, that’s really cool. I wonder if I might have some knowledge that he could benefit from. I’ve used arduinos in my work to trigger bowling balls to get thrown by providing a ground to a an air cylinder.

After reading through the rest of the thread, you are clearly working at a level beyond what I have done or understand.

It sounds like a fun project. I will follow your updates and stay out of the way!

[WesRagle]

Hi Frank ,<?>

Everybody has some nuggets to share.

After reading through the rest of the thread, you are clearly working at a level beyond what I have done or understand.

I spent my entire career working on projects of this type. It's not beyond, above, or below, It's just different. I have never written a Windows program and wouldn't know an arduino if it walked up and smacked me in the face, but this type of programming I understand.

It's that narrow slice of programming known as "Deeply embedded hard real time". The processor and all the peripherals are your responsibility, reset to reset. BTW, "hard" in this context doesn't mean difficult, it just means the deadlines are hard.

In the end I will have been entertained for countless hours and end up with a program that is only about 32 K Bytes in size. Contrast that with the size of a typical windows program. Like I said, it's just different.

If you're interested, the board I'm working with cost about $10 and the development environment is free. If you can flash an LED exactly once a second, you're a hard real time programmer :-)

Wes

[WesRagle]

Hi Guys,

I've pretty much beat ignition pulses to death. (Ref. https://sonexbuilders.net/viewtopic.php?f=66&t=6203#p47024).

The real focus of this project is fuel injection. But, since I intend to use my existing ignition system to time fuel injection I couldn't resist adding ignition control.

The anticipated benefits of ignition control are:

1) Reduced current consumption during ground operations.

I intend to use 5 Ohm coils and control dwell to reduce current consumption at low RPM. At present the ignition pulse widths are controlled by two hard coded constants. MAX_DWELL = 25 mSec and MIN_BURN = 2 mSec. At low speeds MAX_DWELL dominates, at higher speeds MIN_BURN dominates. Again, the center trace is the simulated input, the top and bottom traces are the ignition pulses going to the forward and rear ignition coils (28 Deg. BTDC).

A pic of what works out to be 984 RPM with MAX_DWELL dominating.


A pic of what works out to be 3078 RPM with MIN_BURN dominating.


Hopefully I reduce the ignition current enough to cover the fuel pump and injector current during ground ops.

2) Smoother starts and Idle.

Initially I won't/can't fully map the ignition. So ..., in that time honored engineering tradition of "Plagiarize what you can and invent the rest.", I'm going to do what this guy did (sans ATDC timing):
Ref. page 4 of https://skycraft.ltd/docs/Leburg/EI10A_Electronic_Ignition_System.pdf.

3) Optimum spark advance during LOP operation.

Time will tell.

Anyway, we got some rain so it looks like the grass is actually going to grow this year. I need to take a break for ground keeper chores. My wife has scheduled another state park visit next week in her new travel trailer. I'll get back to injection when we return.

Wes

[WesRagle]

Guys,

I know I said I would go away for a while but ... It's hard to turn it off.

I've been thinking about what Brian said about ATDC firing during start/hand propping. And Brian, you're right. All I'll have to do is adjust the secondary ignition input to 10 Deg. ATDC and use the input the same way I am now during start and then adjust the arithmetic to remove the 10 Deg. once normal advance resumes. It will have the added benefit that the data used to calculate the delay until next spark during normal running is a little less stale. I've been staring at a scope and measuring pulses referenced to TDC for days now and just got a little case of tunnel vision.

Thanks,

Wes

[Bryan Cotton]

Attaboy Wes! Us 'Y' Bryans know our stuff too. I've also studied the Leburg unit and that is where I got the idea from. One of my future projects is a microprocessor based ignition for my 1981 Suzuki GN400. All the old CDI units are on borrowed time as the caps don't last forever.

[WesRagle]

Sorry Bryan. I'm fried.

Mesley

[Bryan Cotton]

No worries! It was shocking as I've never seen my name misspelled before.



(That is a joke.....)
Keep the cool stuff coming!