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 9 or more years using digital modes and as SATERN International Digital Net Manager to give you the benefit of my experience. I will leave the rest for you to research as you see fit.
INTRODUCTION
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 ham radio digital experience. Take the time to use this material to do some on–air listening of 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 and reliabiliity.
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
The PSK mode is a narrow band, low to moderate symbol rate, mode using either single or
multiple carrier differential Phase Shift Keying.
Current supported variants:
BPSK: Binary, 2 constellations 1
QPSK: Quadrature, 4 constellations 1
8PSK: Octal, 8 constellations1
(1) A constellation data display is a convenient way to represent PSK schemes, on a planar diagram, that shows the points in the complex plane where, in this context, the two axies represented are the reference 0 and 90 degrees, and by extention 180 and 270 degrees. Each point ploted on this diagram is the signal received...the X value representing the amplitude of the signal and the axis the phase referenced to 0 degrees. So a BPSK signal sending a digital zero value would be plotted along the X axis with it’s phase (zero degees) being on or near the vertical X axis since there is little to no deviation from the reference. The digital one value is shifted (by definition) either 90 degrees (QPSK) or 180 degrees (BPSK) from zero. Digital values of digital ones are plotted on the constellation along the Y axis (for QPSK) to represent the 90 degree separation from the reference zero degrees (digital zero value)...or...along the lower X axis to represent a 180 degree separation from the zero degrees. For all strict PSK modes, the amplitude is assumed to be the reference zero amplitude. Practicality shows operating conditions cause variations of both amplitude and phase to some small extent. For instance, band-related doppler effect may cause the normally zero degrees reference (as well as all phases referenced to it) to rotate around the center point (zero phase and amplitude). This gives the normal display a “tilted” appearance representing the doppler shift.
One variant of PSK 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 (K2K) 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. The widest sub– mode is the 2–carrier PSK1000R mode at 3600 Hz band width.
The BPSK31 sub–mode is a popular mode attempting 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 frequency 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.
BPSK31 uses 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. Exact QRGs for each band may vary.
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.
With no interleaver and limited coding length, the QPSK mode Forward Error Correction coding gain is limited, and under burst noise conditions on HF the performance is usually worse than the BPSK option at the same baud rate. In general the narrow-band BPSK modes work well on a quiet single hop path, but give poor performance in most other conditions. Another 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.
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 ofnon-text data and the transmission time is extremely slow in comparison to other more capable modes.
PSK63FEC and the PSKxxxR modes are forward error correcting modes. PSK63FEC is compatible with the MultiPsk mode of the same name. The PSKxxxR, or robust, modes use both forward error correction and interleaving to achieve about 4 dB s/n improvement over standard PSK. These modes are used primarily by the PskMail user community. They are the invention of John Douyere, VK2ETA, a member of the fldigi development team.
Recently, Dave and his team has introduced the 8PSK sub-modes. The 8 PSK modes are intended for use on VHF/UHF FM systems (although under very good HF conditions the 8PSK125 mode been shown to be effective). They provide a very high data rate suitable for use with both FLMSG and FLAMP and the transfer of digital data.
The FEC modes do not all use the same Viterbi polynomials to achieve the forward error correction. That is why the WPM rates for the FEC modes are not multiples of the base 125 baud. The WPM rates are only an indication of relative rates. The actual transfer rate is highly dependent on the data content. This is always true for modes which use a VARICODER.
The 8psk signal is similar to both bpsk and qpsk, but with 8 possible phase states instead of the 2 and 4 associated with bpsk, qpsk. The format of the signal does not lend itself easily to a conventional AFC. Instead, the modes should be used with FLDIGI RsID enabled. The RsID signal will both determine the mode and the mode center frequency (to the nearest 2.6 Hz).
A finer resolution of the mode center frequency can be made using the optional pilot carrier. This pilot carrier is placed at the frequency f0 – samplerate / symbollen, f0 is modem center frequency
Samplerate / symbol len is the same as the mode bandwidth.
Decoding errors are reduced as the tracking point nears the actual transmit center frequency. The loss of signal power is more than offset by the decoder improvement. Field testing has shown that the pilot tone needs to be at –40 dB (usually S3–S5 depending on ambient ) or greater (i.e. less negative).
Pilot tone detection does require a bit more cpu power. The pilot tone is detected using a sliding fast Fourier transform (SFFT) which computes the frequency of the pilot to approximately 1 Hz resolution. The SFFT only evaluates the signal at 11 discrete frequencies, so it is necessary that either the RsID, or manual tuning is used for the initial signal acquisition. The detector is set to provide lock when the pilot s/n is 2:1 or better. The signal tracking point is then adjusted to place the pilot tone at the correct frequency location. For example, if the RsID put the tracking point at 1502 Hz, the pilot would then adjust for 1500 (if that is the correct tracking frequency). The adjustment is made once per second. Unlike AFC, which is continuous, the pilot adjustment is discrete and occurs in 1 Hz steps. If the pilot s/n is less than 2:1 then no adjustment is made to the tracking point. The pilot tone is transmitted during the 8PSK preamble as well as during the data transmission. You should see the tracking point adjust once at the beginning of the transmission and then stay fixed.
With these modes, a very linear transmitter is required. Over–driven operation results in excessive bandwidth, poorer reception and difficult tuning. Overdrive usually occurs by having the audio signal much too large. These are very sensitive modes and usually very little power is required. QRP operation of 80, 40, 30 and 20 meters can provide nearly 100% copy over multi–hop paths. In many instances PSK can provide better decoding than CW.
Setting up for a good clean on air signal that will receive the accolades of your QSO partners is easy. Follow the instructions in FLDIGI docs on using the Tune button and you will have a clean on-air signal.
Good reception of PSK signals requires that the demodulator be phase locked to the incoming signal. Fldigi has both a fast acquire / slow tracking AFC system. Place the red bandwidth bar (see above) so that it overlies the desired signal and then press the left mouse button. The signal should quickly lock on a decoding should commence immediately. It is almost impossible to visually tell whether a BPSK or QPSK signal is being received. Under very low noise conditions you might be able to hear the difference, but that is even difficult for most operators. If you are not able to decode a signal that looks like a BPSK and the bandwidth of the signal matches the baud rate then it might be a QPSK signal. Just change mode a try reacquiring the signal.
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, ext. spkr 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 fanatically 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, and 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.
PSK63FEC and the PSKxxxR modes are forward error correcting modes. PSK63FEC is compatible with the MultiPsk mode of the same name. The PSKxxxR, or robust, modes use both forward error correction and interleaving to achieve about 4 dB s/n improvement over standard PSK. These modes are used primarily by the PskMail user community. They are the invention of John Douyere, VK2ETA, a member of the FLDIGI development team.
For those of you who prefer Linux you may want to check out LinPSK as seen in the image below: While it will not perform all the PSK modes of FLDIGI, it does a beautiful job of the simpler PSK31 and similar modes.
(BTW the picture IS Linux and Not Mac OS X. I am just running a Mac–like theme in the window manager. See our Linux for the Windows User guide under Training.)
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 employing homebrew 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 |
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 in the mechanical TTY terminals. 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. The FLDIGI AFSK modulator can use any audio center frequency. FLDIGI can also be to configured for FSK using a serial data interface the radio. FLDIGI AFSK is not limited to the traditional FSK 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:
The two lighter colored bands in the display are the binary tones of RTTY that have been detected by FLDIGI. [Author Note: The frequency displayed in this illustration is the actual transmit frequency (a configurable option) rather than the audio frequency]
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 relatively long time domain. The spectrum display is a display of the near-instantaneous frequency domain for a limited time. The difference is subtle, but distinctive.
In this spectrum display, the two distictive 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 audiio signal when displayed in the time domain.
Many software programs display the audio, spectrum, and/or the waterfall displays. It is a useful and somewhat complicated way of showing the same information – amplitude vs. frequency or time.
You can see from the spectral display that RTTY occupies little spectrum and power is concentrated in only two binary tonal 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 (Reverse mode) 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 to 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 or agressively limiting the signal.
This is an actual on air signal that was being over driven (but not on purpose):
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 relatively 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 mis-tuned. 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:
This display indicates an 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.
The Send Image Dialog is shown with a 160x120 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.
[Author Note: Selection on images and avatars should be made with transmission length in mind. You should already know that THOR22 is only 21.1 baud or 78 wpm. Transmitting images will be relatively slow. Large images my take scores of minutes to send. Not recommended. Any image type should be less than 640x480 pixels in size. Grayscale images (black and white) will be smaller and will transmit quicker than full color.]
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 of OLIVIA 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:
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 2x2 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 |
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 an increase in noise tolerance. In other words, the 32 tones / 1000 Hz sub-mode is quite robust, but nearly 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 MFSK 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 distortions. 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 modes are very useful to send large documents or files when some transmission errors are can be tolerated. Use on HF would be limited to days when lower noise and other band variables are not present. However, practical tests over long periods of time and various conditions, have shown these modes to be quite useful on the HF bands - especially 20 meters and above where noise conditions are lower.
This is an example of properly tuned MFSK16 signal with a s/n of approximately 9 dB.
[Author note: We have seen considerable success with the MFSK-64L (long leader) mode on the SATERN International 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 (similar to THOR). 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 the signal on the waterfall. Your transmit signal, and also the received signal should be centered at 1000 Hz for MT63-500, 1500 Hz for MT63-1000, and 1750 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.
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 (Baudotcodeover 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.&rduo;
“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 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 fequencies, 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.
Some 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.
Numerous attempts at implementing a soundcard based modem have yielded two legacy products still in use today. the AGWPE packet engine is used on Windows and Beowolf on Linux are notable examples.
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 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 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.
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.
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:
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:
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) ARDOP “C”, and ARDOP-Pi has begun and testing on the Windows version began 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, FT-8 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:
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 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.
Rev. 1.01 2017-03-21