|
Although
my favorite digital (as in
finger-powered) mode is CW, I
dabble in others from time to
time, bagging DX stations
that don’t use CW,
assessing propagation or just
trying something new.
Quick links
- Digimode hardware (sound cards)
- MMVARI multimode software
- JT65 and other JT modes
- HF DXing with FT8 including the FT8 Operating Guide
- WSPR and WSPRnet plus SDRs
- QRSS - dead slow computerized CW for DXing over extremely poor paths
- Operating tips for digital DXers - general advice, not specific to any mode
Digimode hardware (sound cards)
 A decade or more ago, this section
of the page would have covered
Creed teletypes and terminal units
full of 88mH chokes. These days,
we’re mostly using PC sound cards
to code and decode all manner of
digital mode signals thanks to
Digital Signal Processing.
Rather than use the motherboard
sound system (so I don’t
accidentally transmit the Windows
bleeps, CDs and movie
soundtracks), I have been using a
USB sound system for digimodes,
specifically an ASUS Xonar U7
7.1
USB soundcard and headphone
amplifier.
I chose the U7 because it:
-
Uses a “high definition” Cirrus Logic CS4398 DAC (Digital-to-Analog Converter) audio chip
capable of 192kHz 24-bit audio sampling;
-
Has a claimed SNR of 114dB and low THD which I guess helps dig out the weak among the
strong ones (although I suspect the receiver noise floor and band noise predominate);
- Has a
stereo
microphone/line input, alllowing me to record and decode signals from both
receivers in my K3 simultaneously (e.g. a DX station and his pileup on split, or two different
10m beacons);
-
Is an external USB device, dead simple to install and easier to hard-reboot than PCI cards or
motherboard sounds if I need to do that;
-
Is packaged in a nice little slimline box, USB powered, with standard 3.5mm stereo audio
connectors on the back and a volume knob on top;
-
Is a current, supported product, certified for Windows 8.1, from a well respected supplier;
-
Costs about US$80, better value than those fancy USB sound boxes aimed at the ham
market and much better quality than those cheap-n-nasty USB laptop sound dongles flooding
the market from BY.
Back to quick links
mmmmmmmmmMMVARI
I occasionally use MMVARI through Logger32 for RTTY and PSK. Running it within Logger32 means I
can log QSOs as I make them, and ‘new ones’ are highlit for me on the decode panes. Here’s a
typical screenshot of the MMVARI window within Logger32:
 |
A: This area is the decoded text from the signal selected on the waterfall (see D).
B: The text in red is my transmission.
C: This is the transmit text area where I can compile and edit a message, before or while
sending it.
D: ... is the waterfall. Audio from the rig passes to the sound card and is analyzed here by
frequency spectrum over time. MMVARI/Logger32 makes an attempt to display the on-air
frequencies, combining VFO frequency information from the rig with the audio frequency. The
two vertical red bars at the top show the sound card transmitting my message, centred
where the little triangle points (I clicked there to select UN1L’s frequency). Below that is a
mostly blue specled area of received noise with 5 pairs of bars representing 5 RTTY signals
within the rig’s 2.7kHz audio spectrum. Below that are three rows of 12 macro buttons, 36 in
total. The bottom line is a status bar with other operating information (e.g. ‘Net On’ means I
will transmit at the same frequency that I receive, while ‘AFC On’ means the decoder will
adjust itself across a small frequency range to peak the received signal).
E: The MultiRX button opens another decode window ...
 |
A: Below are 24 rows of decoded text from 24 simultaneous decoders spread evenly across
about 2.5kHz of audio spectrum. [The number of decoders or channels is user-configurable]
B: The decoded text flows right to left. Logger32 highlights CQ calls with green backgrounds,
and callsigns with yellow which is the colour that I chose for new countries on this mode and
band (same for DXcluster spots). Reports are highlit in grey. I can click any call to pop it in the
log entry window, look up the country, check for previous QSOs etc. Logger32 also
substitutes the chosen callsign in place of $call$ in any macros.
MMVARI can do a lot more than that, such as PSK and other modes, but that’s enough for now.
Go explore it yourself or read about it in the Logger32 User Manual.
Back to quick links
JT65, JT9, FT8 ...
Professor J
oe T
aylor (K1JT) from Princeton University invented the JT narrowband digital modes
for extreme weak signal work. Using DSP/sound card and software processing, audio signals well
below the level discernable by ear can be decoded successfully. By integrating the audio over
several seconds, the signal can more readily be distinguished from random noise. Forward Error
Correcting encoding means that (with rare exceptions) messages are either correctly decoded and
displayed, or not displayed at all.
I doubt someone transmitted the message “+7+/4ZS7JTJ0L” on 15m FT8!
The downside is a low bit-rate meaning tediously long overs and mostly brief, standard, boring
messages. The upside includes working the world with QRP or QRPp and poor antennas, even from
noicy city locations, and efficient use of small slices of the shared radio spectrum.
FT8 is extremely popular on HF. Each FT8 over lasts 15 seconds, taking at least a minute to
exchange and confirm receipt of callsigns, locators and reports (niceties such as 73s take another
30 seconds). The downside of the extra speed (compared to, say, JT65) is less sensitivity and
very little thinking time about what message to send next in response to the message received and
decoded. The sensitivity is still remarkable, hence a few watts are generally adequate if a path is
open. Automating the normal sequence of standard messages reduces the thinking time issue, at
the cost of turning us into passive observers as our computers make QSOs for us.
Under the hood, there’s some complex mathematics going on. The WSJT-X help file tells us:
“Forward error correction (FEC) in FT8 uses a low-density parity check (LDPC) code with 75 information bits, a
12-bit cyclic redundancy check (CRC), and 87 parity bits making a 174-bit codeword. It is thus called an LDPC
(174,87) code. Synchronization uses 7x7 Costas arrays at the beginning, middle, and end of each transmission.
Modulation is 8-tone frequency-shift keying (8-FSK) at 12000/1920 = 6.25 baud. Each transmitted symbol carries
three bits, so the total number of channel symbols is 174/3 + 21 = 79. The total occupied bandwidth is 8 x 6.25 =
50 Hz.”
Most of that flies way over my head ... but there are enough clues in there to start exploring the
protocol, if not designing the Fast Fourier Transforms (whatever they might be) to decode it.
Meanwhile, I’m happy to use it, in the same way that I drive a car without being a metallurgist.
There are a few programs capable of running the JT modes on HF. The original was WSJT-X written
by Joe K1JT himself plus a team of elves. It sends info on logged QSOs to other programs via UDP: Logger32 can now be configured to receive and use the QSO info.
Two variants derived from the open-source WSJT-X codebase are also worth trying: I find JTDX by
UA3DJY easier to use. MSHV by LZ2HV didn’t do so well for me last time I used it but it may suit
you.
JTAlert by VK3AMA is another popular add-on. As a Logger32 user, it doesn’t add anything I need
or want but YMMV.
Back to quick links
HF DXing with FT8 
When I started out with FT8 in July 2017, I made rough notes as I and the HF DX community
learned how to use the new mode. My notes grew into a set of pragmatic “Hinson tips” published
and frequently updated here, then evolved into the FT8 Operating Guide
:
The guide is fairly stable aside from occasional tweaks as I learn new tricks. I’m grateful to all those
of you who have emailed me with feedback, both plaudits and improvement suggestions. The
guide is popular and FT8 is patently a raging success, accounting for about
half
of the QSOs being
made on HF today - all within a few kHz of band space, most operators using low power to basic
antennas despite the lack of sunspots.
I’ve dubbed FT8 the Marmite mode
: it seems hams either love it or hate it. Seldom has a new
mode polarized opinions so starkly, except perhaps when the new-fangled Single Side Band was
introduced, and I guess when tuned circuits, oscillators and smooth sine waves kicked those noisy
spark transmitters into touch.
Back to quick links
WSPR and WSPRnet
WSPRnet
(“W
eak S
ignal P
ropagation R
eporting net
work”) is an HF propagation monitoring
system using WSPR, a weak-signal data mode similar to JT65 that uses digital audio processing on
PC soundcards to encode and decode very narrowband (just 6 Hz!) QRP data transmissions. Each
transmission takes 2 long minutes to transmit the callsign, locator and power. QRP and QRPp
signals are routinely received over thousands of kilometers when the bands are open. In the best
amateur tradition, the original software was written and released free-of-charge by K1JT to help
others experiment. WSPR is now supported in WSJT-X. The neat thing about WSPR is that the
programs automatically upload details of transmitters and receivers to a website where the
information is listed and mapped in near-real-time, so you can see at a glance where in the world
QRP signals are currently being heard on whatever band you choose.
Here’s a screenshot from the original software with some usage notes:
WSPR measures transmitter power in dBm (decibels relative to 1 milliwatt) rather than in milliwatts
or watts, so here’s a conversion chart to make things easier:
The chart is a simple Excel
spreadsheet. By all means
download it if you want to print
it for the shack wall or calculate
different equivalents.
A similar project is running on PSK31 mode - see PropNET.org.
Back to quick links
QRSS
QRSS VD by AJ4VD is easy tonuse: literally within a few minutes of downloading and running the
program, I received the KC0TKS QRSS 10m beacon on 28.221.510 sending “TKS” with QRSS30
(30 seconds per dot). Here’s an image from QRSS VD (click it for a much bigger version):
This grainy image may not look like much to you but I find it amazing, given that the beacon is
transmitting just 25 mW and is about 12,000 km from ZL (that’s
480,000 km per watt,
roughly
ten times further than I have ever achieved by ear, even on an outstandingly good day)!
The QRSS beacon was totally inaudible by ear, of course, but integrated over about 10 minutes the
Morse characters are clearly readable. We can even make out a tiny chirp as the transmitter drifts
about 1 Hz HF during each transmission and a short blip after the S character (which was actually
his full callsign sent in normal CW at 13 WPM, acting as a punctuation mark before the sequence
repeats).
At the time this was recorded, 10m was in good shape: I could hear numerous conventional QRP
beacons and stations in the USA and central America, even Junior, a mobile Jamaican in the
Kingston traffic. It will be interesting to monitor KC0TKS and other QRSS beacons for signs of life
when the band appears dead but is, in fact, merely resting.
Back to quick links
Operating tips for digiDXers
In the same vein as my tips for those chasing or being DX on CW and phone modes, here is my
advice for DXing on any of the digital modes.
|
Pileup-beating
advice
for
digiDXers
|
Pileup
management
advice
for
digiDX
stations
|
|
Lock
your
RX
frequency
on
the
DX
and
turn
off
all
automatic
tuning
(e.g. AFC and NET in MMTTY). Manually select your TX frequency, lock it or pop it in the memory and for sure don’t touch that VFO if the DX calls you! Keep to a sensible range but look for a quiet spot away from the DX stn’s TX frequency (up to 1 kHz away on PSK, probably more on RTTY) and stay put for a while. If the DX seems to drift off frequency, use the RIT on your rig to keep them in tune rather than moving your VFO or adjusting the receive frequency in software. Don’t forget to listen on your chosen TX frequency and watch the waterfall to make sure it’s still clear.
|
Stick
to
the
preferred
band
segments
for
each
mode,
especially
if
this
is a
condition
of
your
licence.
Avoid
the
beacon
frequencies
and,
of
course,
listen
first to find a clear spot.
Always split.
Never
operate
simplex.
Avoid
listening
too
close
to
your
own
TX
frequency.
Turn off all automatic tuning
and
lock
your
TX
frequency
to avoid wandering across the band. Use suitable filters to pick out individual callers. Remember your responsibility to tune within a limited range to avoid spreading the pileup out too far. If stations are clearly not hearing you well, double check that your TX frequency remains clear and don’t forget to send “UP” or “QSX 14085-6” or similar.
|
|
Setup
your
digital
mode
software
and
macros
appropriately
.
When
calling
DX in
a
pileup,
give
your
own
callsign
two
or
three
times
and
listen.
It is
not
normally
necessary
to
include
the
DX
callsign
in
your
calls.
Get your macros ready e.g. in MMVARI: “$transmit$ $mycall$ $mycall$ $receive$” and “$transmit$ $call$ TU $sentrst$ $mycall$ $receive$” (note: using $sentrst$ lets you send genuine reports from your log)
Make
sure
you
can
actually
copy
the
DX
properly
and
have
his
call
correct
(DXcluster
is
peppered
with
busted
calls).
|
The
worst
thing
for
callers
is
not
knowing
who
got
called
due
to
QRM.
Repeat
a
caller’s
callsign
at
least
twice
and give your own callsign frequently, especially if there are other DXpeditions active at the same time.
Get your macros ready e.g. in MMVARI: “$transmit$ CQ DE $mycall$ $mycall$ UP 1 $receive$” and “$transmit$ $call$ $sentrst$ $call$ $receive$” and “$transmit$ $call$ TU $mycall$ UP $log$ $receive$” (note: the leading and trailing spaces are important for readability)
Be
consistent
and
get
into
a
rhythm
for
more
efficient
QSOs
and
to
reduce
out-of-turn
calling.
|
|
Use
multi-frequency
decoding
software
if
possible e.g. $multirx$ in MMVARI. Monitor the pileup to identify who is working the DX and so where he is listening. Look for holes in the pileup in which to transmit. Stay well clear of the DX station’s frequency and respect the band limits.
|
Use
multi-frequency
decoding
software
if
possible e.g.
$multirx$
in
MMVARI.
Monitor
the
pileup
to
identify
numerous
callers
simultaneously.
Avoid
working
callers
too
close
to
your
TX
frequency
or
out
of
band,
and
try
not
to
let
your
pileup
spread
too
far
(no
more
than
a few
kHz
please).
|
|
Do not overdrive your transmitter.
Apart from perhaps overheating and damaging it, your signal will probably become unreadable and create QRM for others. This is especially important if you are using AFSK with tones generated by a PC audio card. Use your rig’s transmit monitor function for a simple but crude quality check. If you have a separate receiver or a monitor scope, listen to/monitor your own data transmissions to check the levels. If not, find a local ham who is willing to help you conduct some tests. If you have trouble contacting reasonably strong stations normally, and especially if you receive reports indicating poor quality signals, check those settings again.
|
Look
out
for
well
modulated
signals
and
make
certain
your
own
signal
is
clean.
Do
not
overdrive
your
transmitter
and be careful not to knock the microphone or PC audio level controls once set. It pays to keep a written note of the correct settings. You should really have figured those out before you left home but small adjustments may be needed in the field: ask a local to check the quality and width of your data signal when you first set up, and act on
any
adverse
signal
reports,
such
as
ghost
signals
either
side
of
your
transmission.
|
|
Back to quick links
|
