The VeeCU
Posted: Tue Mar 23, 2021 1:06 pm
by WesRagle
Hi Guys,
Retirement is supposed to be the time you do all those things you always wanted to do but just didn’t have the time while you were working. I’ve been retired for over three years now and I’m chipping away at the list. I wanted to build a Onex from the day it was introduced, check. The wife and I always wanted to get a travel trailer and visit the state parks, in work. And, I always wanted to work an engineering project outside the corporate environment, just for the sheer fun of it.
Well, it’s time to start on #3. The project will be an Engine Control Unit for my Onex. I am serious about the product but now that I have no title, no company, and no reputation to uphold, I can poke fun at myself. While I’m at it I’ll poke some fun at corporate America and all of characters that play a part.
Enter the first character, Bud. Bud’s a BD (Business Development) guy. Ref. (“https://www.urbandictionary.com/define.php?term=BD%20guy”). Bud is responsible for the title of this thread. He caught wind of what I was doing and immediately called a brain storming session to name the product.
The second character is Harold. I met Harold right out of school. Harold is the prototypical insecure engineer. He obsesses over every single detail. He wears dark rim glasses and the right ear piece is held on with adhesive tape. Harold comes complete with pocket protector and lives in constant fear of making a mistake. One more thing, Harold’s personal hygiene is somewhat lacking. Harold is a hardware guy. Last time I saw Harold he was walking in circles muttering something about load dumps, slew rates, electromagnetic radiation, and input signal conditioning. I’ll leave him alone for now. He’ll calm down eventually.
I’ll play a small part myself. I enjoy the software more than hardware. Like Harold I’m a bit of a social invalid. And…, I don’t have a very good filter between my brain and my mouth. That’s caused me grief my entire life, especially with the Suits.
Oh yes, the Suits. The Suits are an exceedingly odd group of folks, not like the rest of us. A Suit is likely to have their very own bathroom. I’m not sure why they want to live with their flatulence but it seems to be a status symbol. One things for sure, Suits have no sense of humor. You have to be very careful with these guys, they hold the purse strings. If a Suit ever approaches you with an “idea they’ve had”, even if it is a hopelessly and obviously flawed idea, don’t say a word. If you have to say something just say “Wow”. Freeze, stare off into space as if awe struck by a truly original thought. After a few moments ask for some time to think about it. Now, you need to train for this situation, just like pushing the nose over on a loss of power, the response needs to be automatic. If you’re lucky that will be the end of it. If not there are multiple full back positions. For those I charge a consulting fee.
Project details to follow.
Wes
Re: The VeeCU
Posted: Tue Mar 23, 2021 5:12 pm
by WesRagle
Just a reminder, I know this is not an economically viable project. This is therapy for me. All in good fun.
All I have is a text editor, no word processing software, I probably need to fix that.
So, here is a first cut at a top level document. If you think the verbiage sounds a bit like marketing fluff you’re right. Top level documents always start off that way. It’s an attempt to capture the intent of a product. From an engineering standpoint the top level document provides a place to record some basic system characteristics that can later be fleshed out into full blown requirements. If anybody sees a problem with the content let me know and I’ll fix it.
VeeCU Top Level Document Rev 0.01
Introduction:
The VeeCU is a microprocessor based Engine Control Unit designed specifically for air cooled Volkswagen engines that have been converted for aircraft use. The VeeCU is not designed to replace the engine’s existing induction and ignition systems but rather it is designed to augments those systems. The VeeCU provides all of the the benefits of port fuel injection and electronic ignition while retaining the existing manual systems as a proven backup.
In addition to the benefits of a traditional port fuel injection system the VeeCU allows the installer to trim each injector individually eliminating the fuel imbalance common to many VW conversions. The electronic ignition works in conjunction with fuel injection and provides optimum spark advance for rock solid idle and maximum fuel economy while cruising lean of peak.
The VeeCU’s compact size and rugged design allow it to be installed in the engine compartment thus minimizing wiring clutter in the cockpit.
Inputs:
Secondary Ignition Module Output (Front Cylinders)
Scaling 0 Hz = 0 RPM, 60 Hz = 3600 RPM
Range 0 - 5000 RPM
Secondary Ignition Module Output (Rear Cylinders)
Scaling 0 Hz = 0 RPM, 60 Hz = 3600 RPM
Range 0 - 5000 RPM
Primary Ignition (P-Lead)
Scaling 0 Hz = 0 RPM, 60 Hz = 3600 RPM
Range 0 - 5000 RPM
Manifold Air Pressure
Scaling TBD Volts = 20 Kpa, TBD Volts = 110 Kpa
Range 20 - 110 Kpa
Inlet Air Temperatre
Scaling TBD Volts = -40 Deg. C., TBD Volts = 70 Deg. C.
Range -40 - 70 Deg. C.
Mixture Control
Scaling TBD Angular Deg. CCW = -50 Pcnt., TBD Angular Deg. CW = +50 Pcnt.
Range -50 - +50 Pcnt
Communication Port
ARINC 825 data bus @ 1 Meg bit per second
Outputs:
Secondary Ignition Coil Input (Front Cylinders)
Secondary Ignition Coil Input (Rear Cylinders)
Four (4) High Impedance Injector drives.
Fuel Flow output. Open Collector output most likely simulating a Red Cube.
ARINC 825 data bus @ 1 Meg bit per second
Dimentions:
TBD
Weight:
TBD
Pinout:
TBD
Environmental:
In accordance with D0160X …
Re: The VeeCU
Posted: Fri Apr 16, 2021 1:18 am
by WesRagle
Hi Guys,
Some progress on the ECU.
The CPU is up and running with a small Real Time Kernel.
The four pulsed input channels have been implemented using one of the 32 bit timers. The edge on which the timer capture happens is programmable, so right now I’m just using a spare timer to drive the inputs for both front and rear coil secondary inputs. One captures on the rising edge and the other on the falling edge. Frequency and pulse width measurement is made to one micro-Sec.
The internal AtoD is a 12 bit SAR type with with 18 possible inputs. By the time I allocated all the pins needed for coil drivers, injector drivers, etc., there were 11 pins left for use as analog inputs. Right now I am measuring 11 external pins and two internal signals, core CPU Temp, and internal reference voltage. The AtoD is running in batch acquisition mode with all channels sampled and summed 8 times, shifted right 2 bits (so as to leave a rounding bit) and then dumped to memory via a DMA channel. The DMA terminal count ISR sums the new readings to four groups of readings. Each secondary ignition capture generates an interrupt which grabs the group with the most samples, copies it to a working group, and then zeros that group. Anyway, that gives me an average of the AtoD readings over the last two revolutions of the engine. I may change strategy during testing, but that’s the plan for now.
Two output bits have been allocated to verify/test timing.
The pics below shows timing bit #1, timing bit #2, and one edge of the “engine” timer. Timing bit #1 is toggled by the “idle” task. Any gap in toggling means either an ISR or a higher priority task is executing. In this pic Timing bit #2 is toggled at the beginning and end of the AtoD DMA terminal count ISR.
Looking at timing bit #1 you can see the AtoD DMA terminal count ISR, the Kernel timer tick ISR every mSec (along with the tasks triggered by the timer tick), and the input capture ISR (and the input capture task) generated by edge on trace #3. At present the input capture ISR just stores the captured value and signals the input capture task. In the future it will also output pulses for ignition and fuel injection. As you can see, the CPU is very lightly loaded at present.
The input capture task buffers the captured reading in a 30 reading circular buffer, calculates the period of the last revolution, the RPMS based on that period, and an RPM based on 0.3 second gate time (for display). This task also scales all of the AtoD readings to engineering units for use in calculating pulse width and phase for output.
I also bought the evaluation board for an ASIC (Application Specific Integrated Circuit) which targets 4 cylinder engine engine control. The ASIC provides a CAN bus driver, power for the CPU, two five volt outputs for sensor excitation, four injector drives, four pre-drives for the IGBTs that drive the ignition coils, and a lot of outputs that will go unused.
Up next is pulse generation followed by bringing up the Arinc 825 bus for communication with the control head.
Forever Forward,
Wes
Re: The VeeCU
Posted: Sat Apr 17, 2021 10:33 pm
by WesRagle
HI Guys,
I’ve been working on ignition pulses today. I want to feel comfortable using the secondary ignition for ground operations so I want to minimize current draw at lower engine speeds. So… the focus today has been timing AND “dwell”.
The following simulation sweeps the input from the secondary ignition module, the bottom trace (remember it will be adjusted to TDC) through a start sequence. The top trace is the wire that will be routed to the forward ignition coil and will trigger a spark on the falling edge of that signal. To test the control, below 500 RPM the spark is fired at TDC for 3 mSec. Above 500 RPM the dwell is adjusted to 25 mSec and advanced 90 Deg. (because it’s easy to look at). Exact advance and dwell will be calculated later.
The sequence:
Zoom at the transition from Start to Run (500 RPM).
Latency from ignition module input (the highest priority interrupt in the system) to spark generation during TDC firing.
Based on the following pic provided by Chris Madsen, 25 ms of dwell (on time) should be more than adequate to charge the coil. At idle (900 RPM) that amounts to a duty cycle of 0.375 which should cut the current consumption of the secondary ignition by at least half at idle. Using 5 Ohm coils should bring the secondary ignition current down to between 2 and 2.5 amps total at idle.
Recent testing has shown that there is just over 1 micro second of jitter in interrupt latency due to short critical sections in the real time kernel. That amounts to 0.0216 angular degrees of uncertainty at 3600 RPM. Nothing to worry about.
Also, the CPU is so low power that the core temperature only increases 2 centigrade degrees over ambient while running.
Did I mention that my Wife bought a travel trailer? Off on another vacation.
Wes
Re: The VeeCU
Posted: Sun Apr 18, 2021 11:54 am
by pappas
I’m kind of excited about your project and your postings. Of course, the only thing I understood in all of these posts was, “My wife bought a travel trailer”.
Nevertheless, I would love to see this working, and in the fleet. Keep at it!
Re: The VeeCU
Posted: Sun Apr 18, 2021 3:32 pm
by WesRagle
Hi Lou,
Thanks. I’ll keep at it and see where it leads. After this upcoming trip I’ll clean up the ignition code and add the injection pulses. That will probably be about a week of testing and study. Then I’ll bring up the communication bus.
You probably noticed me talking about the “Real Time Kernel”. The neat thing about having a kernel is that you can have multiple tasks (sub-programs) running on the same CPU with the highest priority program (that has something to do) running at any particular time. I mention this because the communication bus (CAN bus) can be initialized in “loop back” mode. In loop back mode the CAN transceiver receives what it transmits. In that mode I can insert a task that mimics the control head and perfect the communication protocol before I actually have to start wiring things together. The longer I can keep the project confined to a single CPU the faster I can make progress.
Anyway, it really is great fun and very inexpensive compared to building an airplane. The CPU board I’m using to breadboard the proof of concept cost a whopping $15.
My wife works jigsaw puzzles and I do this ![]()
Wes
Re: The VeeCU
Posted: Sun Apr 18, 2021 9:43 pm
by GordonTurner
Maybe we should talk some more about the jigsaw puzzles. I’m on the same apparently sink8ng ship as Lou…
Cheers, Gordon
Re: The VeeCU
Posted: Mon Apr 19, 2021 12:42 am
by WesRagle
Hi Gordon,
The VeeCU will intercept the ignition pulses coming from the secondary ignition module and use those pulses, in lieu of a crank sensor, to time fuel injection and the actual ignition pulses delivered to the secondary ignition coils. The secondary ignition will be adjusted to TDC (0 Deg. advance). The longer I can keep the project on the desk top the faster software development goes. So, simulation is key to rapid software development.
Since the MPU (Micro processing unit) has 16 timers on board, I am using one of the spare timers to simulate the pulses coming from the secondary ignition module. In it’s final form there will be input signal conditioning circuitry between the secondary ignition module and the MPU but I can ignore that for now.
Thinking about the end game, there will be two pulse streams coming from the secondary ignition module. One pulse per revolution on each stream with the pulses occurring 180 Deg. apart. Since the pulses are accepted on an edge and since the edge on which they are accepted is programmable, for the sake of simulation I can program the forward coil (from the secondary ignition module) to be accepted on a rising edge and the rear coil to be accepted on the falling edge. That way I can use the same square wave to drive both MPU secondary ignition inputs. Clear as mud?
Back to the previous image:
The bottom trace is the square wave simulating both pulses coming from the secondary ignition module with edges occurring at TDC. Looking at the top trace, those pulses will be driving the circuitry that actually fires the front ignition coil. While starting, that signal is driven low for 3 mSec right at TDC. The signal then goes back high to recharge the coil. Once the engine speed is up to 500 RPM ( 8.33 Hz) The ignition pulse is driven low 90 Deg. (1/4 of the signal period) before TDC. The signal is then driven high to recharge the coil ~25 mSec before it is fired again at 90 Deg. before TDC and so on.
Kinda hard to talk about but that’s what’s going on ![]()
Wes
Re: The VeeCU
Posted: Mon Apr 19, 2021 7:24 am
by GordonTurner
I’ll continue to monitor and input my my keen guidance to help you keep the project on track.
![]()
Re: The VeeCU
Posted: Mon Apr 19, 2021 10:37 am
by pappas
OK, great, give me a poke when you get to the part about how the inverse relationship between interest rates and bond prices in the secondary market begins to have an effect on the ignition firing sequence, and I may have some helpful input!
Re: The VeeCU
Posted: Mon Apr 19, 2021 11:54 am
by GordonTurner
Everything is connected.
Re: The VeeCU
Posted: Wed Apr 28, 2021 5:26 pm
by 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:
-
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. -
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
Re: The VeeCU
Posted: Sat May 01, 2021 9:50 pm
by 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
Re: The VeeCU
Posted: Sun May 02, 2021 12:48 pm
by 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!
Re: The VeeCU
Posted: Sun May 02, 2021 3:18 pm
by WesRagle
Hi Frank ,<?>
Everybody has some nuggets to share.
Frankart wrote: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
Re: The VeeCU
Posted: Tue May 04, 2021 10:31 am
by 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:
- 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.
- 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.
- 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
Re: The VeeCU
Posted: Tue May 04, 2021 11:24 pm
by 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
Re: The VeeCU
Posted: Wed May 05, 2021 12:12 am
by 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.
Re: The VeeCU
Posted: Wed May 05, 2021 12:35 am
by WesRagle
Sorry Bryan. I’m fried.
Mesley
Re: The VeeCU
Posted: Wed May 05, 2021 8:36 am
by 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!
Re: The VeeCU
Posted: Mon May 17, 2021 2:36 pm
by WesRagle
HI Guys,
Back from the park and working on injection pulses.
Here is a shot of three of the injector pulses. One pulse has zero delay and 10 micro second duration. The second has 10 micro seconds of delay and 20 micro seconds of duration. The third has 30 micro seconds of delay and 30 micro seconds of duration. The forth was too hard to get to ![]()
The delay and duration are controllable in 10 micro second increments up to (delay + duration) = 65535. Setting the timer to 10 micro second increments allows 0.65535 seconds as the maximum pulse width. I can’t imagine every needing more than that. And, 10 micro second resolution on injector pulse width seems more than adequate. It makes for simple code so I’m calling that good enough.
It’s time for what new grads call re-factoring. It’s what we used to call clean up. I’ll start a new project in the development environment and bring the code over piece by piece improving/simplifying where ever possible.
Looking to the future, I’ve implemented the 3-D lookup routine for typical VE lookup. Not sure that is the way I’ll go but I’m ready if that’s what I decide. It’s interesting to see all the hoops folks jump through trying to get a good start (Ref.https://www.hptuners.com/help/vcm_editor_parameters_gm_eng_fuel_general.htm). We’ll see how that goes ![]()
It’s time to start considering signal conditioning. Can I really replace my ignition coils with optical couplers?? Hum…
EDIT: So, I couldn’t resist. I went to the shop and replaced one of the ignition coils with a 10K just for a test. When the DYNA-S fired the low end of the resistor went to 0.5 volts and then back all the way to bus voltage while “charging”. The DYNA-S hung in all the way to below 5 Volts at which point it just turned on (0.4 volts). So, looks like appropriately sized resistors and opto-couplers is a viable option for acquiring the secondary ignition pulse.
Forever Forward,
Wes
Re: The VeeCU
Posted: Wed May 19, 2021 5:47 am
by sonex1566
Hi Wes,
While you, Peter and a couple of others are chasing the perfectly smooth running engine down the electronic rabbit hole…I’ve gone down the opposite path using steam power instead. I’m almost finished machining up my own custom slide needle with two difference angles to cope with the different fuel demands of idle and high power settings. If nothing else it would make a good conversation to have over a beer whilst we work out who is crazier!. Good luck.
Re: The VeeCU
Posted: Wed May 19, 2021 11:29 am
by WesRagle
HI Richard,
“Crazier” is right. Anyone who builds an airplane in the garage/shop is certifiable to begin with.
That looks like a fun experiment. Me, I took the “Red Pill” and I’m way down the rabbit hole. If you’re able to balance fuel to the individual cylinders with that needle I’ll be out in a heart beat and begging for a copy ![]()
Wes
Re: The VeeCU
Posted: Sun Jun 20, 2021 12:15 am
by WesRagle
Hi Guys,
I’m down a rabbit hole in a rabbit hole. I going to attempt to “glue” four boards together to form the “Proof of Concept” unit for what will eventually be the VeeCU. In order to do that I need signal conditioning circuitry. So …, full speed ahead and damn the torpedoes. I’ve been trying to figure out how those folks I used to work with laid out PCBs.
I just sent off for my first attempt. What comes back may make for a good laugh. It costs about $60 total for a small two sided board (minimum qty. 5). BTW, the real deal will be laid out by a professional.
If there are any PCB designers and or EEs on the list, I would love your contact information so I could ask some questions ![]()
Now, back to the display board.
Forever Forward
Wes
Re: The VeeCU
Posted: Tue Jun 22, 2021 6:40 am
by sonex1566
Hi Wes,
I believe that there must be something wrong with me, but I was thinking about your problems today whilst stuck in traffic on my way to work this morning. Peter Henry put up his picture of his fuel manifold on the top of his injectors fitted to his inlet manifold and wondered how you were going to go fitting it inside your cowling. However, last year I wasted far too much time getting a mate’s Ducati Monster going after it had been sitting for years. But what I was thinking about was how Ducati got around supplying fuel to their injectors on their V-twin engine. They just used a banjo bolt in the top of each injector and used flexible fuel tubing to go from the pump and then from one injector to the other and then the fuel pressure regulator was tacked on the end where the unused fuel was returned directly back to the tank. I was wondering if that would be a simpler and more compact way of supplying fuel to your injectors. I’ll take the management role here and supervise you while you scratch your head and wonder how the hell you actually plumb it all together!
























