This is mostly stuff I have learned very recently, so feel free to correct anything I have wrong.
John Carmack, 12/10/00
Family Radio (FR) devices, like the cheap Radio Shack ones, are capable of running data telemetry, but the legality is questionable.† They are limited to .5 watts and non-detachable antennas, so the range isnít really useful anyway.
Multi Use Radio Service (MURS) was just made available in November 2000, allowing license free data communication on five channels.† It is limited to two watts of power, but can use external antennas.† http://www.provide.net/~prsg/murs_faq.htm
Amateur (ham) radio is almost certainly still the way to go.† You get lots of band options, and license to use more power than you are going to cram into a rocket.† Getting a no-code technician license is easy, and I learned a thing or two while studying for it.† http://www.arrl.org/
Most telemetry work is done on the 2m and/or 70cm bands with FM radios, but there are other options used for some satellite and HF modes.
Higher frequency bands draw more battery power for a given radiated power, but allow smaller antennas.
Normal radio communication is half duplex, meaning that only a single part can talk or send data at one time.† For purely one-way communication, like just dumping a single sensor or GPS output over a radio channel, this isnít a problem.
If any information needs to be passed back from the ground station to the rocket, the rocket must stop sending data at regular intervals and listen to see if a command is being sent.
This implies much more overhead than it sounds like.† Radio transceivers cannot instantly switch from receiving to transmitting, it takes some time to decide to open the squelch, and it takes some time for the radio modem to lock on.† This adds up to nearly an entire second of overhead in standard configurations.
Even in a simple situation, you may need a back channel to ask for retransmits of corrupted data or to select between multiple sources of data, and serious rockets are going to want an abort command option and backup recovery system commands.
One of the projects we are working on involves remotely piloting a small VTVL craft with a joystick, so I need very high (10-20/sec) command counts and low latencies.
If you just want to send a steady stream of data from the rocket, and allow for an occasional uplink command, normal half duplex telemetry configurations can be configured so that the overhead is reasonable.† If you are sending large packets (which increases the error chance), you may be able to get up to 50% or so of the rated channel bandwidth.
If you need either more bandwidth or lower round trip latency, you need to go to a full duplex link.† This requires either two separate radios, or a simultaneous dual band radio that can transmit and receive at the same time (many dual band radios arenít simultaneous).
Besides the actual overlapping of transmissions, this allows the receive side to keep the squelch open continuously, and the transmit side to send a carrier continuously, which removes the large half duplex switching overhead.
With a link level protocol optimized for this, you can use 100% of the bandwidth, and have packets separated by a single framing byte.
Each side of a telemetry system will need some combination of the following elements:
Transmitter and receiver, usually combined into a single transceiver.
A radio modem, which turns a bit stream into a modulated signal, returns a Data Carrier Detect (DCD) state for the receive channel, and controls the push-to-talk (PTT) on the transmit channel.† Most radio modems are only half duplex, so full duplex requires two radio modems.
The Terminal Node Controller (TNC), which performs housekeeping functions like determining when to transmit, and dividing the serial byte stream into framed bit streams.† The TNC is often referred to as the DCE in serial communication, for Data Communication Equipment.
The computer that is communicating data, often referred to as the DTE in serial communication, for Data Terminal Equipment.† The selection of the flight computer is a whole other complicated decision, ranging from basic stamps to microcontrollers to PC104 single board computers.
A worst-case full duplex situation would have seven boxes: transmitter, receiver, transmit radio modem, receive radio modem, transmit TNC, receive radio modem, and computer.
The common situation would have three boxes: transceiver, TNC with integrated modem, and computer.
There are two possibilities for reducing it to two boxes: a transceiver with integrated TNC and modem (Kenwood D7AG http://www.kenwood.net/ama_page.cfm ) connected to a computer, or a transceiver connected to a computerís sound card with the radio modem and TNC functions performed in software.
1200 baud communication is usually done with Audio Frequency Shift Keying (AFSK), but some satellites use Phase Shift Keying (PSK), which is supposed to be less susceptible to noise.
There are 2400 baud modems that use Minimum Shift Keying (MSK).† I have seen conflicting reports on whether this can work through normal audio inputs and outputs.
9600 baud communication is done with either direct (not audio) Frequency Shift Keying (FSK) or Gaussian Minimum Shift Keying† (GMSK), but the range of frequencies generated is outside the normal audio pass band that radios use, so it requires internal radio modifications.
Another result of this is that you canít just listen in on a 9600 baud channel and tell what is going on, because much of it is outside the delivered audio range.† A 1200 baud conversation can be reasonably eavesdropped on to tell when there is a carrier and data communication.† 9600 baud just sounds like static.
If anyone has a pointer to a page with oscilloscope images of all the different modulation schemes, I would like to see it.† As I understand it, MSK is just FSK that only transitions at zero crossings, and GMSK is just slightly smoothed MSK, but I would like a more exact reference.
There is potential for developing modulation schemes that can dynamically trade off bandwidth for lower error rates, which makes for interesting comparison with error correcting codes.
The author of the sound modem drivers has several useful references:
If you only need to pass one message back and forth every two seconds, or one message a second in a single direction, normal AX25 packet radio procedures are adequate.†
AX25 includes several bytes of header and trailer overhead on top of the payload to be transferred.†† Some TNC offer a KISS interface mode that lets you write raw packets to avoid this overhead, but then you are responsible for your own error detection and station identification, and you still donít get to exactly control the half duplex transitions.
Normally, AX25 is used in a ďconnectedĒ mode, and the protocol deals with detecting errors and getting retransmissions.† This is usually not desired in a telemetry system, where it is better to just ignore errors and transmit the current state.† If you enter converse mode without connecting, packets will be sent without a destination address, and without the possibility of retransmissions.
Flow control can be an issue, especially in a half duplex environment where packets can back up before sending.† In a continuous data mode, it is usually not desirable to buffer more than one packet at a time.
My communication code dumps the following to the TNC at startup:
"\003"†††††††††††††† ††††††††††† // ^c to get to command mode
"echo off\r"†††††† ††††††††††† // (on) donít repeat back what we send
"autolf off\r"††††† ††††††††††† // (on) don't add \n after each \r
"cr off\r"†††††††††† ††††††††††† // (on) no carriage return added to packet
"flow off\r"††††††† ††††††††††† // (on) allow packets to display while "typing"
"hbaud 9600\r"††††††††††† // (1200)
"mon on\r"††††††† ††††††††††† // monitor packets
"conv\r"††††††††††† ††††††††††† // enter converse mode
At this point, the link will then act more or less like a full duplex serial link that can be read and written to a line (ending in \r) at a time.† Incoming packets will be preceded by a ďCALLSIGN>CQ:Ē header that must be stripped off.
I experimented a lot with controlling the half duplex parameters with options like:
"ppersist off\r"†† ††††††††††† // (on) disable random delay before transmit
"dwait 0\r"††††††† ††††††††††† // (30) transmit immediately when clear
"txdelay 10\r"††† ††††††††††† // (50) delay after push to talk in 10msec
Even with everything tweaked to the point of unreliability, I couldnít quite get two pings a second, so for most cases I just leave them at the defaults.
AX25 behavior was defined to share a channel among several users.† Telemetry to a rocket should be strictly a two party arrangement (possibly with additional stations monitoring), and much more efficient protocols are possible.
I have been working with RTX-12A telemetry modems from Tigertronics for raw radio modem communication.† www.tigertronics.com
These half duplex 1200 baud modems use serial status lines to sense a carrier on the channel and key the push to talk (PTT) control.
You can use them in a half-duplex mode much like the TNC operate, or you can use two of them and two radios (or a dual band transceiver) and operate in full duplex.† In full duplex mode, you can leave the carrier on full time when two way traffic is going on, completely eliminating the extra delays associated with the TNC mode.† To save power, you would want to drop the PTT if nothing had been sent for a second or so.
The FSK modulation seems to be compatible with 1200 baud packet radios, but the data canít be read because the telemetry modem does framing one character at a time, while normal 1200 baud packet uses HDLC framing on a packet level.
To avoid having to use two serial ports for the full duplex communication, I wired up a splitter cable that breaks one serial port into two radio modem ports.
All of the functionality of these modems can be duplicated with software modem technology and connecting the sound card IO directly to the radio with a few extra parts for controlling PTT.
Linux offers a sound modem kernel option, but it gets layered pretty deeply under the networking infrastructure.† It is probably worthwhile to yank most of the modulation code directly into user mode, so you can exactly control buffering.
The FCC requires all amateur radio transmissions to include a station identification at least every ten minutes.† The AX25 packet format include a call sign field in every packet, satisfying the requirement.
There is an exemption for low power telemetry to model planes and such, where unidentified communication can be done if it is under one watt (is that the correct figure?) and the physical transmitter is labeled with the call sign.
An ERPS member claimed that you can define your own packet format that includes station identification, as long as the format is publicly published.† I have not followed up on that option.
Other options for using the raw telemetry modems would include using the AX25 frame format, or beeping out a call sign every ten minutes (effectively at the end of a rocket flight) in morse code by keying the carrier wave without sending any serial data.
Standard AX25 does a 16 bit CRC check over the entire packet, and rejects the entire packet if any errors are detected.† The TNC command ďpassall onĒ will cause it to display the packet anyway, with no notice that an error occurred.† In my experimentation (using a third radio to interrupt communication between two radios), many interrupted packets are still not displayed at all, I would assume because the lower level link framing failed.
If you are expecting a noisy link, you should transmit as small of packets as possible, so single errors throw out less good data.† Unfortunately, that magnifies the issues and overhead with AX25.
With raw radio modem control, you are responsible for your own framing, error detection, and error correction (either ignore, retransmit, or forward correct).
There are many good possibilities for including error correction data in each packet, so that many classes of errors can be corrected instead of just detected.† Just using the algorithm for ECC memory is one example, although there are probably better algorithms that are specifically characterized for radio links.
I donít have a good sense yet for how to trade off modulation bit rates for error correction.† A 9600 baud modem could transmit the same thing that a 1200 baud modem does, and repeat it eight times.† Iím sure there comes a point where you just get nothing useful at all from a 9600 baud link, while still reading a 1200 baud link, but I donít know the details.
This is operating system specific, but this type of picky information is important.† I did my testing on a win98 laptop with both an on-board serial port, and a Keyspan USB serial port expander off of a USB hub.† Iím not sure if it is win98, the hub, or (likely) the USB serial port, but I get fair number of blue screen system errors while exercising com3.
To the on-board serial port, writes of 16 bytes or less returned immediately (assuming an empty FIFO), while writes of 17 or more bytes blocked for the full transit time of approximately one msec per byte.† I would have expected it to only block for one msec per byte over 16.
To the USB serial port, all size writes blocked for the expected transit time.† That was also unexpected, considering that there has to be some level of packetization going on at the USB level.† It may be sending every single byte in a separate USB command packet.
Windows does not allow a single serial port to be opened twice, even if one handle is read only and the other is write only.
On Win2k, if two threads use a single com file handle, writes will block if a read is currently blocked, even if the write FIFO is clear.† This isnít a problem with half duplex communication, but it forces you to basically implement your own serial queues for full duplex communication.† This is unfortunate and needless.† Win98 doesnít seem to suffer from this.
I still need to characterize the Linux interfaces for our flight computer.
I donít have any relevant experience here yet.
Just plugging a Kenwood D7AG radios to your flight computer offers a very simple setup.† It can work with any computer, and offers 9600 baud.
The donwside is that it is relatively expensive ($429 from www.texastowers.com), and by itself you are limited to AX25.† It is moderately heavy at 0.34 kg, but much of that is battery that you could share with other devices or replace with a vehicle power bus.
The other direction that holds promise is to use cheaper radios with a software modem on the flight computer.† This rules out puny microcontrollers, and limits you to 1200 (maybe 2400) baud, but allows high performance full duplex communication (with an appropriate radio) and completely customizable protocols.