Difference between revisions of "Projets:Doc AX25 1200"
(→Audio Tones) |
(→Why 1200 Baud Packet Radio) |
||
Line 2: | Line 2: | ||
==Why 1200 Baud Packet Radio== | ==Why 1200 Baud Packet Radio== | ||
− | The Electrolab has a cubesat ground station facility... Most of the cubesats today uses hamradio bands, and the " | + | The Electrolab has a cubesat ground station facility... Most of the cubesats today uses hamradio bands, and the "usual way" for these cubesats to send datas (and beacons actually), is the 1200 Baud Packet Radio standard (used during the old days by hamradios for the packet radio network, and still used today ont the APRS system. |
− | SPACECUBE satellite has several issues on his data | + | SPACECUBE satellite has several issues on his data communication link. We grab frames from it, but with a lot of anomalies (carrier frequency drift, AFSB modulation frequency drif, and we also suspect abnormal bit stuffing). We initiated de development of a "custom" demodulator optimized for this satellite, and by the way, we had to deeply explore AX25 protocol, and its impementation on the particular low level layer used for APRS (1200 baud AFSK). |
==Lessons Learned== | ==Lessons Learned== |
Revision as of 12:48, 5 July 2017
Contents
1200 Baud Packet Radio Details
Why 1200 Baud Packet Radio
The Electrolab has a cubesat ground station facility... Most of the cubesats today uses hamradio bands, and the "usual way" for these cubesats to send datas (and beacons actually), is the 1200 Baud Packet Radio standard (used during the old days by hamradios for the packet radio network, and still used today ont the APRS system.
SPACECUBE satellite has several issues on his data communication link. We grab frames from it, but with a lot of anomalies (carrier frequency drift, AFSB modulation frequency drif, and we also suspect abnormal bit stuffing). We initiated de development of a "custom" demodulator optimized for this satellite, and by the way, we had to deeply explore AX25 protocol, and its impementation on the particular low level layer used for APRS (1200 baud AFSK).
Lessons Learned
There is very little documentation available on the low-level aspects of 1200 baud packet radio. We learned a lot of lessons the hard way during this project, and this page is the summary of theses lessons...
Physical Layer
1200 baud packet uses a modulation similar to Bell 202 AFSK. AFSK is audio frequency shift keying, which means the signal is modulated using two audio tones, as opposed to regular FSK, where the radio frequency carrier itself is shifted in frequency. Using FSK generally requires a DC-coupled connection directly to the radio's discriminator. AFSK has the advantage of working through a regular audio path, which makes it well suited for use with radios designed for voice.
Audio Tones
Two tones : 1200Hz and 2200Hz.
Packet uses NRZI (non-return to zero inverted) encoding, which means that a 0 is encoded as a change in tone, and a 1 is encoded as no change in tone.
Tone change has to be continuous in phase.
Bit Order
Bytes are sent least-significant bit first.
Bit Stuffing
Because a 1 is represented by no change in tone, sending a long string of 1s would result in an unchanging signal, which in turn would cause the receiver to drift out of sync with the transmitter. Bit stuffing prevents this. With the exception of the flag sequence, which we'll get to in a minute, any run of five 1s has a 0 inserted after the fifth 1. This stuffed 0 must be removed by the receiver.
Be warned: The description of bit stuffing in version 2.0 of the AX.25 specification (paragraph 2.2.6) is WRONG. The 0 is inserted after the fifth 1, not the first 1.
Data Link Layer
The AX.25 protocol defines the packet format. AX.25 is based on the High Level Data Link Control protocol, or HDLC. Frames start and end with the binary sequence 01111110 - the HDLC 'flag'. This sequence is not bit stuffed, so this is the only time you'll see a run of six 1s. The contents of the AX.25 frame are well-documented, so I won't go into much detail here.
Frame Check Sequence
One detail of the AX.25 format that deserves attention is the Frame Check Sequence (FCS) checksum. This is a two-byte checksum added to the end of every frame. It's generated using the CRC-CCITT polynomial, and is sent low-byte first.
The CRC-CCITT algorithm has plenty of published code examples, but the one I needed, and had trouble finding, was the algorithm for calculating the FCS one bit at a time, rather than a byte at a time. That algorithm is as follows:
Start with the 16-bit FCS set to 0xffff. For each data bit sent, shift the FCS value right one bit. If the bit that was shifted off (formerly bit 1) was not equal to the bit being sent, exclusive-OR the FCS value with 0x8408. After the last data bit, take the ones complement (inverse) of the FCS value and send it low-byte first.
References
AX.25 Specification, Version 2.2 : http://www.tapr.org/pub_ax25.html
HDLC Technical Overview : http://vkalra.tripod.com/hdlc.html