Chapter 2 -Modes

editor’s note:  there graphics which I have yet to insert.

Disclaimer:

These are my comments on digital communications and are not necessarily all there is to know on the subject.  As with everything computer related – there are at least six ways to do the same thing.  Given this caveat, let me say this is opinion and not the complete story. I only relate to you my experience of 5 or more years using digital modes and as SATERN Digital Net Manager to give you the benefit of my experience.  I will leave the rest for you to research as you see fit.

This installment is a bit lengthy.  There is a lot of information here which may be overwhelming at first. However, familiarization with this material will go a long way to understanding the digital ham radio enthusiasm.  Take the time to use this material to do some listening on your own.  You make your own conclusions about the modes discussed.

I encourage you to experiment with the digital modes in receive to get the feel of each mode before trying to get on the air in QSO. You will learn the sounds of the transmitted signals and the methods and practices of each mode.  Good etiquette for any mode is good amateur practice.

The descriptions below are a thumbnail sketch of common ham radio digital modes in use at the time of this writing.  It is designed to give you a closer look at each mode and highlight the advantages and shortcomings of each.

There should be a distinction made between the digital mode and the transmission method used.  As amateurs, we have AM, FM, SSB, FSK and other modulation methods to transmit voice and data information.  Digital modes may use one or more of these modulation methods when transmitting.  The most common method on HF is SSB/AFSK (with the upper sideband being the default on all bands) modulation although it is possible to also use FSK for some digital modes (see the discussion on RTTY).  On VHF/UHF, the FM/FSK method is very common for data transmission for much higher data rates.

The digital modes that are transmitted are unique and separate from the modulation methods used to transmit them. I hope you can understand the distinction.

PSK31

This digital mode is a very narrow band Phase Shift Keying or Binary PSK (BPSK as it is more commonly known) mode for text transmission in keyboard to keyboard chat, and automated text mailbox applications.  The normal bandwidth is about 60-80 Hz when adjusted to modulate your transceiver properly.  The most widely used sub-mode has a character send rate is about 30-31 characters per second – hence the 31 at the end of the PSK designation.  There is also a PSK63 and PSK125 sub-mode for faster symbol rates although with a much broader bandwidth of 100-200 Hz.

This popular mode attempts to send digital signals by modulating a continuous audio frequency by shifting the audio carrier in phase by 180 degrees for each transition of the digital data. Each digital data transition from 0 to 1, corresponds to a shift in phase of the audio carrier from 0 to 180 degrees in phase.   This is an extremely efficient transmission method in that power is in a very small spectrum (60-80 hz) and not spread out over a much broader spectrum as is SSB speech (2.5 Khz).   Normal data communication can be obtained with 20 watts or less of power, even QRP.

This mode can be transmitted using several modulation methods including SSB, AM, and FM.  This makes it suitable for just about any band for hams where digital signals are allowed.  Just as with CW, signals can be stacked very closely together without causing interference to adjacent signals.  The caveat to this mode is that the rig used must have very good stability and audio quality in order to transmit and receive the phase shifted information properly.  This is not usually possible with most older tube based equipment on a practical level.

PSK31 uses a Varicode 8-bit character encoding to reduce the overall amount of data that has to be sent.  But no error-correction is employed so when noise or interference causes data loss.  This is a severe downside to the PSK protocol in that it is not very noise tolerant and is not error-correcting as an integral part of the mode.  You will notice this when conditions are noisy on the band and the computer begins to show mistakes in the text.   One possibility to slightly improve the capability of PSK31 is to use the FLMSG text format/encapsulation.  In this way the text, when received will be checked with a Cyclic Redundancy Check (CRC) within FLMSG.  The drawback to this method is that the entire message must be re-sent until it is received and decoded error-free.  Often text only non-essential messages may be read even if the CRC fails.  This mode is not generally used for image transmission such as FAX or any graphical image as a file.

Computer software programs are available now that will decode multiple PSK transmissions simultaneously in what is known as a panoramic view.  The first time you see this in action it may be confusing but it is quite impressive.

Because PSK31 and the other PSK modes work well with very low power, it has gained a good reputation as being an ideal DX mode and is very popular. PSK signals can be heard in the data/CW segment of almost all amateur bands. The trend lately is to use the xx.070 region of each band. For instance on 20 meters, 14.070 is well populated. On 40 meters 7.070 is also used, and so on. The CW/data portion of all bands will find some use of PSK31. When open, 10 meters has about 100 Khz in use mostly for PSK DX contacts and CW. Often other digital modes are present and in great variety.

A very close relative of PSK is Quadrature Phase Shift Keying (QPSK). This mode also uses the phase shift scheme but only shifts 90 degrees instead of 180. This mode has gained some popularity lately due to the improvement in decoding software that includes automatic frequency control (AFC). QPSK software is now available in error correcting versions. PSKMail is also available as QPSK. This is quite a reliable and easy text mail delivery method when automated and signal strength is very good. It enjoys the same low power – high capture rate of PSK but includes the security feature of error correction at some rates.

Improvements in software have also been made that allow SOME non-text data to be transmitted in PSK. This is limited to only certain types of non-text data and the transmission time is extremely slow in comparison to other more capable modes.

The downside of QPSK is that more precise tuning and higher stability are necessary for it to be reliable in addition to the low noise and minimal QSB needs of PSK in general.

All in all, PSK is a fun and easy way to get into digital communications if you know how to type. It can be a pain if you cannot type. But have no fear there are other digital modes that do not require you to type that much.

A good way to get a look at PSK31 is to use the audio output from your radio acoustically coupled to your computer internal mic and/or, connect your rig audio output (headphones, external speaker or aux audio output) to the computer sound cards’ line input with a simple adapter cable made or purchased. Download from the Internet, multi-mode programs like FLDIGI, Digipan, MultiPSK, or MixW. With little time spent on setup and some practice receiving you will begin to receive PSK31 text on your computer. All that is left to do to get on the air, is to connect the speaker output from the computer to the mic input or audio input of your rig or (with some manual difficulty, key the mic with the PTT button, and acoustically couple the mic to the computer speakers). If you are really frugal, you don’t even need to spend the money on an interface box. Simple adapter cables with the proper plug types at each end may work. With at least one rig I have even been able to rubber band the microphone to the computer speakers and manually switch to transmit with the software, as it turns on the microphone when the PTT line is activated. Many QSO sessions have been made this way and there is nothing wrong with it. This works fine with PSK31, and other keyboard modes that do not have fast turn around times. It will not work with semi-automated modes like WinLINK, AMTOR, PACTOR or any other ARQ (Automatic Repeat Request) or synchronous mode due to the fast turn-around T/R times and much lower audio quality, higher noise, of acoustical coupling vs direct connection.

Often there is a problem with direct connection of the computer soundcard to the radio because it introduces what is called “common mode” noise, i.e. hum. When this is the case, the only solution is to use a computer interface to isolate the radio from the computer. For those of you who prefer Linux you may want to check out LinPSK as seen in the image below:

(BTW this IS Linux and Not Mac OS X. I am just running a Mac-like theme in the window manager.)

graphic to be inserted

RTTY

adapted from the FLDIGI documentation by W1HKJ

This is one of the oldest digital modes around. Even before modern computer software solutions were available, RTTY was used by construction of discreet audio components for tone generation and detection. Terminal equipment was generally available wire-line teleprinter equipment as surplus on the commercial and military surplus markets. My first encounter as a ham was by way of a veteran ham and MARS operator who was very proud of his Teletype Model 40 and a homebrew detector / modulator to operate RTTY for MARS. That was decades ago.

Today, computers replace the discreet components and software does the job of detection and transmission.

The RTTY modulator and demodulator have been extensively changed with version 3.21.67 of FLDIGI. The new design was a cooperative effort of Stefan, DO2SMF, and Dave, W1HKJ with extensive testing performed by Ed, W3NR, and Dick, AA5VU. Chen, W7AY, was a silent contributor to the design by virtue of his excellent technical papers on RTTY modulation and demodulation, which he so generously placed in the public domain.

FLDIGI can operate on a wide range of RTTY symbol rates and bandwidths. The selection of symbol rate and bandwidth is made on the RTTY configuration tab. The three most common in amateur radio use can be selected from the mode menu. These are:

Mode Symbol Rate Typing Speed Bandwidth RTTY 45 45.45 baud 6.0 cps (60 wpm) 270 Hz RTTY 50 50.0 baud 6.6 cps (66 wpm) 280 Hz RTTY 75 75.0 baud 10.0 cps (100 wpm) 370 Hz

graphic to be inserted

These modes were a result of mechanical and electrical designs of the early TTY machines. The 45.45 baud and 75 baud machines were for the US / Canadian market and used 60 Hz synchronous motors. The 50 baud machines were for the European market and used 50 Hz synchronous motors.

FLDIGI can encode and decode many other symbol rates and bandwidths. “Custom” combinations are set up on the RTTY configuration tab. You probably will never have to do that unless you like experimenting with unusual RTTY modes.

All of the modem signals that FLDIGI produces are audio signals. That includes the RTTY signal. FLDIGI can encode and decode an RTTY signal that is anywhere within the passband of the sideband transceiver. It is not limited to the traditional tone pairs around 2100 Hz. Each of the generated Mark / Space signals are on-off-keyed (OOK), bandwidth limited signals. The resultant waveform is not an FM type signal of constant amplitude. Therefore the transmit audio and RF amplifiers must be linear, just like the requirement for PSK signals. There are performance gains using this approach. The principal being a reduction in inter symbol interference which gives much improved performance by the receiver.

 The waterfall, time domain, and spectrum signatures of the transmitted signal look like this:

graphic to be inserted

The two lighter colored bands in the display are the binary tones of RTTY that have been detected by FLDIGI. We can also look at the spectrum of the RTTY signal that generated the waterfall display and that would display in FLDIGI as shown below right. Understand that the waterfall is a spectrum display, one line at a time over a very long time domain. The spectrum display is a display of the instantaneous frequency domain for a limited time. The difference is subtle, but distinctive. In this spectrum display, the two distinctive tones of RTTY modulation are shown as a rise in the signal at the frequency of the digital signal. The baud rate is fast enough to see both tones in one sweep of the detected signal. The faster RTTY modes will look similar except the peaks will be separated by more space, indicating a greater difference in the tonal frequencies. The image below it is the appearance of a detected AFSK signal when displayed in the time domain. Many software programs display both the spectrum and the waterfall displays. It is a useful and somewhat complicated way of showing the same information – amplitude vs. frequency. You can see from the spectral display that RTTY occupies little spectrum and power is concentrated in only two frequencies. Efficiency of the transmitted signal is quite high although the duty cycle is 100%. Be sure your rig is capable of full-time transmit if you intend to have long QSOs over RTTY. RTTY is almost as popular as PSK31. As a result, there are several RTTY contests and DX events each year that may be heard in the CW portion of each band. You must operate your transceiver in the USB mode for the FLDIGI RTTY signal to be the correct polarity (transmitting the correct tones for each 0 or 1 data signal). If your transceiver is set to LSB then use the FLDIGI “Rev” button to reverse the sense of the mark and space signals. You must maintain transmitter LINEARITY in the AUDIO AMPLIFIERs. Do not think that you can improve performance by over driving the audio input. A good operating procedure for most transceivers is the set the audio level to the level for which there is just barely a hint of ALC. Then reduce the input to 80% of that power level. Over driving an AFSK signal is as disastrous as over driving a PSK signal. In fact, this is true for all digital modes. Transmit audio level should be held to the minimum needed to communicate, never increase the audio signal where the ALC is obviously limiting the signal.

This is an actual on air signal that was being over driven (but not on purpose):

graphic to be inserted

The presence of harmonic distortion is a dead giveaway. It is possible to use FLDIGI to generate the keying waveform for use with an FSK type of transmitter. See Pseudo FSK for a description of how this can be accomplished.

Thor

Thor is a new forward error correcting, incremental frequency shift keyed, communications mode. It was developed specifically to meet the needs of ARQ transfers in the HF spectrum. It is particularly well suited under conditions of atmospheric static noise. Thor borrows from two current modem technologies, MFSK and DominoEX.

Thor emits a distinctive double rising tone sequence at the beginning of each transmission. It is used to flush the receive decoder and also provides a visual and audible clue to its’ being used.

The modem code for Thor uses a wide band multiple frequency detector that can lock on and detect the incoming signal even when badly mistuned. Frequency domain oversampling is used to allow proper tone detection without the need for AFC. The AFC control does not alter the decoder in any way.

The FLDIGI implementation of the Thor modem includes the ability to send and receive images and avatars. The default avatar is the “Tux” logo. Sending, receiving and saving avatars is discussed in the avatar section of the FLDIGI documentation. Other images of very small size may also be sent in addition to the Tux avatar. Transmission lengths dramatically increase with data that is bit intensive.

The waterfall and digiscope will appear as:

graphic to be inserted

This display indicates an and extremely linear detected signal (as indicated by the digiscope on the right) with little noise shown on the waterfall.

The text displayed in the status area is the secondary text being sent by the transmitting station. When the keyboard buffer is empty the Thor modem transmits text from the secondary text buffer. Your secondary text buffer can be edited on the Thor configuration tab.

Transmit Image

Transmitting an image in Thor is initiated by selecting the “Send image” menu item from the pop up Tx menu. Right click on the Tx panel. This selection opens up the Send Image dialog.

graphic to be inserted

The Send Image Dialog is shown with a 160×120 color image loaded and ready to transmit.

Transmission begins when you press the “Xmt” button. fldigi will insert the text preamble and immediately begin the image transmission. fldigi returns to the receive mode when the image transmission is completed.

Receive Image

Reception is completely automatic. The decoder will identify the picture start, and record the picture. In doing so, it automatically opens a separate “Thor Rx Image” dialog.

OLIVIA

In an article that appeared in QST Dec. 2008 the author Gary Robinson, W8ROL describes OLIVIA mode this way:

Olivia mode can be set to various formats that are labeled using the particular format’s bandwidth and number of tones. Bandwidths of 125, 250, 500, 1000 and 2000 Hz are typical. The number of tones can be set anywhere from 4 to 256 depending upon the propagation conditions. Different combinations of tones and bandwidths provide for slower or faster transmission rates. Commonly used formats are 125/4 (125 Hz bandwidth using 4 tones), 250/8, 500/16, 500/8, 500/16, 1000/32. The 500/8 format seems most popular at this moment, though I have had several QSOs on the 125/4 and 250/8. The 1000/32 format seems to be popular on 20 meters.

Each of the Olivia formats has advantages and disadvantages. Obviously, the bandwidth differences make the more narrow formats attractive because they will fit in available open spectrum space more easily. They also will likely get through slightly better since all the power of the transmitted signal is concentrated in a smaller bandwidth — much the way CW gets through better than wide phone signals.

The speed of Olivia is an issue also. Olivia is generally not as fast as PSK31 or MFSK16. Olivia 500/16 sends text at approximately 20 wpm. The 500/8 format speeds that up to nearly 30 wpm. Fewer tones results in more speed while less bandwidth results in slower speed. Olivia 1000/8 and 2000/8 are often used by Military Affiliate Radio System (MARS) traffic nets because these formats are fairly fast, accurate and get through when the MT63 mode (a digital mode using 64 tones phase shift keyed in a 1 kHz bandwidth) fails. Most of this information and more pertaining to Olivia are available at the HFLink and DXZone Web sites.

Many hams find Olivia slower than they like and prefer to use other modes, while many others find the accuracy and ability to get through an acceptable trade off. Also, many of us, including myself, are not fast typists and actually find “slower” to be a positive attribute and allows for more comfortable overall operation.

Another advantage to the mode is that it’s not quite as critical for it to be tuned exactly on frequency as it is with PSK, MFSK and many other modes. If you click on the waterfall with your mouse and the indicator doesn’t get exactly on the signal it may still decode properly. Most implementations of Olivia are set to search for signals to either side of your center frequency by a fixed percentage of your signal’s width.

The W1HKJ documentation describes OLIVIA this way:

These [OLIVIA sub-modes] are unconnected, simplex chat modes with full time Forward Error Correction. Olivia is a very robust mode with low error rates, but the penalty can be an annoyingly slow transfer of information. If you are a one finger typist then Olivia is your cup of tea. The tones are spaced the same as the baud rate, for example 31.25 Hz for the default baud rates. The default calling mode is 32-1000. It has the following appearance on fldigi’s waterfall:

graphic to be inserted

When you call CQ on this mode be patient and wait at least 45-60 seconds before you put out another call. When the other person who hears your CQ clicks on the waterfall it may take 4-20 seconds or even longer before they might actually start decoding your signal. That varies a lot depending on the software they are using AND value they have their Sync Integration Period set to. The Sync Integration Period setting determines how “deep” the Olivia decoding algorithm searches in the noise to get the signal. A higher settings takes longer BUT usually decodes with more accuracy – at least to a point. However, a higher setting (since it does more work and takes longer) will increase the delay factor. So, when you finish your CQ and your transmitter switches to receive – the station listening to you (depending on his Sync Integration Periods setting) MAY NOT finish decoding your CQ for another 4-20 seconds. The same applies during a QSO when you pass it back to the other guy for his turn – be patient if he doesn’t come back right away because his software may still be decoding your signal long after you stopped transmitting.

It DOES NOT PAY to be impatient on this mode and send SHORT CQ’s or NOT wait at least 45-60 seconds between CQ’s. Generally a 2×2 CQ sent at least 2 or 3 times is going to work much better for you than a short one.

FLDIGI can operate on the following Olivia modes without special setup by the operator:

Mode Symbol Rate Typing Speed Bandwidth Olivia 8-250 31.25 baud 1.46 cps (14.6 wpm) 250 Hz Olivia 8-500 62.5 baud 2.92 cps (29.2 wpm) 500 Hz Olivia 16-500 31.25 baud 1.95 cps (19.5 wpm) 500 Hz Olivia 32-1000 31.25 baud 2.44 cps (24.4 wpm) 1000 Hz

graphic to be inserted

You will notice the actual symbol rate is not intuitive. That is to say that the throughput speed does not go up proportionately with bandwidth. In fact the most efficient throughout is using the 8 tones / 500 Hz sub- mode. Precisely the reason it is used on the SATERN Digital Net each Saturday.

What is intuitive is that the wider modes with more tones have in increase in noise tolerance. In other words, the 32 tones / 1000 Hz sub-mode is quite robust, but half the speed of 8 tones / 500 Hz sub-mode.

MFSK

From the FLDIGI documentation…:

MFSK16 and MFSK8 are multi-frequency shift keyed (MFSK) modes with low symbol rate. A single carrier of constant amplitude is stepped (between 16 or 32 tone frequencies respectively) in a constant phase manner. As a result, no unwanted sidebands are generated, and no special amplifier linearity requirements are necessary. The tones selected are set by the transmitted (4 or 5 bit) bit pattern and a gray-code table.

The mode has full-time Forward Error Correction, so it is very robust. Tuning must be very accurate, and the software will not tolerate differences between transmit and receive frequency. The mode was designed for long path HF DX, and due to its great sensitivity is one of the best for long distance QSOs and skeds. MFSK8 has improved sensitivity, but is very difficult to tune, and suffers more from Doppler. It is useful as the band fades out.

MFSK-32 and MFSK-64 are high baud rate and wide bandwidth modes designed for use on VHF and UHF. These are very useful for send large documents or files when some transmission errors are can be tolerated.

This is an example of properly tuned MFSK16 signal with a s/n of approximately 9 dB.

graphic to be inserted

[Author note: We have seen considerable success with the MFSK-64L (long leader) mode on the SATERN So. Terr. Digital Net on HF. It is fairly quick and has some robust qualities.]

MFSK Picture Mode

Fldigi can send and receive small images using all MFSK baud rates. When operating with other modem programs you should limit sending pictures to the MFSK-16 baud rate. The program can send and receive MFSK images in both black and white and in 24 bit color. The transmission mode for MFSKpic is similar to FAX.

Reception of an MFSKpic transmission is fully automatic. The MFSKpic transmission has a preamble sent which will be visible on the text screen. The preamble reads as “Pic:WWWxHHH;” or “Pic:WWWxHHHC;” for b/w or color respectively. The WWW and HHH are numbers specifying the width and height of the picture in pixels.

The successful reception of a MFSKpic is highly dependent on s/n conditions. The data is transmitted as an FM modulated signal and is subject to burst and phase noise on the transmission path. It can provide excellent photo transmission on a really good path.

Use of this mode to send images should be limited to very small pictures (smaller than 150 X 150) due to the slow throughput of bit intensive data and the length of transmission.

MT-63 The FLDIGI documentation describes this mode this way: MT63 is an Orthogonal Frequency Division Multiplexed [OFDM] mode consisting of 64 parallel carriers each carrying part of the transmitted signal. The tones are differential BPSK modulated. MT63 employs a unique highly redundant Forward Error Correction system which contributes to it robustness in the face of interference and facing. The tones have synchronous symbols, and are raised cosine modulated [to limit spurious sideband generation]. This mode requires a very linear transmitter. Over-driving leads to excessive bandwidth and poorer reception. The mode is very tolerant of tuning and FLDIGI will handle as much as 100 Hz of mis-tuning. This is very important since MT63 is often used in very low Signal to Noise ratios. There are three standard modes: Mode Symbol Rate Typing Speed Bandwidth MT63-500 5.0 baud 5.0 cps (50 wpm) 500 Hz MT63-1000 10.0 baud 10.0 cps (100 wpm) 1000 Hz MT63-2000 20 baud 20.0 cps (200 wpm) 2000 Hz In addition there are two interleave options (short and long) which can be set on the MT63 configuration tab. The default calling mode is MT63-1000. If the short interleave is used then one can expect some compromise in robustness. The long interleave results in somewhat excessive latency (delay between overs) for keyboard chatting. MT63-1000 with the long interleave has a latency of 12.8 seconds. You can change from receive to transmit immediately upon seeing the other stations signal disappear from the waterfall. You do not need to wait until the receive text completes. Any remaining data in the interleaver will be flushed and the associated receive text printed quickly to the Rx pane. Tx will commence right after the buffer is flushed. MT63 may be operated in the default fixed audio frequency mode. In this mode you are not allowed to randomly place of the signal on the waterfall. Your transmit signal, and also the received signal should be centered at 750 Hz for MT63-500, 1000 Hz for MT63-1000, and 1500 Hz for MT63-2000. The downside to this mode is the need for an extremely flat audio passband in the receiver for the mode bandwidth. The accuracy of the received data suffers where the audio passband has the characteristic “hump” in the mid-frequencies of the received audio. Also, since the data is spread over a broader spectrum, the net resulting carrier power average is some 25% of other AFSK modes. The graph above depicts the very broad and linear use of the transmitted spectrum. The total average power spectrum is a fraction of other modes. Where you may see a 50 watt signal from PSK, MT-63 would possibly be only 10 watts or less. This does not make it less capable, just less efficient. It also shows the almost perfect audio passband linearity of the station transmitter.

———————– Page 12———————– This mode is used extensively by MARS and some government and NGOs as their default mode for message passing outside radio mail, Internet based email is almost exclusively WinLink 2000 and PACTOR. This graph compares common digital modes and MT-63. As with any digital mode, there are trade-offs between bandwidth and speed. It is among the fastest, however the speed requires considerable bandwidth. Use of MT-63 for general communication should be weighted against the frequency used, noise and QSB present, and band segment. The SATERN Digital Net uses MT-63 only as a fallback mode when interfacing with MARS or NGOs that require it when conditions will allow error-free message transmission and reception. PACKET The Wikipedia Web Site describes PACKET this way: Packet radio is a form of packet switching technology used to transmit digital data via radio or wireless communications links. It uses the same concepts of data transmission via Datagram that are fundamental to communications via the Internet , as opposed to the older techniques used by dedicated or switched circuits (land lines). Earlier digital modes were telegraphy (Morse Code), teleprinter (Baudot code over RTTY) and [FAX]. Like those earlier modes, packet was intended as a way to reliably transmit written information. The primary advantage was initially expected to be increased speed, but as the protocol developed, other capabilities surfaced. By the early 1990s, packet radio was recognized as a way not only to send text, but also to send files (including small computer programs), handle repetitive transmissions, control remote systems, etc. The technology itself was a leap forward, making it possible for nearly any packet station to act as a digipeater [i.e. digital repeater], linking distant stations with each other through ad hoc networks. This makes packet especially useful for emergency communications. In addition, mobile packet radio stations can automatically transmit their location [APRS], and check in periodically with the network to show that they are still operating. The most common use of packet is in amateur radio, to construct wireless computer networks. Packet radio uses the AX.25 (Amateur X.25) data link layer protocol, derived from the X.25 protocol suite and adapted for amateur radio use. AX.25 was developed in the 1970s and is based on the wired network protocol X.25. AX.25 includes a digipeater field to allow other stations to automatically repeat packets to extend the range of transmitters. One advantage is that every packet sent contains the sender’s and recipient’s amateur radio callsign, thus providing station identification with every transmission. One of the first challenges faced by amateurs implementing packet radio is that almost all amateur radio equipment (and most surplus commercial/military equipment) has historically been designed to transmit voice, not data. Like any other digital communications system that uses analog media, packet radio systems require a modem. Since the radio equipment to be used with the modem was intended for voice, early amateur packet systems used AFSK modems that followed telephone standards (notably the Bell 202 standard). While this approach worked, it was not optimal, because it used a 25 kHz FM channel to transmit at 1,200 baud; when using a direct FSK modulation like G3RUH’s packet radio modem, a 9,600 baud transmission is easily made in the same channel. In addition, the baseband characteristics of the audio channel provided by voice radios are often quite different from those of telephone audio channels. This led to the need in some cases to enable or disable pre-emphasis or de-emphasis

———————– Page 13———————– circuits in the radios and/or modems. Another problem faced by early “packeteers” was the issue of asynchronous versus synchronous data transfer. At the time, most personal computers had asynchronous RS-232 serial ports for data communications between the computer and devices such as modems. The RS-232 standard specifies an asynchronous, start-stop mode of data transmission where data is sent in groups (characters) of 7 or 8 bits. Unfortunately, the simple AFSK modems typically used to provide no timing signal to indicate the start of a packet frame. That led to the need for a mechanism to enable the receiver to know when to start assembling each packet frame. The method used is called asynchronous framing. The receiver looks for the “frame boundary octet”, [a stream of 8 consecutive bits of data in a pre-defined pattern] then begins decoding the packet data that follows it. Another frame boundary octet marks the end of the packet frame. Modems used for packet radio vary in throughput and modulation technique, and are normally selected to match the capabilities of the radio equipment in use. Most commonly used method is one using audio frequency-shift keying (AFSK) within the radio equipment’s existing speech bandwidth. The first amateur packet radio stations were constructed using surplus Bell 202 1,200 bit/s modems, and despite its low data rate, Bell 202 modulation has remained the standard for VHF operation in most areas. More recently, 9,600 bit/s has become a popular, albeit more technically demanding, alternative. At HF frequencies, Bell 103 modulation is used, at a rate of 300 bit/s. Due to historical reasons, all commonly used modulations are based on an idea of minimal modification of the radio itself, usually just connecting the external speaker or headphone output directly to the transmit microphone input and receiver audio output directly to the computer microphone input. Upon adding a turn the transmitter on output signal (“PTT”) for transmitter control, one has made a “radio modem”. Due to this simplicity, and just having suitable microchips at hand, the Bell 202 modulation became standard way to send the packet radio data over the radio as two distinct tones. The tones are 1,200 Hz for Mark and 2,200 Hz for space (1,000 Hz shift). In the case of Bell 103 modulation, a 200 Hz shift is used. The data is differentially encoded with a NRZI pattern, where a data zero bit is encoded by a change in tones and a data one bit is encoded by no change in tones. Ways to achieve higher speeds than 1,200 bits/s, include using telephone modem chips, [and] via the microphone and audio out connectors. This has been proven to work at speeds up to 4,800 bit/s using fax V.27 modems in half- duplex mode. These modems use phase shift keying [PSK] which works fine when there is no amplitude shift keying, but at faster speeds such as 9,600 bit/s, signal levels become critical and they are extremely sensitive to group delay in the radio. These systems were pioneered by Simon Taylor (G1NTX) and Jerry Sandys (G8DXZ) in the 1980s. Other systems which involved small modification of the radio were developed by James Miller (G3RUH) and operated at 9,600 bit/s. 1,200 bit/s AFSK node controllers on 2 meters (144–148 MHz) are the most commonly found packet radio. For 1,200/2,400 bit/s UHF/VHF packet radio, amateurs use commonly available narrow band FM voice radios. For HF packet, 300 bit/s data is used over single side band (SSB) modulation. For high speed packet (9,600 bit/s upwards), special radios or modified FM radios must be used. Custom modems have been developed which allow throughput rates of 19.2 kbit/s, 56 kbit/s, and even 1.2 Mbit/s over amateur radio links on FCC permitted frequencies of 440 MHz and above. However, special radio equipment is needed to carry data at these speeds. The interface between the “modem” and the “radio” is at the intermediate frequency part of the radio as opposed to the audio section used for 1,200 bit/s operation. The adoption of these high speed links has been limited. PACTOR I The following information is adapted from the Specialized Communication Systems web site and other sources. PACTOR (Latin for: The mediator – conflated from PACket and amTOR) is a radio modulation mode that uses Frequency Shift Keyed (FSK) modulation or audio frequency shift keying (AFSK). PACTOR was

———————– Page 14———————– developed in Germany by Ulrich Strate (DF4KV) and Hans-Peter Helfert (DL6MAA) of Special Communications Systems GmbH (SCS) and released to the public in 1991. PACTOR is an evolution of both Amtor and Packet radio, hence the name PAC-TOR. It was developed in order to improve the reception of digital data when the received signal was weak or noisy. PACTOR combines the bandwidth efficiency of packet radio with the Cyclic Redundancy Check (CRC) and Automatic Repeat reQuest (ARQ) error recovery of AMTOR. Amateur radio operators in Europe and the US were instrumental in developing and implementing this digital mode. PACTOR is most commonly used on frequencies between 1 MHz and 30 MHz (HF) but theoretically can be used on any amateur frequency where digital communications are allowed. The next illustration shows the spectral content of a PACTOR transmission. Notice this is very similar to other 2FSK modes like RTTY, AMTOR/SITOR and G-TOR. The illustration is of PACTOR II, but the PACTOR I waveform is very similar. PACTOR I provides reliable communications with only 170- 200 Hz required for the 2FSK transmission scheme at a character rate faster than RTTY and AMTOR. The PACTOR protocol allows a much higher throughput than AMTOR/SITOR/GTOR, and packet (150 and 300 baud modes on HF) with the efficient error correction and data transparency of packet radio. One should not, however, be under the impression that PACTOR is just a combination of packet radio and AMTOR/SITOR. Although essential parts of both systems have been included, such as data integrity (by using CRC error checking), and multi-frequency data elements from packet radio, and the synchronous transmission format and short block lengths (compared to packet radio) of AMTOR/SITOR, a fully new concept has also been included from the very beginning. For the first time in amateur radio, in-line data compression can be used to markedly increase the effective transmission speed so long as it complies with current FCC guidelines. Also the use of memory ARQ [holding data in memory until verified completely] in PACTOR I is a milestone in amateur radio, although it has been known for a long time in the commercial sector. Previously it has been very difficult, or impossible, to apply the concept of memory ARQ in amateur radio. The use of memory ARQ is the main reason that PACTOR does not loose the link under bad conditions. With memory ARQ, defectively received packets or blocks are not just simply thrown away. They are stored and added to other defective packets, until enough data is collected in memory to reconstruct the original packet, and thus keep the link during operation. The new WinMor protocol incorporates a similar strategy to provide robustness to it’s platform. PACTOR has established itself as a standard for AFSK radio message transport on shortwave amateur and marine radio. PACTOR makes it possible to utilize an almost ideal combination of simple AFSK modulation and ARQ protocol for robust error detection and data throughput. Generational improvements to PACTOR I include PACTOR II, III, and now IV (with the new Dragon TNC) which are capable of higher speed transmission. These newer versions are used mostly by amateur radio operators to transfer large binary data files and to accomplish transparent Internet E-mail access over shortwave. PACTOR is also used by the SailMail network for e-mail transfer over Marine radio frequencies. HF data transmission by radio amateurs usually use medium power (typically 100 watts or less) over all distances. Such distances over hostile radio paths require that special attention be paid to the rate at which data is repeated, and to error correction methods. To reduce the amount of data sent, in-stream data compression and CRC is utilized, along with memory ARQ. By combining these open technologies, PACTOR achieves a power efficiency much greater than that of older protocols such as packet, AMTOR or RTTY (RTTY has no error correction methods of its’ own only CRC error detection). PACTOR I has a

———————– Page 15———————– very narrow audio spectrum waveform and can occupy the same band space as analog 300 baud packet. To date, there is only one computer-based [vs hardware implementation] soundcard software program that can both transmit and receive PACTOR I – “hf” or “hfterm”, as it is called, available on some Linux platforms. There are several that can decode PACTOR I signals in receive only mode (ARQ). Those programs are the Windows only applications MultiPSK, and MixW (with the addon, plugin module). These programs do not allow software connection to email client programs directly, but text can be cut and pasted when necessary. WinMor is a soundcard based mode that surpasses PACTOR I and is free for general amateur use on the WinLink 2000 network and in peer-to-peer QSO. PACTOR II The PACTOR-II protocol is based on the Level-I standard, consisting of a synchronous half-duplex ARQ protocol. New in this version however, is the ability to choose four different data speed steps, so that a greatly improved adaptability is obtained by mode shifting on-the-fly. The modulation system used for PACTOR-II is based on DPSK (differential phase shift keying) which leads to a very narrow spectrum, virtually independent of the data rate. The robustness of the DPSK modulation qualifies itself noticeably higher at lower information speeds in comparison to FSK. The illustration shows the audio spectrum use in comparison to 300 baud packet FSK. Being more robust than PACTOR I, PACTOR-II uses high performance convolutional coding, that is evaluated with a real Viterbi decoder in the data receiver. This is a common method for multi-frequency error-correcting protocols today. The high correction capability of the decoder allows not only links with extremely weak or noisy signals, but also, with more normal signals, enables short error bursts, or fade- outs, to be entirely ignored, and a repetition of that packet is not required. This is especially important with PACTOR-II, as the protocol allows switching to a triple cycle length if there is enough data in the transmit buffer. The relatively long resultant data packet would be very prone to impulse errors from clicks or atmospherics (QRN), if not for the highly effective error correction designed. As with the Level-I protocol, PACTOR-II uses hardware based Huffman coding for text compression on a packet by packet basis. As an alternative, PACTOR-II can also use pseudo Markov coding (also hardware based) as a compression method. Known as PMC, it has been developed by SCS, and increases the throughput of plain text by a factor of 1.3 compared to Huffman coding. The PTC-II modem hardware examines each packet individually to see if it would be faster to send it using Huffman, PMC, or normal ASCII transmission. There are thus no disadvantages incurred by using PMC when using the internal compression provided by the PTC-II. There is a total of 6 different compression variations available for use. The SCS PTC-II modem checks each packet automatically, and then chooses the best compression method for transmitting the data. Additionally, PACTOR-II uses “run length coding” (similar in method to ZIP and LZW compression), so that sequences of repeated characters, (e.g. underlining, or columns in graphics), may be transmitted very efficiently. With “run length coding”, the system does not transmit each character individually, instead an sample character is sent, followed by the required number of same. Maximum net throughput with in-line data compression: approx. 1200 Bit/sec.

———————– Page 16———————– In certain configurations the modes Pactor II and III, utilizes proprietary data compression technology which may be used by the unscrupulous to try to conceal the nature of the transmission. This is illegal on ham radio in the U.S. and some other countries, but it is possible with the SCS modems. PACTOR-III Almost all current PTC modems, currently available, are upgradeable to use PACTOR-III via a software update. PACTOR-III is included as an option in the standard PTC-II and later firmware. To use PACTOR-III both, transmitting and receiving stations, must support PACTOR-III. If you are a mobile station transmitting to a land based station, both mobile and land stations must be in PACTOR-III mode in order to benefit from the higher data rates PACTOR-III offers. The calling modem uses the PACTOR-I FSK connect frame to be compatible with the lowest level. The called modem then answers and the modems negotiate to the highest possible level both modems are capable of. If one modem is only capable of PACTOR-II, then the 500 Hz PACTOR-II mode is used for the session. With the PTC-II MYLevel command, a user may limit a modems highest mode. An example: a user may set MYL to “1” and a PTC modem will only make a PACTOR I connection, set to “2” and PACTOR I and II connections are available, set to “3” and PACTOR I through III connections are enabled. The default MYL is set to “2” with the current firmware and with PACTOR III firmware it will be set to “3”. If a user is only allowed to occupy a 500 Hz channel, MYL can be set to “2” and the modem will behave like PACTOR-II firmware. Maximum occupied bandwidth: 2.4 kHz @ -40 dB, audio passband: 400-2600 Hz. The illustration is of the PACTOR III signal at maximum data rate. The scale is 0-3000 Hz. Notice that the slope of the leading and trailing passband waveform is very steep by design. This requires very high quality audio passband amplifiers and filters to interpret the signal accurately. Some older radios may have too much ringing in the filters or to broad a slope to provide accurate and reliable results. Most modern, solid-state, digital radios are capable of good to excellent results. Maximum net throughput with proprietary hardware based in-line data compression is approx. 5200 Bit/sec according to the manufacturers web site.

———————– Page 17———————– PACTOR III modems are specifically able to use a combination of different data rates, compression methods, internal modulation modes, and error detection/correction methods to quickly adapt to widely varying conditions. There are up to 6 different data rates, four compression methods, and three error correction/detection methods that can be used in any combination. As mentioned earlier, the PACTOR III to PACTOR III connection protocol starts with the base PACTOR I mode to establish a link and progressively increases the transmission rate to find the best throughput for channel conditions. Using a combination of variable length packet headers, 16-bit CRC error checking, memory based ARQ, adaptive channel audio equalization, DBPSK, and DQPSK, PACTOR III achieves higher robustness at the low SNR edge compared to PACTOR II. On an average channel, PACTOR III is around 3.5 times faster than PACTOR II. On good channels, the effective throughput ratio between PACTOR III and PACTOR II can exceed 5. The in-line data compression provided by the PTC modems is especially useful for applications which do not allow off-line (file) compression, e.g. email via TCP/IP, etc. However, it is a proprietary compression method and is not widely accepted by some countries as an acceptable compression method. US amateurs should not use the built in compression of the SCS modems, but rather use the compression methods provided by PACLINK and AirMail in all modes including PACTOR I, in order to comply with the spirit of FCC Part 97 and OSHEP guidelines on data encryption. The illustration shows how effective PACTOR III connections of moderate quality are over other modes. All modes are on 80m in the daytime (moderately poor conditions). Stations separation miles should not be take too literally as an indicator of performance on HF as this graph pertains to specific tests for comparison purposes only. The negatives of PACTOR II and III are: • Cost is an important consideration when choosing PACTOR II and III equipment. PACTOR I is open technology and used modems can be purchased for PACTOR I (e.g. the Kantronics KAM XL and later models of the AEA PK232 modem) in the $50-$150 price range and are in ample supply. Only one soundcard software solution currently transmits and receives PACTOR I – “hf” or “hfterm” for Linux. The two enhanced modes, PACTOR II and PACTOR III, are much faster but have been kept proprietary by the German company, SCS, that developed PACTOR. As a result, SCS is the only source for modems capable of these modes. The price of these modems (in some cases as much as a recent model HF radio) discourage many potential users. WinMor addresses this concern and is released for the public domain for free and exceeds PACTOR I in performance. It is unclear whether it will be for the Windows market only or will be multi-platform since the advanced Open Source mode ARDOP is in Beta Test now. • As wireless Internet connections become commonplace, including satellite Internet service providers and WiFi, users are finding that other reliable ways to communicate that are less costly than proprietary hardware. • Like all digital radio modulation modes, PACTOR transmissions have the potential to disrupt other modes of communication on the same or nearby frequencies because of bandwidth considerations

———————– Page 18———————– in data segments of each band, and unattended automated operations. Good operating practices must be followed to avoid potential interference. SCS modems have the ability to detect activity before transmitting but it is an operator selected option. Previously, PMBO operators had this feature turned off. Now the use of this feature is more widely accepted and may be in widespread use soon if not already. WINMOR WINMOR, by Rick Muething KN6KB of the Winlink Development Team, is a HF radio transmission protocol for the WinLink 2000 system. WINMOR was introduced at the 2008 ARRL / TAPR Digital Communications Conference in Chicago on September 26-28, 2008. Unlike PACTOR II and III, only a simple computer soundcard-to-radio interface is required, and it will run as a “virtual” TNC (i.e. the modem and decoder are software based, using the soundcard instead of dedicated, embeded hardware external to the computer) with PackLink and RMS software. Also unlike PACTOR in later versions, it will be fully documented and without restrictions or license issues preventing anyone from using the protocol in other software. It has at least three modes, ranging from 200 to 2000 Hertz in bandwidth, and provides raw speeds ranging from 125 to at least 1875 bits per second. This rivals PACTOR II under some conditions. WINMOR will NOT replace PACTOR but be used in addition to PACTOR. The RMS HF servers will be able to operate BOTH WINMOR and PACTOR (1-3 and some locations 4) but not simultaneous connections. While WINMOR may not equal PACTOR II and PACTOR III in total performance it provides lower cost, higher performance and more robustness than PACTOR I. The primary applications are for those lower usage Emcomm applications which have trouble justifying the high cost and low utilization of the PACTOR II and later modems. In addition to the above aspects of WinMor, the extensive use of encoding, compaction, and memory ARQ have resulted in a very robust, fault tolerant, and adaptive digital mode. The following image is of the WinMor Virtual TNC as seen in early versions:

———————– Page 19———————– ARDOP from the ARDOP specifications posted online by Rick Muething, KN6KB The popularity of low cost PCs and tablets with substantial DSP processing power and an increasing awareness of digital signal processing in the amateur community have created an explosion of digital modes. Some of the challenges this poses are lack of portability, inconsistent “virtual TNC” interfaces and protocols optimized for single uses. ARDOP is a new protocol development which was targeted to address these challenges. The development started in 2014 and Alpha testing of the ARDOP_Win TNC (Windows version) was begun in April 2015. From the beginning the protocol was designed to cover a wide spectrum of amateur uses and be fully documented with open sourced code to encourage learning, experimentation, evolution and portability to other platforms both software and hardware. Key words: ARQ, FEC, 4FSK, 8FSK, 16FSK, 4PSK, 8PSK, WINMOR, cyclic prefix, bandwidth negotiation, automatic timing, open source and sound card protocols. Today’s computing platforms (PCs, laptops, tablets and smart phones) pack more numeric processing capability than expensive dedicated DSP hardware of just 10 years ago. This with simple low cost sound cards/interfaces and modern radios with built in “sound cards” combine to make the setup and experimentation of software generated digital modes an important part of our amateur radio hobby. These modes range from simple keyboard and weak signal modes such as PSK31 and JT65 to more complex high speed message/file modes with the ability to automatically adapt to changing signal strength and propagation conditions. WINMOR [1] developed by one of the authors in 2008 has seen good acceptance as a low-cost Pactor alternative in various messaging systems like Winlink 2000 and BPQ32. Each generation of protocol and increase in low cost DSP equipment provides an opportunity to expand both the performance and flexibility of software controlled digital modes. But the development, optimization and support of a full featured digital protocol require a substantial contribution of time and skills that should be spread over many applications, operating systems and years of use. The development of ARDOP started with a short list of target objectives: • Open Design promoting targeting to various computer, OS, and hardware platforms • Wide range of bandwidths to optimize spectrum usage • Automatic channel adaptability…ability to adjust to changing propagation and S:N • Support for both connected ARQ (Automatic Retry reQuest) and multicast FEC (Forward Error Correcting) transmission modes. • Minimize interference potential (bandwidth negotiation and effective busy channel • detection) • Flexible operating modes and radios. Compatibility with popular voice grade HF and VHF/UHF transceivers using modulation optimized for the frequency of use. • Full binary transmission and support for multi-language UTF-8 character sets. These expanded over a period of months to first a skeleton specification and finally a full detailed specification with detailed spread sheets showing the composition, bandwidth, robustness and speed of several modes across a 200 to 2000 Hz (audio bandwidth) spectrum [2]. In deriving the specification care was taken to provide avenues to encourage experimentation yet not impact the compatibility of compliant implementations. The experience with hardware TNCs and the portability of virtual (software) TNCs such as WinMor has confirmed the benefit and flexibility of separating the “TNC” or modem function

———————– Page 20———————– from the host (user) application. This promotes portability and allows the same TNC code or hardware implementation to be used (without change) in a variety of diverse applications such as keyboard clients, messaging systems, tracking functions, sounding systems, emergency beacons, etc. We chose this path to allow us to focus first on the protocol and TNC and not the final user host application. To the user the virtual ARDOP TNC operates similar to a hardware TNC and like a hardware TNC can display operating parameters or hidden away to avoid clutter. Figure 1 is an example of the ARDOP Win TNC showing a small but rich panel to display operating parameters, transmission progress and for the entertainment of the operator! The virtual TNC can interface to the host program via a TCPIP connection (wired or wireless), a high speed serial connection or a wireless Bluetooth connection. This permits not only flexibilitybut the ability to operate the TNC/Radio combination remotely from the host software. Likewise a hardware implementation of the protocol (e.g. PIC microprocessor with sound card chip) could interface to the same host software and provide functional equivalence and compatibility. At this writing, the ARDOP mode is in Alpha testing. Participating stations have implemented it on both Windows and Linux with better than expected result using a demo application called V-chat and as a WinLink server node with BPQ32 and LinBPQ. It is expected that the Open Source Code will be released sometime next year, opening the mode to public development and porting to other languages and platforms as well as development of client side applications such as a WinLink client.

Advertisements