FT8 has been a revolution. The technology has made DXing really easy. Or has it? I continue to be amazed at how much difficulty people have working DXpeditions on FT8. 

Last year, there were DXpeditions to Bouvet (3Y0J), Crozet (FT8WW) and Sable Islands (CY0S). The most recent DXpedition to Glorioso Islands (FT4GL) has brought it all back to me.

Let's start off with a few observations on people trying to work these DXpeditions:

• Wrong Cycle - It's amazing the number of folks trying to work DX that are calling on the wrong cycle. FT8 has even and odd cycles. Even cycles start at 00 or 30 seconds, and odd cycles start on 15 and 45 seconds. You always call on the cycle the DX station is NOT transmitting. Indeed, if you double-click on a decode of the DX station, WSJT-X will set up the correct cycle. So how are people getting it wrong?

September 1985, I purchased a Kenwood TS-430S and became more active in amateur radio. In the apartment where I was living, I snuck wires out of a second floor window and began to make contacts. 

In October, I got the notion to try some Radio Teletype (RTTY). I built a demodulator using a circuit I've forgotten. Perhaps it used a couple of NE567 chips. Having a demodulator, I needed to translate the five-level Baudot characters into ASCII that I could display on the terminal.

(I purchased a Wyse 85 VT-220 emulator terminal in August of 1985, so I was no longer constrained by the 64x16 screen and 1200 bps limitations of the CT-64)

RTTY Decoder

I wrote a program for Flex09 to decode 45 Baud RTTY by bit-banging a PIA pin. I couldn't use the MC6850 ACIA, because it does not support 5 bit characters.

A delay loop established character timing: 

Each pass through the loop consumes 8 clock cycles. With the right value loaded in X, fairly precise timings could be accomplished. A value close to 250 would be 1 ms on a 2 MHz machine. By calling this loop repeatedly, timings of 11 and 22 ms are measured. 

I connected the demodulator output to PIA Port B, pin 0. The program looks at this pin, waiting for a zero. Finding one, it calls the delay loop for 1 ms and checks again. If the pin is still zero, it waits 10 ms and checks Port B pin 0. A continued zero at this point indicates a start bit. The 11 ms total delay places us right in the middle of the start bit.

The next sequence waits 22 ms and then samples of value of Port B, pin 0. It does this five times. These samples are shifted into a byte value, which used to look up an ASCII character in one of two tables -- one for letters, and one for figures -- according to the shift mode. This character is then sent to the terminal, and we go back to waiting for a start bit.

The resulting program is about 300 bytes long. Despite the simplicity,  I had little success decoding RTTY signals. 

In hindsight, there are several reasons for this. 

• Decoding signals off the air that might have been noisy.
• Demodulator circuit was completely untested and might not have worked.
• No experience with RTTY, so signals might not have been properly tuned.
• Precise value of the 1 ms time delay not known. I used values of 230 and 240, allowing cycles for other program logic. 

At some point, I distinctly copied "RY RY RY RY RY RY RY" from someone, but not much else. Later, I figured out this meant my program, at least, was working. 

Hardware Solution

In November 1986, I decided to use serial chip that could do five-level Baudot. The MC6850 only allows 7 and 8 bit characters, so I needed a different chip. The NS8250 could do 5, 6, 7 and 8 bit characters, and sports a programmable bit rate generator for all the common RTTY rates. Hence, I added an NS8250 UART to the baud-rate generator board. 

Funny, though -- I never wrote software to use the NS8250. In February 1989, I removed the NS8250 and its associated circuitry. 

I didn't become active in RTTY on the air until 2005, using Cocoamodem.

Nearly twelve years ago, I wrote about completing Worked All States on six bands. I'd worked all states on 160, 80, 40, 20, 15 and 10m. About three years ago, I finished up 30m, so now it was seven bands. However, finishing 17 and 12m seemed like it would take forever. I felt stalled out.

A couple of months ago, it occurred to me that I was only four band-states away from Ten-Band Worked All States. I needed Delaware on 17m, Kentucky on 12m, and Alaska and Hawaii on 6m. 

The 6m states would have to wait -- I'd need very special conditions to work either state. But with the recent rise in sunspots, working those close-in states on 17 and 12m seemed do-able. The biggest problem would be operating the Gwinnett station. That was solved after I configured the RemoteRig devices to allow remote operation. 

Indeed, the first afternoon operating remotely, I was able to work Kentucky on 12m and the LoTW confirmation came the next day. Finishing off 17m took a month longer.

It was surprising to me how calling CQ DEL AA4LR EM83 would gather so many responses from people who were not in Delaware. I worked at least one station in Delaware, but the LoTW confirmation was not forthcoming. Then the RemoteRig Control device no longer powered up.

I got lucky one Friday afternoon when I was in Gwinnett county and managed to get a legitimate answer to my CQ DEL message and a confirmation later that day. I'd done it. Worked All States on Nine Bands. 

Now, I just have to wait for those special conditions in order to work Alaska and Hawaii on 6m....

Sometimes experiment pays off. You never know until you try.

I was reading an article about remotely controlling computers over the internet. It occurred to me that if I could do this, it would be easy to operate FT8 from my Gwinnett QTH when I was at the Fulton QTH. Although I have rigs in both locations, Gwinnett is where I have the K3, and can operate on 6m. 

I started to research solutions. I found a product called RealVNC that can be licensed free for non-commercial use on up to five computers. Comes with a separate server and viewer product, and it works on Macs as well as Windows, Linux, even the Rasberry Pi. 

You have to create an account on their web site, but the installation was easy. I have a MacBook Pro hooked to the K3 at the Gwinnett QTH. I installed the server there. Then I installed the viewer software on a couple of Macs, and one Windows computer. 

Making the connection from Viewer to Server requires 2-factor authentication, so it is pretty secure. 

This software worked great. I was easily able to connect to the MacBook Pro and use WSJT-X. The K3 has to remain turned on, and I have no way to remotely change antennas, so I left it switched to the 3-element 6m beam. I also have no way to rotate the antenna remotely (it uses Armstrong rotation...), so I left the beam pointing SouthEast. I was hoping to pick up some propagation to the Caribbean or perhaps Central or South America. 

The first week of this experiment bore fruit the next day. I was in Fulton county, but checking I lucked into an opening to South America, where I worked two stations in Chile and two in Uruguay. Two new countries and four new grids! The next day, there was a powerful, but brief opening to the Cayman Islands, and Belize.

While one cannot predict 6m propagation, remote operating gives me a tool so I don't miss out on openings while I'm away from the Gwinnett QTH. 

This is only Level 0 of Remote Operating. I can only do FT8, and I can't change bands. That's next, I'm working on an automatic antenna switch driver to choose an antenna by the band selection of the K3.