超级盾 发表于 2016-5-20 11:25:28

5bears制作的ECU控制器

本帖最后由 超级盾 于 2016-5-20 11:28 编辑

前面为纪念WREN发了一个《5bears制作Wren MW54涡喷发动机》的帖子,这里再转帖一下他制作ECU的纪录。

几点说明:
5bears制作ECU已经是十几年前的事了,转帖过来只是给大家一个参考而已;
帖子里不会有制作教程;
处于不同阶段的朋友看完会有不同的收获
原文是英文,这里也不做翻译了,如果确实读不懂又不愿意使用翻译工具,兴趣又不是那么高,就不用继续往下看了。


下面开始:

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.




作者消息更新(最后更新是2002年)

ECU News 19 Feb 2002: Adventures inwireless turbine data transfer have been posted.3 Feb 2002: Minor and modest revisions to the basic ECUcontinue. I am on version 150 as I write. Everything is runningwell. The PDF documentis still accurate except one additional user-defined value hasbeen added... the ability to adjust the accel ramp shape.Accelerating a gas turbine from a stable RPM is a complex processwhen done in a manner which precludes EGT spiking, especially atlow RPM. Early versions of the firmware would initially (andgently) accelerate the rotor from its stable RPM by incrementingthe 10-bit Pump PWM over a short period before allowing theacceleration profile to take over and really drive the turbine tothe commanded setting. This worked best for my MW-54. BillBlackburn's KJ-66, on the other hand, could skip this process, soI added coding which allows the user to define the shape of theinitial acceleration profile.This drawing is pretty crude but perhaps it willbe helpful. The vertical axis is the amount of fuel added as timepasses to accelerate a turbine to a targeted setting. The overallheight of the curve is set with Pump Ramp Up insetup. Pump Ramp Up defines how long the acceleration profiletakes from a given RPM to a higher RPM. The new user setting iscalled Pump Ramp Up Profile, and determines howthe curve (until it reaches its peak value) is shaped. Note the left hand curve, which is suitable formy thrust MW54. Assuming the turbine is idling at a pump settingof 30 (using 8 bits in this example), and max RPM occurs at apump setting of 165, I snap the throttle from 0% to 100%. The ECUdetermines the pump delta, the difference between 30 and165, which is 135. It then examines the value of Pump Ramp Up. Ata Pump Ramp Up of 16, the profile is designed to accelerate fromidle to max in ~ 4 seconds. It then slices the pump delta intosegments, and begins to add these segments (over 4 seconds) tothe current pump setting until the desired pump target isobtained. For this example, let's assume that the software slices135 pump units into 15 segments, resulting in an increase of 9units of fuel per addition: 9 X 15 = 135. If I simply slam anadditional 9 units of fuel into the Wren at idle, the inertia ofthe rotor prohibits an instantaneous increase in the RPM, and theEGT spikes a bit. Not the best answer. So the ECU further slicesthe initial fuel delivery into a slope similar to the left curve.Once the rotor responds and the turbine accelerates, the profilebecomes benign and fuel can be aggressively delivered.Bill's KJ seemed to have no trouble snapping outof a low RPM regime. His turbine can tolerate a shape similar tothe one on the right. Fuel can be added much more aggressively,faster, than my Wren. Thus the ability to alter the shape of thecurve with Pump Ramp Up Profile. Entered duringSETUP (and accessible during RUN), the user can enter a value offrom 1 to 12, with a 1 value being a gentler shape such as theone on the left, and a 12 being similar to the right-hand curve. Why bother? If the turbine can handle the moreaggressive profile, throttle response is improved andacceleration times are reduced. It all leads to my lengthy questto create firmware which is adaptable to all model turbines.When will it be ready!?? I amclose! PLEEEEEEEEEEEZE be patient. As I mentioned on my homepage, I am a hobbyist with normal work and responsibilities, andI cannot devote 100% of my time to this project. Thanks fellows.
15 Nov 01: The ECU has run 3turbines so far,my MW54, Bill's KJ-66, and a borrowed RAM 500, all with greatsuccess. Bill initially experienced some hard starts andtorchings, which were caused by an exceptionally powerful fuelpump. This particular pump was running his turbine over a verynarrow output range, which means that even minute adjustments ofthe pump caused large changes in RPM. By choking the output ofthe pump slightly, and modifying the code somewhat, Bill's KJ wasup and running, and as of this date has had many, manyconsecutive runs with great success. Posted below are Bill'sprogrammed values, and the post-flight data showing how the ECUhandles the KJ-66. The data is either reported log data or timedobservations.
Idle RPMMax RPMEGT MaxAccel Up TimeDecel Down Time
Programmed Setting40K100K700Ramp Up = 12Ramp Dn = 6
Post-Flight-100K6854.0 - 4.5s3.0s
We were both happyto 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 beflown with ease, we realize that many pilots would rather foregocarrying the weight, and a system is needed to allow users to seeturbine status at a glance. To satisfy this requirement, we aredesigning a direct, plug-in replacement for the LCD display whichwill 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 convenientlocation. The LED's will be used for both start cues and turbinestatus. The pressure module is still in theconceptual stage and will take some time to develop, but will bea boon for those desiring a pressure-only system rather than atachometry system.23 July 01: My neighbors are goingto lynch me with as much bench running as I have done inthe last couple of months. Everything seems to be falling inplace. There are some last-minute glitches, but nothinginsurmountable. I did discover that the ECU requires the use ofan ungrounded type k probe. Thermocouples come in 3flavors: grounded, ungrounded, and exposed junctions. Thejunction is where the two dissimilar metallic wires are welded toform the "tip" of the thermocouple, and this is wherethe voltage is generated proportional to heat. My ECU uses anAD595 chip to measure the EGT, and the 595 has a handy "openthermocouple" detector which can tell the ECU if the TC isburnt out or unplugged. This detector works great but only if theTC is of the ungrounded variety. Basically, this means that theTC wires inside the sheathe are electrically isolated from saidsheathing. If the wires contact the sheathe (a grounded probe)and the sheathe makes contact with the turbine exhaust cone, theEGT signal is grounded through the glow plug ground and the ECUreports an Open TC error. I have purchased a couple of ungroundedprobes and these work fine. I will offer some special ungroundedprobes in a 4" proble length which is perfect for the MW54on 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 resistancebetween the probe's sheath and the pins of the TC's socket. Ifthe resistance is just a few ohms, the probe is a groundedjunction; 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 ungroundedprobes 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 socketused for the LCD, a Molex C-Grid connector (kind of a locking R/Cstyle jack) is excellent in every way, but the force required toplug and unplug the LCD display is high enough to cause wear onthe cable. After the first half-dozen ECU's go out, the LCDconnector will be replaced with a 6-pin mini DIN plug identicalto a PS2 mouse connector, with the female plug being attached tothe ECU with a short run of cable, and the LCD display plug beingof greater length. This will allow the data terminal to beattached and reattached with ease and with less stress to the ECUboard.One other improvement is in the appearanceof the LCD display... the 4 phillips head screws seen in thepictures below were initially required to hold a cast plasticbracket which nests the pushbuttons and the LCD board. This wasre-engineered to eliminate these screws, allowing a much neaterappearance.28 May 01: Updates, updates; muchof the work in the last month has been in sourcing parts, CADdrawings of the necessary case cutouts, and especially refinementof the RUN ramping of the fuel to the engine. It was easy to makean ECU which would safely drive the engine with slow throttleresponse, but to get really crisp performance required someimaginative and effective coding. I have reached a point in thiscoding where I am confident users will be pleased with throttleresponse.
I apologize      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.
      


      The top      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.
      Bottom line: Run Mode/Fault annunciation, commanded      throttle setting in %, and 3 dashes which show the status      of gas solenoid, starter motor, and Glow, currently all      OFF.
      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 printedcircuit 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, andthe new board has been tested successfully to verify the tracesand functionality.Tachometry: there aremany different ways to successfully measure the engine's RPM. Thebest of these is, I believe, sensing via a Hall effecttransducer... see the online manual for details. But I realizetoo there are a lot of guys who simply want to use case pressure.To accomodate these enthusiasts, I am developing a separate pressuresensing module which will plug directly into the ECU TACH INport. This module will be quite compact and packaged like anelectric R/C speed controller with shrink-wrap tubing as a"case". During ECU setup, the user will specify whichtype of RPM sensing to use. In the case of the pressure sensor,the sensing module will have a barb which will of course beattached to the engine's compressor output. Inside the pressuresensing 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 mathematicalmanipulation or a simple "look up" table to derive anappropriate RPM given the current case pressure. This RPM valueis sent to the ECU serially, and the user sees an "RPM"display indistinguishable from a true RPM transducer. Of coursethe accuracy is not as good as a true RPM sensor, and the enginewould best be derated 5000 or 10,000 RPM. Each pressure sensingmodule will need to be programmed for a specific RPM/Pressuremapping, so that there would be a "KJ-66 pressuresensor" and a "MW-54 pressure sensor", etc. All Ineed to program the module is a curve of RPM vs Case Pressure.This is normally provided by the engine designer, or can bederived by experimentation.For those patiently awaitingprice, delivery, etc, please bear with me. I want thisECU to be reliable, easy to use, safe, and affordable. Thanks!And I'll try to update more often too.

作者给出的参考链接
microEngineering Labs,Inc.
MCUmart.com Online Store
Microchip Technology Ince
BASIC Compilers for the PIC microcontroller
Basic Micro
PicBasic Pro,PicBasic,Basic Stamp,PIC Micro,and 8051 Microcontroller Projects



超级盾 发表于 2016-5-20 11:33:41

Simple Circuits for an ECU


These remain here on my site although badly dated and not currently in use by my ECU. They were derived very early in my initial experiments. They remain only for general interest.

The original plans for the ECU called for a very simple unit designed to keep the engine within parameters. I was going to use a Basic Stamp 2, a pressure transducer, and a thermocouple. As work progressed, I realized that greater functionality could be obtained with a proper tachometer, and the use of a faster, more capable, compiled Microchip controller. I will leave these circuits posted, but the final ECU will make much greater use of the inherent capabilities of the PIC16F876, 28-pin microcontroller, especially for tasks like driving the pump and the glow plug.

While I have some experience with programming, I rank myself just a notch above beginner with electronics theory. I am teaching myself this stuff as I go. If anyone reading this page finds fault in these circuits or descriptions, please email me, I will be grateful!

For Parts, 99% of these can be purchased on line from DigiKey or simply try Radio Shack. Don't skimp on the MOSFETS, the specified MOSFETS have a very low on-state resistance which is important for power dissipation. For a more compact MOSFET, look at the International Rectifier "I-Pak" MOSFETS.



Circuit 01: A mV Source for Thermocouple simulation

I realized early that for prototyping and troubleshooting, I would require a millivolt source which can simulate a type K TC. For now, this circuit is what I devised. When the ECU is complete, I will do final calibration with a lab-grade TC simulator, and develop software interpolation of the non-linear curve. But to simply create the Op-amp interface to amplify the signal, this little circuit seems to work quite well. It is mounted on a 2" square PC board with a 9V battery. I used a 10-turn 1K pot (expensive). A normal pot will work fine. Vary the 120K resistance to increase or decrease the mV signal range. In this configuration, it will output a fairly stable 0 to 40 mV.



The EGT probe, without getting into too much thermocouple theory, is a bimetal junction which delivers a non-linear millivolt signal as the junction's temperature rises. A type K thermocouple will generate roughly 33 millivolts at 800 degrees.

The unit can be plugged into a TC meter, and it will nicely deliver any temperature desired. Once "set", the unit can be then plugged into the BS2IC. By turning the pot, I can simulate ignition, normal running, and overtemps or flameouts to check the microprocessor's programming.


Circuit 02: A simple Thermocouple Amplifier

Continuing with the thermocouple interface concept, the next step is to amplify the TC's millivolt signal into a more readable analog voltage, on the order of 0 to 5VDC. This simple circuit fits the bill. The LM358N is a dual op-amp IC. I'm quite sure any op-amp IC would do fine, just be sure it can accept a Vcc which is compatible with your battery pack. The IC draws ~ 1.0 mA.

The resistors form a feedback loop into the op-amp, with a gain described in the schematic, and based upon the resistances R1 and R2. I used 100K and 1K respectively for the breadboarding, delivering a gain of roughly 100. This works well with the TC's range of up to 40 mV, with the output then being from 0 to 4VDC.



I was surprised to find the circuit as stable as it was. Wired to a 6V battery, I attached a speed 300 motor simulating the starter motor to the same V+ and ground. Initial spooling of the starter motor caused a small hiccup in the signal, but it quickly restabilized, and it shouldn't cause any problems in operation. The C1 (0.1 uF ceramic) is essential to minimize this interference.

The polarity of the thermocouple is important. If wired backwards, the circuit drops low and stays there, and could be confused with an operating TC at room temperature. A more elegant solution would be to offset the output so that if wired backwards, the output would deliver 1.0VDC, with the upper limit now 5VDC rather than 4.


Circuit 03: A precision T/C Amplifier with cold junction compensation for the BS2

This circuit greatly expands upon the capabilities of circuit 02. A thermocouple signal is quite small, and the long thermocouple leads often induce quite a bit of noise into the system. This new circuit is far more accurate, stable, and less immune to noise. It makes use of a Linear Technologies LT1025 chip to provide CJC (Cold Junction Compensation), an LTC1098 8-bit 2-channel Analogue to Digital Converter, and an LTC1050 chopper amp. The feedback resistors are designed to deliver 5V (full scale signal) to the ADC with a 1000 degree C. Type K signal. The 1050 is a great amplifier, delivering "rail to rail" output which makes powering the circuit simple.



This circuit is far superior to the basic op-amp circuit shown above, but is still complex. The actual EGT section of the ECU has been replaced with an Analog Devices AD595 IC.


Circuit 04: An Op-Amp based battery voltage monitor

An ECU must have a way to monitor battery voltage. Here is a simple op-amp based circuit which will illuminate the LED when the battery voltage drops to a certain level. The turn-on point is set with R2. You must be able to vary Vcc (usually with a good power supply) to set the circuit. Decide at what voltage you'd like the LED to illuminate, and apply this at Vcc. Adjust R2 until the light just illuminates. Use an LED which will light at the desired voltage level, and determine R3, using ohm's law (E=IR), to keep the current flowing through the LED and op-amp to around 10mA.

The LM324 will draw 0.8 mA with the LED out. With the LED on, current will increase to that determined by your selection of R3, with lower being better, of course.




Circuit 05: A Logic-Level actuated gas solenoid for starting propane

Despite exhaustive searching, every reasonably priced solenoid valve for controlling propane during pushbutton start required 12VDC, beyond the capabilities of a normal pump battery. I know that there are methods to generate HV pulses which will actuate the solenoid, which will remain closed down to below 5V, but I went the more expensive and reliable route with a DC-DC converter, shown here, the Newport NMR101. R2 is 10K, and R3 is 100K. R1 is 39 ohms. Vary R1 to acheive reliable closing of the valve and to keep current to ~90 mA through the solenoid. The converter will draw 260 mA from the 5V source.



A diode clamp across the solenoid (not shown) might not be a bad idea.

The MOSFET (IRLD014) is a logic-level, 4 pin DIP package. A 5V logic high from the CPU will actuate the circuit, with less than 1mA at the gate.


Circuit 06: A Logic-Driven adjustable Glow-Plug driver for 5 to 12VDC

All of my turbine starts before the research on the ECU involved a very successful spark ignition. I thought (only briefly) of trying to add spark ignition to the ECU, but the mixture of delicate logic circuitry and perhaps 30,000V simply don't mix. My past experience with the hall sensor ignition for the radial engine bears this out in painful detail. So I decided to go with a glow-plug driver.

I claim no great originality to this circuit... it is a modified PWM motor driver which happens to work, after the minimal mods, with a glow plug. The heart is a 556, which is a dual 555 timer chip. Timer #1 is the oscillator, and timer #2 actually drives the MOSFET, with the transistor circuit determining the duty cycle.

5V Logic HIGH from CPU enables circuit, Logic LOW disables. R15 will adjust plug, be sure output is fully low (Use DVM on pin 5) before attaching plug, then adjust trimmer pot for correct drive



Uses a dual 555 Timer package to oscillate and PWM-drive an advanced MOSFET. Tie pins 4 and 10, 6 and 9 together.

Note: ECU Glow drive is now accomplished with hardware PWM from the PIC16F876! Only 3 components necessary!
R14,16 - 470
R15 - 10K Trimmer
R17 - 8.2K
R18 - 100
R19 - 100K
R20 - 33K
R21 - 2.2K
R22 - 22K         Q3 - Any cheap NPN Switcher, hFe ~ 150
Q4 - IRL3705N (Digi-Key)
C18 - 0.1uF Ceramic
All Other Caps - 0.01 uF Ceramic
556 - Dual 555 Timer (any Radio Shack)

超级盾 发表于 2016-5-20 11:35:38

ECU Manual (PDF)下载






超级盾 发表于 2016-5-20 11:39:06

PC Board Art (A Work InProgress!)

Far harder than I expected was the layout of the PC board(s) and the planning of how the components, fasteners, and connectors will all come together. I have bought perhaps a dozen different cases and rejected almost all of them for one reason or another. The first three boards show the evolution of the project from concept to final board . Boards 2 and higher measure 80mm X 52 mm. The latter 2 boards are conceptual and have not been etched.

The blue traces are the bottom side... the red traces are on top of the board. Yellow silkscreen outlines show the component placement.


Board 1: This board includes a pressure transducer which has since been eliminated. it can be seen as an outline to the upper left. My skills at layout and creating logical, clean traces is a joke. While this board would probably work, it would be prone to interference, and the sheer number of components makes failure of an individual component more likely. Simpler is often better!



Board 2: MUCH better! I haven't wired up the PIC uController, but 90% of the components are in place. Molex C-grid connectors will make attachment of external devices a cinch. The three identical clusters are the I-Pak MOSFETS and support components. The cluster above the 28-pin DIP is the AD595, "Thermocouple meter on a chip", which replaces a much more complex thermocouple interface on the first board.



Board 3: An evolution of board 2, above. This is the final board for what we call "PCB Mark 1". An order was placed with Express PCB for a large number, which turned out to be excellent and functionally perfect, no jumpers or corrections to the layout required.

The upper row holds the input section, with jacks for RC, tach, and LCD out. Below these is the uController, still a PIC16F876. 3 MOSFETS can be seen to the right of the PIC's 28 pin DIP layout; these control Pump, Glow, and Starter circuits, with corresponding output jacks on the right edge of the board. Power-in components occupy the lower right portion. The EGT section is to the lower left, to keep its sensitive circuitry as isolated as possible from the noise of the outputs. Note the blue ground plane around this critical area.

Obviously a densely populated board. All of the components are through-hole, making it feasible to produce this ECU as a kit.

Through hundreds of hours of bench testing and live running, no failures of any components have been noted!



Board 4: After a lot of thought on safety and hardware. I designed this dual-processor ECU. The only common components are power supply. The uControllers run independently of each other. uProcessor #2 is a PIC16F628, whose functions include gathering external data (R/C and RPM) and sending this data serially to the primary controller, a PIC16F876. Its secondary function is to monitor the "health" of the primary processor... in the event of a primary processor failure, the PIC16F628 can secure the pump by triggering a fuse device. The MOSFETS have been placed vertically to save room, as they run quite cool.

The plain 7805 5V regulator has been replaced with a superb Texas Instruments 5V LDO (Low Dropout) Regulator, which assists in brownout prevention during high-amperage motor starts. Another output has been added; a fuel solenoid port. Both the fuel solenoid and gas solenoid are controlled with a high-side dual FET switch, eliminating a bunch of components.

Compare the size of the uProcessor layout with board 3. The only way to cram these components onto this board is to switch to a number of surface mount devices, which certainly save space but make kit potential a bit tricky. To help further my ability to use SMD components, I acquired a Hakko 850 hot-air rework station.

This board is still conceptual and has not been produced.



Board 5: Pushing size and functionality to the limit! The massive object center-left is a Linx SC-PA tranciever for a wireless link to a data module on the ground! Lots of testing of this concept to go (range? interference? legality?) but the potential is very cool. Being able to monitor critical parameters inflight would be a boon. An audible alarm on the data display could alert a pilot to a turbine/ECU problem in real time.

RadioMetrix in the U.K. has a better solution in its TX3/RX3 combination, allowing legal use in Europe at 868 MHz, and the U.S. market at 914 MHz. In typical U.S. fashion, the U.S. version would require FCC approval of the final design, a process which would cost ~$2,500. Ouch. But the European version at 868 MHz is pre-approved without further testing. This whole wireless concept is something that I would like to pursue.

超级盾 发表于 2016-5-20 11:45:10

Wireless Turbine Data Transfer

Gathering and displaying critical turbine data has always been somewhat of a weakness for all turbine ECU's. Once your precious model is underway, one must simply trust that all will go well, and the ECU will handle unforseen problems. Generally, it will, and will do so efficiently. But being human, we'd like to see, in real time, exactly what is happening... hence, my desire to test some basic telemetry.

Quite a bit of time was spent checking legality, cost, and the availability of "plug and play" RF modules. Plug and play is certainly a misnomer, as all except the most expensive and bulky RF modules do not handle error correction, and this is the hardest part in implementing a telemetry scheme.


My current ECU design has the programming pushbuttons on the LCD display. To avoid the hassles of duplex (2-way) communication, these were moved to the ECU. Now, there need only be a single transmiter and reciever pair for data transfer. The circuit board from "PC Boards for the Masses" was used for both the transmitter and reciever boards. To make the tests valid, I created copper ground planes (antenna counterpoise) which were similar in size to the projected finished product. Simple 1/4 wave whips were used for both devices. The first tests were made without any form of packetization.

Let me digress and explain radio packets. We know digital data, if even one bit is corrupt, can become useless garbage. A scheme is necessary when using wireless serial data transfer to verify the integrity of the data. First, a pair of unique ID bytes is transmitted, such as 123, 123. This is followed by a fixed number of data bytes. Last comes the checksum, which is nothing more than all of the previous bytes added together, presented as a 16-bit "word" value.

For example, let's say the RPM is 35, EGT 474, Pump 0, throttle 0%, and a No R/C fault exists as shown here in this picture. The data packet looks like this:

ID, ID, RPM, EGT.HighByte, EGT.LowByte, Pump, Throttle, FaultStatus, Checksum.HighByte, Checksum.LowByte

On the rx end, the recieving PIC processor waits until it "sees" ID, ID, come in over the ether. It then digests 8 more bytes of data. It strips the last two bytes, and converts them to a 16-bit value. Adding up the appropriate bytes, it sees if its own checksum value matches the recieved value. If it does, the data packet is valid and may be used. If not, it rejects the packet as corrupt, and waits for the next. In practice, this simple checksum error handling works very well.


A closeup of the reciever module. The device measures ~ 1.7 inches by 0.7", 5VDC, TTL serial output into a PIC16F876. The PIC procesor handles packetization. Without it, the output of the RX3, when fed directly into a serial LCD module, is loaded with hash and spurious characters, and is unuseable.

Range tests were promising. When the transmitter was sited inside my house, I was able to walk outside and obtain valid data updates of 1 per second up to 120 meters. With an airborne transmitter and an optimized RX antenna, the range may be enough to obtain decent data up to 300 meters. Beyond this, I have no idea. I am guessing that inflight, valid data could be obtained with closer passes to the pilot, but continuous coverage is impossible without higher (illegal) power output.


The Transmitter module, smaller by ~ 35% than the rx module. The 3 buttons normally located on the LCD display can be seen, as well as the simple plug which connects directly to the ECU. The only ECU modification is some firmware massage which packetizes the data.

In summary, the serial transfer of turbine data (telemetry) is very possible. My big problem is the fact that my ECU right now uses the LCD for programming; this transfers large amounts of text which is not suitable for packets, and makes the wireless modules useful for only turbine performance data. A complete, wireless-only setup would require weeks of coding to implement. One method which might be used is a set of TX/RX modules which simply "severs the cable" between the ECU and the LCD display. In doing this, the modules would not be able to program the ECU. To program, the modules would be unplugged, and the cable between the ECU and LCD restored. Once programming is complete, the RF modules would again replace the cable, and allow inflight data transfer.


This may not be a bad way to implement this process. One final huge gripe is the requirement for FCC certification for use in the U.S. The European community allows non-specific SRD's (Short Range Devices) to operate on certain bands without special certification. The U.S. certification requirement can cost thousands of dollars! Grrrr.

超级盾 发表于 2016-5-20 11:48:56

本帖最后由 超级盾 于 2016-5-20 11:51 编辑

PicBasic code samples
两个代码例子


1Asynchronous PWM for Pumps, Glow Plug Drive, etc

Any turbojet ECU will require as a minimum a controllable fuel pump, and sometimes an adjustable glow plug driver. The traditional technique for varying a DC motor is by using PWM (Pulse Width Modulation), whereby a pulsed signal's duty cycle is varied, causing the device (in this case an advanced MOSFET) to switch on and off very rapidly. This in turn effectively varies the voltage which the target device sees. A benefit, especially for a motor, is that torque at low speeds is improved over a resistive setup, and the efficiency is much greater.

A microcontroller can produce PWM in 2 ways... it can be dedicated to PWM output, which means that it will have essentially no additional time to process other parameters. Or, it can have contained within it a Timer module which allows continuous PWM output while the processor clock can effectively perform other functions without causing gross interruptions in the PWM output.

The PIC16F876 conveniently has two PWM output modules, one of which can control a pump, the other controlling a glow plug driver. The PWM output is fed through a diode and resistor and delivered to the gate of an N-MOSFET capable of "turning on" at logic voltage levels. The MOSFET must additionally have a resistor from gate to source (ground), or the MOSFET will latch "on" with the first pulse from the uController.

This code, when compiled and loaded into the PIC, generates a PWM output suitable for both a Speed280/300 style pump or a glow plug.

'This program is designed to explore the PWM characteristics
'of the 16F876 for motor or Glow excitation.Buttons one
'and 2 are Active Low and are wired to PortB 3 and 4 using
'2 10K pullup resistors.The LCD is a Scott Adams Serial LCD
'module.Compiled with PicBasic Pro and MPASM.

'For MOSFETs, I highly recommend the compact and efficient International
'Rectifier IRLU3103.For gate drive for a Speed 300/280 type pump, use
'a 10K resistor, with a 12K resistor gate to ground.Higher gate to ground
'resistance reduces resolution of the byte Duty Cycle variable.

'Clamp the Motor with a 10 or 12V 1/2W Zener.
'Experimentation is always in order.

INCLUDE "modedefs.bas"

PumpDC                var                CCPR1L
PumpOut                var                PORTC.2
PumpOn                con                %1111110      '16 Pre/Post scale
PumpOff                con                %1111010
PumpEnable      var                T2CON                'Timer2 ControlRegister

'See Scott Adams Serial LCD sheets for these commands
LCDOutPin                VAR                PORTB.2                '23 --> LCD
LCDCmd                CON                254                'LCD Command prefix
LCDHome                CON                2                'Move cursor home, Pause
LCDClr                CON                1                'Clear LCD screen, Pause
LCDLine1                CON                128                'First cell line 1
LCDLine2                CON                192                'First cell line 2

'Buttons, select any convenient I/O port.Buttons will change
'(and scroll) the Duty Cycle of the PWM from 0 to 255.
Btn1                var                PORTB.3
Btn2                var                PORTB.4

Gosub EnablePump                'Set required PWM/Timer2 registers
Gosub DisplayDC                'Initialize LCD


'Buttons, set for pull up, active low
TRISB.3 = 1: TRISB.4 = 1


'The buttons will increment or decrement the duty cycle
'by one within a range of 0 to 255.

SetDC:
      if Btn1 = 0 then
                if PumpDC < 255 then PumpDC = PumpDC + 1
                Gosub DisplayDC                              'Update LCD
                Pause 150                              'Button debounce/scroll rate
      Endif
         if Btn2 = 0 then
                if PumpDC then PumpDC = PumpDC - 1
                Gosub DisplayDC
                Pause 150
      Endif
Goto SetDC                'Loop endlessly polling for button presses
               




'Pump subroutines --------------------------------------------------

PumpEmergencyOff:                              'Sets throttle to zero, Kills timer2, and sets
      PumpDC = 0                        'Pump Drive pin to Low
      PumpEnable = PumpOff
      Low PumpOut                        
Return

DisplayDC:                                                'Display the current Duty Cycle of PWM on LCD
      SerOut LCDOutPin, N9600,       'Clear LCD
      Pause 2
      SerOut LCDOutPin, N9600,
Return

EnablePump:                        'Call once to enable PWM
      PR2 = $FF                'PWM Period
      PumpDC = 0                'Set DC to 0
      TRISC.2 = 0                'Set pin to output
      CCP1CON = %001100      'Set CCP Register for PWM
      PumpEnable = PumpOn      'Turn On timer
Return




2 R/C, Voltage, EGT, and Tachometry Inputs
The PIC16F876 has two analogue inputs which are ideal for sensing onboard battery voltage and an EGT output from the AD595 TC chip. The battery voltage is divided by two series, precision resistors, and the output fed directly into one of the two ADC channel pins. The AD595 is externally biased to keep the output below 5V, and a precision voltage reference, LM336, provides a stable 5V output for ADC comparison.

The RC and Tachometer are measured differently... the RC receiver controls a servo by varying pulse width, and this pulse width is easily measured with a single PicBasic Pro command, PULSIN. The tacho input is a different matter entirely... one cannot measure pulse width, as the width of the pulse will vary with the mechanics of the transducer. Instead, one must measure the number of pulses which arrives at the pin over a given period of time. If the uProcessor counts the number of pulses over a 60 millisecond period, the resulting number indicates the RPM in thousands. For example, 30 pulses in 60 milliseconds = 30,000 RPM. Resolution can be improved by taking a longer sample, but there is a tradeoff in that the uProcessor "hangs" while counting, and cannot monitor other functions. Three 60 mS samples generates a resolution of ~ 300 RPM, which should be more than adequate for a model turbojet, and consumes 0.180 seconds. Of course, a dedicated processor could get a much higher resolution and serially report the results, but this would greatly increase the complexity.

EGT is smoothed and can be software filtered for noise by taking a large number of samples and rejecting aberrant samples which do not fall into the normal range. Currently, this code takes 48 samples and averages the result. Using 8-bit sampling, resolution is +/- 4 degrees C, but the effect of the large sample number is to actually increase the resolution.

Getting the data is easy... the hard part is formatting it for display on the LCD!!



'****************************************************************
'*                                                              *
'*                        INPUTS.BAS                              *
'*                                                              *
'****************************************************************

'This code conglomerates all of the inputs to the PIC chip, including
'EGT, battery voltage, RC throttle inputs, and tachometry.


DEFINE        ADC_BITS        8
DEFINE        ADC_CLOCK        3                         'Uses internal RC clock
DEFINE        ADC_SAMPLEUS        10                        'Microsecond sample time

EGTChannel        con        1                        'Channel 1
VoltChannel        con             0                        'Channel 0

'ADC Variables
Voltage                var                Word                '0 to 1000, where 1000 = 10V
LCDVHigh                var                Byte                'Left of decimal place
LCDVLow                var                Byte                'Right of decimal place

NumSamples        con                 48                'Number of EGT samples to take, Max 254
EGT                var                Word                'Global EGT Reading
EGTSample                var                Byte                'Sample In from AD595
i                var                Byte                'Iterative tool




'Tachometry:RPMSM is the number of 60 mS samples to take.Each sample
'represents the actual tach output / 1000.Resolution increases with
'an increase in RPMNumSamps at the expense of shared processor time.An RPMNumSamps
'of 3 yields a resolution of +/- 400 RPM

'R/C Input:
ThrotPin                var        PORTB.2                'Pin 21, RC Throttle Signal
Throttle                var        Word                'Sample in from RC
TachPin                var        PORTB.1                'Pin 22, Pulled High, Active Low
RPMSamp                var        Word               
RPM                var        Byte                'High Byte for display and Globally used RPM reference       
RPML                var        Byte                'Low Byte for display               
RPMNumSamps        con        2                'Number of 60 ms Sample times to take


'ADC Subroutines
ADCInit:                                           'Call once to initialize pins and ADCON1 register
        EGT = 0: Voltage = 0               
        TRISA.0 = 1                        'Set chnl 0, 1, Vref to Inputs
        TRISA.1 = 1
        TRISA.3 = 1
        ADCON1 = %00000101                'Left Justified Results
Return


ScanInputs:

        'For global reference to system voltage, use the Voltage variable, which is based on a
        'scale of 1 to 1000, with 775 = 7.75 volts.Remember that the resistors on the board
        'divide the actual battery voltage in half so the ADC can "digest" it without damage.
        'ADCIN voltages are limited to 5.Both EGT and Voltage are compared with the onboard
        'precision voltage reference which delivers a perfect 5V.

       
        '**Voltage**
        ADCIN VoltChannel, Voltage                'Take just 1 voltage sample. 7.6V = 194
        Voltage = Voltage * 4                        '194 * 4 = 776
        LCDVHigh = Voltage / 100                '776 / 100 rounds to 7
        LCDVLow = (Voltage // 100) / 10        '776 // 100 = 76, 76 / 10 = 7
                                                'Final Display = 7.7

        '** EGT **
        EGT = 0                                        'Reinitialize EGT
        for i = 0 to NumSamples - 1
                ADCIN EGTChannel, EGTSample            '0 to 255 EGT sample
                EGT = EGT + ((EGTSample * 255) / 60)   'The equation gives the actual Celcius reading
        next i                                             'Add it all into EGT.

        EGT = EGT / NumSamples                        'Divide EGT by the Number of samples


        'Tach and R/C subroutines
        'The greater the number of samples taken, the better the resultion, at the expense
        'of processor time.More than 4 to 6 really slows the whole thing down.With three
        'samples or less, it might be best to simply display 1000's rather than XXX.X


        '** RPM **
        '60 ms Sample time yields direct RPM readout in 1000's
        'Comments start with real RPM of 143,578 and RPMNumSamps=3

        Count tachPin, 60 * RPMNumSamps, RPMSamp        'RPMSamp = 430
        RPMSamp = RPMSamp * 10                                'RPMSamp = 4300
        RPM = RPMSamp / (RPMNumSamps * 10)                'RPM = 143
        if not RPMNoDecimal then                        'Calculate the tenths if RPMNoDecimal = 0
                RPML = RPMSamp // (RPMNumSamps * 10)        'RPML = 10
                RPML = RPML /RPMNumSamps                'RPML = 3
        endif
                                                        'LCD output is thus 143.3

        '** R/C **
        'Measure the pulse width of the incoming RC signal
        Pulsin Throtpin, 0, Throttle

Return

超级盾 发表于 2016-5-20 11:57:58

附:简易电路板制作
Printed Circuit Boards for theMasses

Creating PCB's at home has always been a hassle. The basic methods available include manually laying out the traces with trace transfers (not recommended), photoreproduction (specialized, and expensive), or the use of a laser printer using the toner transfer method. This latter has been somewhat hit or miss for me, with variable results, until I did a bit of internet research and discovered an absolutely dynamite paper. All the credit goes to Tom Gootee for finding a paper that really works.

The procedure is simple. You need some Jet Print brand Photo paper, glossy. The stuff I bought was Jet Print Multi-Project Photo Paper, 07033-0. Jet Print color codes their inkjet photo papers... look for the stuff with the green band. About $0.75 per sheet here in Texas.

The next step is to produce a positive image of the traces you want, using almost any editor, CAD program, etc. The image must print to the exact scale needed.



Once the image is created, test-print the traces on a sheet of regular paper. You must use a laser printer; inkjet printers will not work. If it all looks good, load a sheet of the Jet Print into your printer tray, set your printer for darkest image, and print. Here is the image of my traces printed to the Jet Print paper.


Cut out the traces, leaving a bit of paper surrounding the traces as a border. Prepare your copper board by first sanding lightly in a cross-hatched pattern with 400 grit paper. Next, degrease and clean the copper with alcohol or similar.
My Jet Printed circuit is shown here next to a small, prepared board.


Borrow an iron from the house boss. Set it on its highest temperature, and allow it to warm up. Tack the paper down on one corner of the board. It will immediately begin to fuse and stick. Continue to iron the paper onto the board. Go ahead and use a bit of pressure. This 2" sq. board was ironed for about 3 minutes. Use the edge of the iron as well to apply higher pressure in a pattern. You can tell when you're done because you will actually be able to see the traces through the paper. Something in the heating process causes this phenomenon. Give it another minute for luck, then, drop the fused paper and board...


...into a bowl of hot water. It will immediately bubble and begin to separate from the copper. Don't rush things, let it soak for a good 10 to 30 minutes. You may need to help the paper separate a bit... it won't float free on its own. But if you used a good hot iron, you won't have any trouble with trace mask peeling off the copper. It really fuses well.


The PCB is ready to etch! Note the very clean image. No melting or blurring at all!


Into the ferric chloride etch. Keep an eye on it and agitate occasionally. A plastic fork is handy to lift and inspect the board.


The fused toner does a superb job. No creep of etchant under the mask is evident.


Here is a nice, close view of the etched board before the toner is stripped to reveal the copper. The pads in the lower left were originally octagonal, and they retain their shape perfectly.


The only reliable solvent to remove the toner is acetone. Other solvents such as xylol or alcohol work, but it is very slow!


This is the completed board. The copper looks tin-plated, but it is a trick of lighting... they are still copper. All that remains is drilling.


A super close-up. Note the clean traces and lack of pin-holes or etchant bleed. These are 20 mil traces.
Overall, a great way to make simple PCB's at home with confidence!

轴流涡喷暴走了 发表于 2016-7-30 23:09:34

赞一个!!!赞一个!!!赞一个!!!没翻译看不懂

HY5IHY 发表于 2016-10-21 10:35:00

学习了,谢谢!!

星魂 发表于 2017-7-13 09:33:26

赞一个!!!
页: [1] 2
查看完整版本: 5bears制作的ECU控制器