Although my favourite digital
mode by far is CW, I dabble
in various others from time
to time, usually just to
collect a few DX stations
that aren’t operating
enough CW but sometimes to
assess propagation or simply
to try something different.
- Digimode hardware (sound cards)
- MMVARI multimode software
- JT65 and other JT modes
- WSPR and WSPRnet plus SDRs
- QRSS - dead slow CW with computer integration
- Operating tips for digital DXers
Digimode hardware (sound cards)
A few years ago, this section 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 with
For some years a SoundBlaster
Audigy PCI card worked fine for me,
better than the motherboard sound
system anyway (the motherboard
still runs my PC audio, so I don’t
accidentally transmit the bleeps, CDs
and movie soundtracks!). After
installing Windows 8.1, the Audigy
card played up and eventually refused
to run, so I replaced it with a USB
sound card, an ASUS Xonar U7
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 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
Is an external USB device, dead simple to install and easier to reboot than PCI cards or
motherboard sounds if (when!) I need to do that;
Is packaged in a nice little slimline box, USB powered, with standard 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 better specified than the sub-$10 USB laptop sound dongles flooding the market.
I’ve noticed lately that sometimes the right channel stops recording. Power-cycling the box by
unplugging and re-plugging the USB cable cures it so I’m pretty sure it must be a bug.
Back to quick links
I 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 type-ahead/buffer and edit text before
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!
Back to quick links
JT65, JT9 ...
Professor Joe Taylor (K1JT) from Princeton University has developed the JT narrowband digital
modes for extreme weak signal work. Using DSP/sound card and software processing, audio
signals well below the minimum level discernable by ear can be decoded successfully. By integrating
the audio over a many seconds, the signal can be distinguished from random noise. Fancy message
encoding also allows common errors to be corrected, so messages are normally decoded complete
and intact or not at all. The downside is a low bit-rate meaning tediously long overs and several
minutes for a minimalist QSO. The upside includes working the world with QRP or QRPp, and
efficient use of the HF spectrum.
I believe there are several programs capable of running the JT modes on HF, although I’m quite
happy with WSJT-X written by Joe K1JT himself. It doesn’t integrate with Logger32 but QSOs are
so slow that I am hardly rushed to update my log manually in another window.
Back to quick links
WSPR and WSPRnet
WSPRnet (“Weak Signal Propagation Reporting Network”) is an HF propagation monitoring system
on WSPR, an experimental weak-signal data mode similar to JT65 that uses digital audio
processing on PC soundcards to encode and decode narrowband (just 6 Hz!) QRP data
transmissions. Each transmission takes 2 minutes to transmit the station’s 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 software was written and released free-of-charge by
K1JT to help others experiment. The really neat thing about it is that the program automatically
uploads 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 your QRP signals are
currently being heard on whatever band you are using.
Here’s a screenshot (with some notes for new WSPR users since the help file is rather basic):
WSPR measures transmitter power in dBm rather than 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
A similar project is running on PSK31 mode - see PropNET.org.
My pal Holger ZL2IO is currently experimenting with Skimmer using the Red Pitaya SDR sold as a
learning/development system and bench test instrument for about US$260. It can monitor 6 HF
amateur bands simultaneously. The high impedance input needs a wideband pre-amp on a typical
50 ohm feedline, and it is vulnerable to local transmitters so it’s best placed at a remote receiving
site - like maybe our previous contest club site along the coast North of Napier. We’ll see.
Back to quick links
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,
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
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 to be 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 digital mode DXing.
(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.
first to find a clear spot.
Turn off all automatic tuning
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.
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)
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)
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.
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.
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
Back to quick links