|PIC Links:||For the
5BECU, the tools of choice are the Microchip Flash series of controllers,
specifically the 16F87X series. Thes cost approx. $8.00
U.S., are capable of low-voltage ICP (In Circuit
Programming) for firmware updates, and have on-board
Analog to Digital Conversion, Timers, and PWM output.
The code for the ECU is compiled with PicBasic Pro, a Basic language compiler available from MicroEngineering Labs. Assembly is using the Microchip assembler, available as a part of the MPLAB IDE, free from MicroChip. Programming of the Flash chips is done with the EPIC programmer, also available from MicroEngineering labs.
|Circuits of interest
Outdated but still interesting
PicBasic code samples
19 Feb 2002: Adventures in wireless turbine data transfer have been posted.
3 Feb 2002: Minor and modest revisions to the basic ECU continue. I am on version 150 as I write. Everything is running well. The PDF document is still accurate except one additional user-defined value has been added... the ability to adjust the accel ramp shape. Accelerating a gas turbine from a stable RPM is a complex process when done in a manner which precludes EGT spiking, especially at low RPM. Early versions of the firmware would initially (and gently) accelerate the rotor from its stable RPM by incrementing the 10-bit Pump PWM over a short period before allowing the acceleration profile to take over and really drive the turbine to the commanded setting. This worked best for my MW-54. Bill Blackburn's KJ-66, on the other hand, could skip this process, so I added coding which allows the user to define the shape of the initial acceleration profile.
This drawing is pretty crude but perhaps it will be helpful. The vertical axis is the amount of fuel added as time passes to accelerate a turbine to a targeted setting. The overall height of the curve is set with Pump Ramp Up in setup. Pump Ramp Up defines how long the acceleration profile takes from a given RPM to a higher RPM. The new user setting is called Pump Ramp Up Profile, and determines how the curve (until it reaches its peak value) is shaped.
Note the left hand curve, which is suitable for my thrust MW54. Assuming the turbine is idling at a pump setting of 30 (using 8 bits in this example), and max RPM occurs at a pump setting of 165, I snap the throttle from 0% to 100%. The ECU determines the pump delta, the difference between 30 and 165, which is 135. It then examines the value of Pump Ramp Up. At a Pump Ramp Up of 16, the profile is designed to accelerate from idle to max in ~ 4 seconds. It then slices the pump delta into segments, and begins to add these segments (over 4 seconds) to the current pump setting until the desired pump target is obtained. For this example, let's assume that the software slices 135 pump units into 15 segments, resulting in an increase of 9 units of fuel per addition: 9 X 15 = 135. If I simply slam an additional 9 units of fuel into the Wren at idle, the inertia of the rotor prohibits an instantaneous increase in the RPM, and the EGT spikes a bit. Not the best answer. So the ECU further slices the initial fuel delivery into a slope similar to the left curve. Once the rotor responds and the turbine accelerates, the profile becomes benign and fuel can be aggressively delivered.
Bill's KJ seemed to have no trouble snapping out of a low RPM regime. His turbine can tolerate a shape similar to the one on the right. Fuel can be added much more aggressively, faster, than my Wren. Thus the ability to alter the shape of the curve with Pump Ramp Up Profile. Entered during SETUP (and accessible during RUN), the user can enter a value of from 1 to 12, with a 1 value being a gentler shape such as the one on the left, and a 12 being similar to the right-hand curve.
Why bother? If the turbine can handle the more aggressive profile, throttle response is improved and acceleration times are reduced. It all leads to my lengthy quest to create firmware which is adaptable to all model turbines.
When will it be ready!?? I am close! PLEEEEEEEEEEEZE be patient. As I mentioned on my home page, I am a hobbyist with normal work and responsibilities, and I cannot devote 100% of my time to this project. Thanks fellows.
15 Nov 01: The ECU has run 3 turbines so far, my MW54, Bill's KJ-66, and a borrowed RAM 500, all with great success. Bill initially experienced some hard starts and torchings, which were caused by an exceptionally powerful fuel pump. This particular pump was running his turbine over a very narrow output range, which means that even minute adjustments of the pump caused large changes in RPM. By choking the output of the pump slightly, and modifying the code somewhat, Bill's KJ was up and running, and as of this date has had many, many consecutive runs with great success. Posted below are Bill's programmed values, and the post-flight data showing how the ECU handles the KJ-66. The data is either reported log data or timed observations.
|Idle RPM||Max RPM||EGT Max||Accel Up Time||Decel Down Time|
|Programmed Setting||40K||100K||700||Ramp Up = 12||Ramp Dn = 6|
|Post-Flight||-||100K||685||4.0 - 4.5s||3.0s|
We were both happy to see how well the ECU handles throttle bursts both up and down, keeping both RPM and EGT within limits.
Accessories: While the LCD Data Display is very compact and can be flown with ease, we realize that many pilots would rather forego carrying the weight, and a system is needed to allow users to see turbine status at a glance. To satisfy this requirement, we are designing a direct, plug-in replacement for the LCD display which will consist of a set of LED's, one each green, amber, and red, which can be mounted in a model's canopy or any other convenient location. The LED's will be used for both start cues and turbine status. The pressure module is still in the conceptual stage and will take some time to develop, but will be a boon for those desiring a pressure-only system rather than a tachometry system.
23 July 01: My neighbors are going to lynch me with as much bench running as I have done in the last couple of months. Everything seems to be falling in place. There are some last-minute glitches, but nothing insurmountable. I did discover that the ECU requires the use of an ungrounded type k probe. Thermocouples come in 3 flavors: grounded, ungrounded, and exposed junctions. The junction is where the two dissimilar metallic wires are welded to form the "tip" of the thermocouple, and this is where the voltage is generated proportional to heat. My ECU uses an AD595 chip to measure the EGT, and the 595 has a handy "open thermocouple" detector which can tell the ECU if the TC is burnt out or unplugged. This detector works great but only if the TC is of the ungrounded variety. Basically, this means that the TC wires inside the sheathe are electrically isolated from said sheathing. If the wires contact the sheathe (a grounded probe) and the sheathe makes contact with the turbine exhaust cone, the EGT signal is grounded through the glow plug ground and the ECU reports an Open TC error. I have purchased a couple of ungrounded probes and these work fine. I will offer some special ungrounded probes in a 4" proble length which is perfect for the MW54 on the online store.
If you want to use your own type k probe, you must verify whether it is a grounded or ungrounded junction. To do this, you will need an ohmmeter. Measure the resistance between the probe's sheath and the pins of the TC's socket. If the resistance is just a few ohms, the probe is a grounded junction; if the resistance is several MOhms (millions of ohms) or greater, the probe is ungrounded and suitable for use.
This issue is not critical as ungrounded probes cost just a couple dollars more than the grounded variety. It is simply something which users must be aware of.
Oh yes, I have discovered that the socket used for the LCD, a Molex C-Grid connector (kind of a locking R/C style jack) is excellent in every way, but the force required to plug and unplug the LCD display is high enough to cause wear on the cable. After the first half-dozen ECU's go out, the LCD connector will be replaced with a 6-pin mini DIN plug identical to a PS2 mouse connector, with the female plug being attached to the ECU with a short run of cable, and the LCD display plug being of greater length. This will allow the data terminal to be attached and reattached with ease and with less stress to the ECU board.
One other improvement is in the appearance of the LCD display... the 4 phillips head screws seen in the pictures below were initially required to hold a cast plastic bracket which nests the pushbuttons and the LCD board. This was re-engineered to eliminate these screws, allowing a much neater appearance.
28 May 01: Updates, updates; much of the work in the last month has been in sourcing parts, CAD drawings of the necessary case cutouts, and especially refinement of the RUN ramping of the fuel to the engine. It was easy to make an ECU which would safely drive the engine with slow throttle response, but to get really crisp performance required some imaginative and effective coding. I have reached a point in this coding where I am confident users will be pleased with throttle response.
for the quality of these photos... I just wanted to get
some pictures up. To the far left is the ECU and
companion LCD display, shown together in my hand for a
relative size comparison. The slot cut into the ECU on
the left edge is for my prototyping only - it allows me
to sneak in a cable and reprogram the microprocessor.
To the right are the outputs (and battery in) of the ECU. From left to right are propane solenoid output, fuel pump drive, and glow plug drive. These make use of locking connectors for security and reliability.
photo shows the ECU inputs. From left to right: R/C input
(optically isolated), tachometer, and the 6-pin connector
for the LCD Display. The yellow jack is an industry
standard miniature thermocouple plug.
The bottom photo is a crude prototype of the LCD display, showing a rough idea of what the user will see when the engine is running. To make this photo, I attached my LCD display to my breadboarded ECU which does duty as a synthetic engine, which means that all the inputs are generated electronically, specifically the EGT and RPM signals. This lets me test all sorts of wild failure scenarios without risking my turbine!
Top Line: RPM
(thousands), EGT, Pump output.
The final ECU will replace the Pump output with battery voltage on the display, but for testing purposes, the pump output is more important to me.
I have received 100 of the final printed circuit board from Express PCB, and the quality is outstanding. These boards are fully solder masked and excellent in every way. Many small PCB refinements were made over the original PCB, and the new board has been tested successfully to verify the traces and functionality.
Tachometry: there are many different ways to successfully measure the engine's RPM. The best of these is, I believe, sensing via a Hall effect transducer... see the online manual for details. But I realize too there are a lot of guys who simply want to use case pressure. To accomodate these enthusiasts, I am developing a separate pressure sensing module which will plug directly into the ECU TACH IN port. This module will be quite compact and packaged like an electric R/C speed controller with shrink-wrap tubing as a "case". During ECU setup, the user will specify which type of RPM sensing to use. In the case of the pressure sensor, the sensing module will have a barb which will of course be attached to the engine's compressor output. Inside the pressure sensing module, the pressure output is converted to a voltage, which is sampled by a dedicated microprocessor (the PIC 12C672). This uProcessor, in turn, will use either mathematical manipulation or a simple "look up" table to derive an appropriate RPM given the current case pressure. This RPM value is sent to the ECU serially, and the user sees an "RPM" display indistinguishable from a true RPM transducer. Of course the accuracy is not as good as a true RPM sensor, and the engine would best be derated 5000 or 10,000 RPM. Each pressure sensing module will need to be programmed for a specific RPM/Pressure mapping, so that there would be a "KJ-66 pressure sensor" and a "MW-54 pressure sensor", etc. All I need to program the module is a curve of RPM vs Case Pressure. This is normally provided by the engine designer, or can be derived by experimentation.
For those patiently awaiting price, delivery, etc, please bear with me. I want this ECU to be reliable, easy to use, safe, and affordable. Thanks! And I'll try to update more often too.