[CALV-AUXCOMM] Fwd: Digital Mode Software Downloads
Shawn Donley
n3ae at comcast.net
Wed Nov 17 13:49:01 EST 2021
If you missed the Calvert AUXCOMM net last night, we're planning on doing some digital mode practice in the near future. Since we have several new members, the info below is to get them up to speed.
Looking towards practicing Winlink, MT63 and old style AX-25 packet.
N3AE
Calvert EC
> ---------- Original Message ----------
> From: Shawn Donley <n3ae at comcast.net>
>
> Subject: Digital Mode Software Downloads
>
>
> All,
>
> As promised during tonight's AUXCOM net, here's the links for downloading software for some digital modes.
>
> If you're having problems, give me a call (240-298-3115) and I'll try to help. The info below is a top level summary of what's needed to run the modes shown.
>
> A quick note... these digital modes over a radio (HF or VHF) are a LOT slower than your internet connection. Don't expect to send long messages or big attachments. For example, on 2M Winlink, this email with its attachments would probably take 10 minutes to send via a Winlink gateway station.
>
> ------------------------------------------------------------------------------------------------------------------
> Winlink 2000
>
> Software download at https://downloads.winlink.org/User%20Programs/
>
> Download the software installation instructions and Winlink Express Install.zip
>
> Winlink is the de facto EMCOM digital mode for our ARRL section. Its origins come from the desire for blue water sailors to have some means of sending and receiving short emails via HF. Winlink messages can be sent to destination stations identified by their callsign or even to an internet email address. It's also possible to send messages by radio-only between two stations by using a peer-to-peer (P2P) session. One disadvantage of Winlink is that third parties cannot easily copy a message being exchanged by two other stations over the air. This leads to some loss of situational awareness during an emergency.
>
> Winlink requires a Terminal Node Controller (TNC) for operation on VHF and UHF (Packet Winlink session & Packet P2P session) , and a sound card interface for operation on HF (Ardop session & Ardop P2P session). The Winlink Express software also provides a means to send and receive messages over the internet (TELNET session) so it's still possible to "play" before you have a radio and TNC set up.
>
> The latest session type recently added is VARA (VARA HF Winlink, VARA FM Winlink, VARA HF P2P and VARA FM P2P. VARA requires downloading and installing third party software that requires purchase of a license. For the moment, we'll skip that. But VARA has demonstrated a much faster message rate than other modes, so eventually we may need to take a look.
>
> If you already have a sound card and a fairly new computer, it's possible to use a software package to emulate the hardware TNC. I've never tried that myself but some folks might want to give that a try. See https://packet-radio.net/direwolf/
>
> -----------------------------------------------------------------------------------------------------------------
> MT-63
>
> Software download at http://www.w1hkj.com/ or https://sourceforge.net/projects/fldigi/
>
> Download FLDIGI, FLRIG and FLMSG along with their user manuals
>
> The FLDIGI software includes a vast number of different digital modes including PSK-31 which was one of the most popular HF digital modes before FT8 was released. The mode of interest for EMCOM is MT63 which comes in several flavors with different bandwidths and corresponding different messaging speeds. The MT63 modem uses strong forward error correction so unless conditions are really bad, you will see perfect copy with no errors. Unlike Winlink, third party stations can receive and copy messages. MT63 is primarily a radio-only mode and does not rely on the Internet. We have successfully used it locally on HF, VHF, UHF and even via our 146.985 voice repeater (yes, it can be sent through a voice repeater if needed).
>
> Because of bandwidth restrictions imposed by the FCC, we're limited to MT63-1000L on 10 meters. MT63-200L can be used on 2M and up. MT63 is also used as the "core engine" in several EMCOM packages including the Narrow Band Emergency Messaging System (NBEMS) and Outpost (Google for info).
>
> MT63 requires a sound card interface between your radio and the computer but in a pinch it's possible to copy MT63 by holding the computer microphone up to the radio speaker, and send MT63 by holding the radio's microphone up to the computer's speaker.
>
> ---------------------------------------------------------------------------------------------------------------
> AX-25 Packet
>
> Old fashion AX-25 packet just requires some sort of terminal program like Putty and a TNC, or TNC emulation software and a sound card. Plain old AX-25 packet can be used between two station (actually more than two with multi-connect) with guaranteed good copy. Each "packet" includes check sum data and if the receiving station decodes the message but has the wrong checksum, a request to re-send is issued. So in good paths, this works fine. If the path is not the best, there can be a lot of "retries" and possibly a disconnect of link if the retry limit is reached.
>
> It's also possible to send packets without being "connected" to another station, called unproto mode. If there's a group of stations with good paths between them, it's possible to have a digital round table by operating in the unproto mode. A digipeater can be sued to stretch distances in both the AX-25 "connected" mode and the unproto mode.
>
> ------------------------------------------------------------------------------------------------------------------
> Our local digipeater
>
> We have a 2M digipeater on the state highway tower in Prince Frederick. The callsign is K3CAL-1 on 145.750 MHz. This digipeater can be used to reach one of the area Winlink "gateway" stations that move Winlink messages onto and off of the Internet. The digi can also be used with AX-25 packet.
>
> In the longer term, we're hoping to put up our own Winlink gateway station at Mt Hope.
>
> ------------------------------------------------------------------------------------------------------------------
> Other info
>
> I've attached a document describing MT63 and another document with web links of interest.
>
>
> Have fun
>
> N3AE
>
-------------- next part --------------
Narrow-Band Emergency Message System (EBEMS) - MT-63 Operating Instructions
http://www.wb2lua.com/papers/NBEMS.pdf
MT63 Spectrum
http://www.w1hkj.com/modes/mt63.htm
http://www.arrl.org/files/file/On%20the%20Air/Tutorials/Introduction_to_NBEMS_ARRL.pdf
http://sacvalleyares.org/contents/ARES%20Documents/Training/Sending%20messages%20digitally/Comparison%20Chart%20of%20Digital%20Modes%20for%20Emcomm.pdf
http://www.qsl.net/ah6rh/am-radio/emcomm/nbems-for-others.pdf
http://sacvalleyares.org/contents/ARES%20Documents/Training/Sending%20messages%20digitally/Packet/Outpost%20Packet%20Station%20Quick%20Start%20Guide%20100613b.pdf
http://www.outpostpm.org/index.php?content=about#what
www.outpostpm.org/docs/OutpostTnT-Slides-220.ppt
www.bucksares.org/meetings/20150310Outpost.ppt
http://microhams.blob.core.windows.net/content/2017/03/MHDC2017_EMCOMM.pdf
-------------- next part --------------
*MT63* is a text only digital radio modulation mode for use in high
noise/high reliability situations. It was developed by Pawel Jalocha,
SP9VRC. MT63 is perhaps the most elaborate user of error correction
techniques of most ham radio public digital modes. It uses a very
efficient error correction method that employes character redundant
sequences over several data packets. It has 64 tones spaced 15.625Hz
apart, in the 1kHz bandwidth. It is so efficient that even if 25% of the
character block sent is obliterated, it will give perfect copy. This
method of spreading characters from multiple words over several packets
is known generally as Forward Error Correcting (FEC). The FEC error
correction employed by MT63 uses a Walsh function that spreads the data
bits of each character across all 64 of the tones of the signal spectrum
and simultaneously repeats the information over a period of 64 symbols
(at maximum interleave) within any one tone. This takes 6.4 seconds. The
combination results in good impulse noise rejection. At the same time,
in the frequency domain, significant portions of the signal can be
masked by unwanted noise or other transmissions without noticeable
effect on successful reception. In fact, during tests conducted by MARS,
data and voice transmissions were successfully received at the same time
within the same audio passband.
Transmission speed is good because there are so many individual tones to
describe the information, while the individual symbol rate per tone can
remain slow (which is good protection against QRN and most QRM).
When conditions are good and audio bandwidth is not an issue, MT63
(particularly the 2 kHz version) using the “long interleave” setting is
the best sub–mode to use. The data rate is good and the compound use of
error correction techniques results in a robust broadcast mode readily
available to the amateur radio operator. Although it can be a little
tricky to identify by ear or on the decoder waterfall, the mode has a
fairly generous tolerance to tuning inaccuracies and its immunity to
short period impulse noise is superior to most. General wide band noise
is also well tolerated as is coherent noise (e.g. a single tone) in band.
Unlike most HF digital modes where a character can be lost or changed
into something else, by a single noise burst, MT63 is inherently very
robust, because each character (or symbol as it is sometimes referred
to) is spread over many tones (to avoid interference such as other radio
transmissions) and over several seconds (to avoid short bursts of noise,
such as lightning).
MT63’s COFDM like properties
* The MT63 signal is spread both in the time domain (temporally) and
the frequency domain (spectrally). To ensure that noise bursts and
other time domain interference artifacts have minimal effect, each
encoded character is spread over 32 sequential symbols (3.2 sec).
* To ensure that frequency domain effects, such as selective fading
and carrier interference have minimal effect, the character is also
spread spectrally by using all the tones across the width of the
transmission.
* On each of the 64 tones, the transmission data rate is fairly slow,
which suits the nature of ionospheric disturbances.
Despite the relatively low data rate, good text speed is maintained,
because the text is sent on many tones at once. The system runs at
several different speeds, which can be chosen to suit conditions, but
100 WPM is typical in the sub–modes of the widest spectral width (1 and
2k modes).
MT63 sounds unusual, (it sounds like a roaring or buzzing noise) but the
performance in the widest spectrum mode is well above normal. It is an
asynchronous mode, meaning there is no connection process, as in AMTOR,
PACKET, PACTOR, or WinMOR. Some users maintain that under poor
propagation conditions (namely excessive fading) MT63 works exceedingly
well. Under good conditions the performance advantages are less obvious.
If the receiver audio passband is of high quality and linear across the
entire demodulator audio passband, decoding in high noise situations is
of much higher performance. As with other multi–tone modes where many
sine waves are transmitted side by side, the transmission audio circuits
should be of high quality and with linear gain across the entire audio
passband (i.e. no mid–band peaking as with older rigs) to minimize IMD
and other passband distortions. The included illustration shows the
audio passband spectrum of MT63 in wide band mode. This passband pattern
is typical of modern digitally capable ham rigs of medium to high quality.
Performance Comparison With Other Modes
There are disadvantages to MT63. First, the mode is broad and is quite
aggressive, (i.e. it causes interference to other modes) but itself is
little affected by other modes. MT63 is also far more immune to
interference and deliberate “jamming” than any of the more conventional
modes. Using the long–interleave option, the spreading is over 64
symbols (6.4 sec latency in 2k mode), with consequent improvement in
resistance to impulse and periodic interference, but of course double
the time taken for the data to “trickle through” the Walsh encoder and
decoder pipeline. Changeover from transmit to receive and vice–versa is
therefore considerably slower than most modes due to the data latency in
the decoder as the buffers are flushed. It therefore, requires some
skill and patience in a QSO as it is not a “break–in” mode as you would
think of CW or PSK that have virtually no latency time. Correctly
decoded text can take up to 15 seconds to appear on the screen. A clue
to synchronized reception can sometimes be gleaned if the software has a
digital squelch facility (software based vs. hardware squelch). If the
squelch is set up to be closed when no MT63 signal is present, it can
often be seen to open as soon as it finds MT63 and ideally the text will
follow quite a number of seconds later! In order to make the decoder
start printing valid text as soon as possible, software should be chosen
that has an effective squelch, so as to minimize feeding the decoder
garbage before valid text. Latency in this mode is considerably longer
than other 2FSK or multi–AFSK modes like MFSK16 or even MFSK64L. For
instance the shortest latency time for MT63 is 3.2 sec. in short
interleave 2K transmission mode. The latency time for RTTY is 330 ms.
_Unlike_ OLIVIA and MFSK16 the narrower 500 Hz operational modes are
much slower using MT63 than the wide (2K) mode. OLIVIA is several times
faster and more noise tolerant in the narrow band mode yielding a lower
latency, while conversely MT63 becomes much more robust and has a longer
latency time in the wide band mode. Accurate text copy can be obtained
from MT63–2K when the tones are near or below the noise level under
optimal conditions similar to PACTOR III, although at a much lower text
throughput.
MARS has adopted MT63 as one of the primary modes for ALE operations
between other MARS stations. Alternately, PACTOR II, III and IV are used
where available. The fact that MT63 is a common mode for MARS normal
digital communication speaks to the reliability and accuracy of this
protocol. Military frequencies are not as restrictive (as far as
bandwidth goes) as are amateur bands. Nonetheless MT63 can be an
important player in emergency communications where adverse conditions
exist and where cost may be a factor. Data throughput is well above most
keyboard chat modes and exceeds PACTOR I. Partnered with Automatic Link
Establishment (or ALE signaling see: www.hflink.com), MT63 serves MARS
and many branches of the military as the backbone of their digital
network. Currently, it is not a significant player in WinLink 2000
system techniques for obvious reasons.
For the SATERN Digital Net, MT–63 is a definite plus in local nets where
the use of low noise frequencies (10 meters and up) are used. Local and
regional nets have a significant advantage in throughput when employing
MT–63 for message broadcasts. The HF net on 20 meters suffers due to
broad variations in band conditions and higher noise figures hampering
effective use of MT–63 in the most robust configuration.
During our discussion of digital modes we covered the mode MT63 and its’
importance in ham radio. Stream and MT63 terminal are software modems
and TNC applications by IZ8BLY, Nino Porchino. Nino has made a very
attractive and functional interface that decodes the MFSK8 and MFSK16
modes in the Stream application. He has the MT63 version that decodes
MT63 mode as well. They are very similar in appearance and functionality.
The information provided by the interface controls is relevant and
helpful. Interface to the rig PTT is via the serial port or computer
interface of your choice (e.g. hamlib). While these applications will
run on Windows 95 and 98, it is recommended that you use a 4^th
generation CPU class computer (Intel I–series) with a speed of at least
1.33 Ghz and Windows Vista® or later to avoid speed and lockup problems.
Stream and MT63 can run under Linux Wine if the CPU is 3^rd generation
class or higher running at least 2 Ghz.
Feature Comparison Decision Matrix
Digipan HamScope MMTTY MMVARI IZ8BLY MultiPSK HRD MixW PCALE EzPal FLDIGI QSSTV
*Platform* Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Win/Lin/Mac Win/Lin/Mac
*Price* Free Free Free Free Free Free $79.95US $70.00US Free Free Free Free
*CW* N N N Y N Y Y Y N N Y N
*PSK* Y Y N Y N Y Y Y N N Y N
*MFSK* Y Y N Y N Y Y Y N N Y N
*Packet* N N N N N Y N Y! N N N N
*Q15X25* N N N N N Y N Y! N N N N
*MT–63* N N N N Y Y Y Y N N Y N
*APRS* N N N N N Y N Y! N N N N
*Pactor I* N N N N N Y N N N N N N
*Amtor* N N N N N Y Y Y N N Y N
*Sitor* N N N N N Y N N N N Y N
*RTTY* N N Y N N Y Y Y N N Y N
*OLIVIA* N N N N N Y Y Y! N N Y N
*Contestia* N N N N N Y Y N N N Y N
*THROB* N N N N N Y N N N N Y N
*DominoEX* N N N N N Y Y Y N N Y N
*PAX* N N N N N Y N N N N N N
*Hell* N N N N N Y Y Y N N Y N
*Fax* N N N N N Y Y Y N N Y N
*SSTV* N N N N N Y N N N N Y Y
*Image* N N N N N Y N N N Y Y Y
*Voice* N N N N N Y N N N N Y N
*Rig Cntrl* Y# Y# N+ N+ Y# Y# Y## Y# Y# Y# Y# Y###
X Built In Feature
! May need downloaded module
* With external ALE decode only
** Receive only
+ Using serial port directly
# Using HamLib or RigCAT for radio contol
## Using HRD interface for radio contol
### Using HamLib and CAT/CI-V
More information about the CALV-ARES
mailing list