Yep, everything not analog voice. CW arguably included, as per a persuasion just below.

There's even digital HF voice, not mention all those VHF/UHF packet voice things from rig manufacturers vying to capture some of your cashflow.

Here's a bit of heresy. Even Straight Key CW is at least partially digital ... or literally so if you consider your digits. CW is a pure, if imprecise, ASK (amplitude shift keying), perhaps the most basic kind of digital moduation. But the case is closed if you consider that the ultimate basis of digital to lie within discrete communications theory. This is because CW employs an alphabet, one if not the most quintessential thing about digital information transfer. See any text on information theory. I don't mean to incur any wrath here. Some very solid fists out there are entirely musical in their rendition of CW. My hat's off. But it's still digital.

Many newcomers to ham radio come in these days intrigued by digital. It can be a lot less costly, and can fit into the most constrained station scenarios (I'm thinking HOAs, but apartments are example enough). And, if you are still active in any kind of school, check out ARDC Scholars. And your school's ham radio club. If there isn't one, start one!

Computing meets radio, possibly forming the future of ham radio. Sixty years ago this was not so!

Nowadays in tech, most younger folks think bytes, if not algorithms, if not AI. Only later, for some, EM fields.

So digitized hams must hook up these two domains, the discrete and the continuous. That's the next tab.

 

 

There be interfaces in all directions these days. It's why we have standards. Multiple, oft-non-friendly standards.

To be digital (ham) radio, really any digital radio, you've got to get from bytes to waves. The "radio" has become just another module on the road to nirvana.

So, a personal story. I got this radio. It has interfaces. And how.

The challenge was getting my rig to talk with my Mac (running its native macos). I got it going with a USB-to-UART Virtual COM Port (VCP) from Silicon Labs. That made a Mac nice with a modern rig that sort of expects Windows!

My Mac's time of day via internet cable was, right off, within tens of milliseconds of "Internet time." And upon installing WSJT-X, it just ran, albeit with one odd glitch. Each start-up of the WSJT-X app required re-assigning that UART VCP a new, unused port name. Who knows why, probably a glitch with an old version of macos (10.13.6 High Sierra)? But it's manageable with a few corrective keystrokes. So live with it. The perfect is the enemy of the good.

Now my Mac was running USB channels (control plus two digitized audio channels) to and from the Yaesu, and in lockstep with everyone else's interval timing, the essential thing in these "automated" digimodes. The next stop (most everyone's) was FT8, which is pretty legit at 5W ERP, as opposed to radiating that much on WSPR, which is pretty questionable (but inevitable out there given modern transceiver minimum powers). I fired up FT8, let WSJT-X automatically set the FT8 watering hole's network frequency, and made a few contacts. Almost too simple. See the FT8 tab.

 

 

Newbies may notice WSPR first - I did, and after all, it's a roughly $200 entrypoint into ham radio (a single board transmitter, - license required! - battery pack, case and some good-enough antenna). What's not to like?

WSPR, for Weak Signal Propagation Reporter (I guess a beacon can report, so everyone including the FCC calls it that), was intended to let a very large number of stations share a very limited "network" bandwidth of some 200 Hz per band (LF through UHF, at least) in a sporting way. It was intended to indicate some current path condition from a beacon station to some other place out there in the rest of the world. Viewing is enabled by the WSPRnet "report-back system" from receivers anywhere, live on the web. A ham radio "killer app," if ever.

I've WSPR'ed twice, both times with someone else's 200mW ZachTek rig (a small box hooked to a battery) on 20m plugged in to my antenna for an hour. The idea was to get a simultaneous two-station antenna comparison - the visitor here having a second, identical ZachTek (so cheap, why buy just one?) back at his station on his antenna firing away in parallel. It enables comparison data like a charm, racking up pairs of SNR reports from WSPR monitors across the US. The data can be captured by a popular WSPR fusion site or the original WSPRnet site. Yeah, I have a comparatively lousy DX antenna, so I always lose the contest. There are so many web pages and projects devoted to WSPR-enabled antenna analysis, that I won't bother you with links. Just google it.

I notice that WSJT-X supports WSPR via the radio it's interfaced to. That's going to be, almost inevitably, a minimum 5W radio. Which is too bad. WSPR at 37 dBm is hardly "weak signal." I've yet to do that. But I see other folks have. Looking at that very interesting fusion site (see above), I notice just for 20m, that there are about as many folks at 5W (37dBm) as there are at 200mW (23dBM), a 15dB (dis)advantage spread, ironically with similar received distance spread. I.e., you hardly need a 15dB advantage to be heard most anywhere those "big signals" are heard.

We're now seeing "portable" WSPR, maybe POTA, SOTA or IOTA, even AOTA. (Where will all this -OTA stuff stop? It won't; maybe that's the point.) And we may also contemplate mobile WSPR. If not too fast, it can survive variations in doppler. A bicycle going in one direction (steadily) at 15 MPH generates a steady-state doppler of 0.3 Hz in the WSPR-popular 20m band. This would be no problem for "routine" WSPR, which doesn't care at all about absolute frequency so long as it falls into the WSPR network bandwidth on any given band. But turning, changing velocity vectors, will degrade tracking. Yet, a cyclist may not change direction much in 2 minutes. If doppler varied but 0.1 Hz or less, it would matter little to a WSPR demodulator (presumably using FFT detection of the 4FSK waveform, having a relatively wide 1.6 Hz orthogonal(!) spacing between FSK tones). So, cycling with WSPR, anyone? Note: Cycling digitally was an early thing. A guy at Qualcomm in the early '90s bicycled around San Diego's North County with a prototype IS-95 modem (UHF ham band?) strapped to a wheel rack to see if it might work. The rest, as they say, is history.

The WSPR beacon has been a big success ever since 2005 or so. The QRPp "natural nature" of the beast was a brilliant stroke, feasible with milliwatts (people have claimed microwatts, not sure if I believe those nanowatt claims!) due to its roughly 1/2 bps rate (see the next tab). But, is it possibly misnamed? It is a beacon, certainly. But there's hardly any "report" in it, just a call sign, a place (low res Maidenhead grid code) and power (in TX output dBmW). The acronym may just be poetic license. WSPRnet on the web is the actual real deal, probably by plan all along. Web-boosted radio! Wireless to wired. Quite possibly leading directly to WebSDR and reverse beacon network(ing). I want to say inevitably, but almost nothing is that. Inventive folks have created this stuff, it has not fallen out of a tree.

WSPR uses a K = 32 (constraint length) non-systematic convolutional code to allow a simple sequential decoding algorithm, a software speed compromise they made in 2005 which has a low format efficiency of (162-31)/162 ~ 0.809, expressed in code bits or in information bits, take your pick. Worse, short block lengths in FEC coding are notorious for degraded error-correcting capability, no matter the "strength" of the code. Efficient, effective sequential decoding usually relies on block lengths at and beyond 1,000 information bits. Not 50 bits! One might as well use an only slightly weaker block code (like the extended (24,12) rate 1/2 Golay code, which is trivial to decode using hard decisions) and circumvent this efficiency loss altogether! Yes, hard decision (one bit channel symbols) decoding is up to 2dB worse than soft decision (probably 3- or 4-bit channel symbols in WSPR) in fully efficient decoding. But at these ultra-short block lengths, there may be very little comparative loss. I have not checked this with a simulation, I admit. But I will add that sequential decoding is dependent on getting the job (i.e., decode the previous transmission burst) done before the next one comes in, or it's a failure to decode (that's technically a Pareto-distributed race between decoding time and buffer memory time, the latter effectively being nearly the full 15 seconds for one decode, noting that multiple decodes of different signals are available if each is short enough). Sequential decoding is not of fixed decode time per bit decoded!

 

 

WSJT-X has to be one of the most commented-on software in hamdom.

It's various waveforms (FT8 being but one example) are for weak signal digital ham communications.

WSJT-X has moved its home page from princeton.physics.edu (which no longer exists) over to sourceforge.io. You can find it and a couple improved versions of it at Software for Amateur Radio Weak Signal Communication.

It doesn't take long before WSPR'ers may try out other weak signal formats from its creator, K1JT and crew. These many low power protocols are packaged under a combined radio controller, with a (essentially) short packet terminal protocol suite (yeah, that's a mouthful, but fairly accurate) called WSJT-X for Weak Signal (by K1)JT - X (many modes, or else maybe experimental). There are also hacks of this open source code altering the user interface.

Joe Taylor, K1JT, seems to have created virtually all of these modes for specific, more "science-like," or "sport-like" uses such as QRP HF DX, "moonbounce," or "meteor burst" QSOs. I rather doubt he was surprised to find people turning to them to chase down Big Game certificates like DXCC. He's a smart guy with likely a good imagination.

The most popular (digi)mode in WSJT-X is FT8 for run-of-the-mill, mostly stable channels, say "decent" HF. See my first tab above for the operator experience. See my next tab for a description of the mode.

Beyond WSJT-X modes for weak signals and short transmissions, in true retro, a newbie can then go back to the future with the "old" PSK modes at much higher data rates, often 32 bps and up, opening up the opportunity for actual conversational QSOs, like in CW. This means other software! And of course, you will need yet more power, head to head, than the short FT8 messages require at their lower rates. WSJT-X does none of these higher rate LF-HF "traditional digital" modes. Check the web for those. But it does do one special "high" (at least for VHF ham radio) data rate mode.

WSJT-X supports MSK144. Sounds fast, and it is. K1JT seems to have invented this particular waveform, MSK144, for meteor burst (meteor-scatter, same thing) QSO'ing. It's not a beacon. Meteor burst communications has been around a long time (US DoD did it for decades using their own specialized waveforms). What characterisizes a meteor burst channel is a very short channel availability time, from fractions up to (only!) several, or maybe on the outside tens of, seconds. So one needs a rate some 100X that of WSPR to get even the most meager message across the channel and hear a reply in a typical case. That's what MSK144 is about, sporting a ripping baud burst rate of 2000 bps. At this baud rate, we're talking VHF since FCC 97.305 and .307 allow 19.2 kbaud/sec at 50.100 MHz and up, but not below. Meteor-burst favors the 6m band and that may almost be it. 10m is unusable for meteor burst. UHF is not favorable. It's almost as if the FCC knew that's what hams wanted to do. This MSK144 ham-defined "standard" for scattering off meteor ionization trails is intended as a weak signal mode! And after it scatters, it is. But power improves things as usual. See the WSJT-X User Guide at JT's website.

You are possibly wondering how frequent decent meteor burst conditions are. And so is your reporter. Well, there are annual meteor showers (presumably up to very good) and all other times (presumably dicey). Direction to the meteors matters. And so forth. But here is an astonishing factoid: every day sees, even if only on average, hundreds of tons of meteors, mostly tiny, tearing into Earth's atmosphere (a vanishing fraction making it all the way down). Some (possibly broad) category of sizes will support meteor burst communication. You will have to research it from there. It's worth mentioning that meteors appear to arrive over pretty much all latitudes, from pole to pole. So it may be a more geographically "egalitarian" mode than ionospheric refraction.

Finally, so where to in digital from here? Well, spread spectrum and FH (no, not the same thing) are presently two immovable barriers to carriers in the 220 MHz band and below. But as Dylan said, pretty long ago but hanging in there today, the times, they are a'changing! We'll have to wait and see.

 

 

As FT8 is so popular, we might as well know what it actually is (as opposed to what's under the hood, which description of the processing would be more involved). So here's yet another description of the mode.

FT8's useful "payload" of 12 alphanumeric characters (in a compression-coded format) in each roughly 13-second transmission time (fitting into the protocol's 15-second, two-station QSO "interval" time per station, in alternation) makes for an information data rate of about 6 x 13 / 13 = 6 bps. That's nearly 13 times faster than the (28+15+7) bits / (162*8192/12000) sec ~ 0.45 bps information rate of WSPR. (Note that WSPR's 12000/8192 ~ 1.4648 raw data rate, or baud per sec, exclusive of the sync pattern, is not the same as its useful data rate!) Both waveforms use rate 1/2 FEC (forward error correction) coding, of differing codes, but similar coding gain.

FT8, again being a very short block length, is FEC-challenged. FT8 uses a short LDPC (aka Gallager) code, a block code that seems to be more natural in a short block setting than a convolutional code. Yet, even so, LDPC codes of high code rate also need something the rough order of 1,000 or more data bits to approach their error-correcting potential. Gallager codes were originally called "capacity-approaching" codes, no less. But nothing like that in FT8! So again, an odd choice for FEC. Why not instead something simple, like a sequence of Golay codewords (which are decode-able by almost instant table look-up), or else maybe a short BCH code? What's almost more important in these super-short waveforms is how the symbol interleaving helps most any code avoid blunt failure from the almost inevitable burst errors of non-Gaussian HF channels when the received weak signal is really near the energy-limited capacity threshold. Nothing beats capacity, and when enough errors strike, decoding is impossible.

Let's move on from FEC nits. Yes, nits literally exist; they are the natural base (e) correspondents to base 2 bits!

From those data rates above, you expect to need at least 11 dB more umph when operating FT8, compared to WSPR, to complete a TX to RX transfer. But WSPR is not a QSO mode, just a one-way beacon. So it's not really comparing the utility of the two. It's not apples to apples. In the end, however, FT8 QSO transmissions can be received at the same low SNR as WSPR if the FT8 is done at 11 dB higher TX power (than for WSPR), everything else (antennas, conditions, etc.) remaining the same. But QSOs need some slow-fade margin, for multiple block exchange (or "back and forth," if you will) reliability that hangs on the (relatively) "steep cliff" of the decoding output error-rate to SNR performance curve. On one side of that cliff, all is OK. On the other side, maybe even only a half dB less, all is lost! So call it a couple dB beyond that 11, maybe ~13 dB, to level the playing field wrt what you miight call "mission reliablity," the mission being moving the exact message to the user on the other end. That's 20X the power needed for WSPR. So a 200mW WSPR compares to a 5W FT8 for completing the two disparate missions. WSPR has, at that commonplace 200mW level, probably been planned all along to dovetail in performance with a similarly commonplace FT8 at 5W. So why are some folks running FT8 at 25W and up? After all, many if not most programmable rigs will go down to 5W. There are two possibilities. 1) Because their antennas are relatively bad, and that justifies it for them. 2) Simply because they can. So much of ham radio is 2).

Bandwidth (BW): FT8 by-the-WSJT-book uses shaped symbols (bauds). These are likely SRRC (square root raised cosine) filtered shapes, at a similar "alpha" to those used in xG cellular communications. That means the 3dB BW is about 25% larger than the symbol rate expressed in Hz. We said 6bps above. So a WSPR signal is about 10Hz (for a memorable number) "wide." That means that about 100 WSPR signals could fit side by side into the FT8 "net channel " 1kHz BW. But, there is no such thing as an organized FT8 network! Individuals signals just fall all over this rough channel width, that due to disorganization. There simply is no organizing network control. So we get QRM and inefficient use of this "space." But it's ham radio. And at any particular receive site, quite a few FT8 signals are separable (meaning, decodeable). And at HF, they fall (in SNR terms) where they may, being even many tens of dB different for otherwise identical transmit ERPs. So, in practice, many hundreds of FT8 signals can happily coexist at any single instant of frame time. Some may find your CQ or reply, if the other op so wishes! So there.

User experience: I found FT8 exciting for the first couple contacts, then trending toward boring as heck. You almost just watch the program run from your keystroke to initiate and complete a call. Maybe 45 seconds (three intervals). Yet this is a very popular mode. You are watching your computer, pretty much ignoring your rig, except of course for antenna tuning and power setting (taking care to lower output power to a level your rig can sustain for tens of seconds continuously; this will be some 25% of your max power capability, generally). I will grant that you also try not to step on others in transmit and try to select your quarry from many FT8 stations on line, and that can be devilishly difficult given how everyone seems to hop around in the roughly 1 kHz-wide FT8 network channel.

The automated digimode payoff? I am given to understand that low power stations (I mean 25W and less) chase down WAS, and even WAC, in short order on FT8. Some guys with a kW key-down apparently chase down DXCC pretty fast. This last is a fish-in-a-barrel proposition that doesn't exactly cry out as "sporting." Because the WS in WSJT-X stands for "weak signal," not "boomer."

Finally, variants on FT8 have appeared, just as you'd expect. One of them is JS8, a mode I haven't tried but which purports to support "chat" more attractively than FT8 might for that particular use. JS8 has its own frequencies, etc. It sounds like a higher capability digital conversation mode than, say, RTTY, a venerable mode often used for chat. The boost would be tolerance for weaker received signals, etc., the original motive for FT8 and its siblings. I'm not endorsing anything here, just noting an almost endless appearance of new ways hams use their radio bands.

 

 

There are a few things, common in commercial digital communications, pretty invisible in ham radio. Call them the "digital frontier."

One is power control. Another is adaptive data rate control. Yet another is adaptive error correction coding rate control. These three share in common the need for feedback, end to end. They benefit from realtime knowledge of the channel. They are combined in cellular communications to reach for simultaneous high availability (low drop out rate) and high network capacity (minimizing the power, time and bandwidth of any particular user). There appears to be no FCC Part 97 prohibition against any of this. And the techniques would be interesting in helping address QSB (of the channel) and even QRM (between adjacent users). I have never heard of ham experiments in any of this. But hams being what we are, I'd not be surprised that some of us are experimenting with it.

Other frontiers might involve very low code rate FEC for "ultra QRP," denoted QRPp as I've heard it denoted. WSPR is only a rate 1/2 K=32 non-systematic coding (sequentially decoded), which gives up several dB compared with "turbo" codes or Gallager (HDPC) "capacity-approaching" codes. To use either of these for their potential is to need a greatly increased transmit encoded block length for a similar "payload" (useful information) length to WSPR or FT8. Since WSPR is de facto legit, there would seem to be no regulatory obstacle to "going long" on packet length. Why not go on for many minutes? The FCC rule requiring station ID once each 10 minutes still applies. But there could be embedded ID at such intervals. Band conditions and QSB might interfere with such longer, sustained transmission viability, you might say. But HF band conditions can also be stable for tens of minutes, occasionally an hour, at some times of day, especially if interleaving techniques are applied. This could give rise to truly small HF stations, meaning small antennas, helping out hams who simply want their beacon heard. Bandwidth need be no more than a WSPR signal, perhaps less.

For another variation on station "mode," you could go mobile with it. This is already done by WSPR stations in cars. But you could even do it on a bike ride (using a really short antenna on a higher HF band) and try to "record" your cycling adventure on a receiver 20,000 km away!

And we should mention the FCC's new ruling on digital limits. It's no longer 300 bps (at HF at least). It's now 3 kHz occupancy bandwidth (of a single signal). That could support a lot higher data rate, at least 3 kbps. Now we're talking internet, of the '70s that is! Well, it is a hobby!