Wireless Turbine Data Transfer
5 Bears Home
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.

Actual RX display! 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.

The RX module 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 TX Module 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.

TOP | 5 Bears HOME