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?
Endless Calling - I've noticed some stations keep calling the DX after the DX station has QSYed or QRTed. A little bit of hopeful calling isn't unusual on Phone or CW, or even RTTY. But stations continue to call much later -- like an hour later, and they are still calling.
Calling without Response - Some stations don't respond when the DX station calls them. They keep calling instead of advancing to the next step. This can get really bad. During the FT8WW expedition, I saw FT8WW keep responding to the same station for more than 10 minutes. Each response had a different signal report. This made it clear that FT8WW was heading this caller quite well, but the caller wasn't hearing FT8WW at all. Instead, that station took up a valuable response slot for 10 minutes -- denying perhaps 20-40 stations from working FT8WW.
Confusing Fox/Hound (FH) and MSHV - Most DXpeditions using FT8 use either FH or MSHV in order to maximize the number of contacts they can make. It is easy to get confused with these two modes. They appear similar. Both allow for the DX station to transmit multiple FT8 carriers at the same time. FH imposes additional behavior to both the Fox and Hound ends of the contact. In particular, there are audio-frequency dependencies that FH enforces. But, it is perfectly possible to work a Fox station even if you are not in Hound mode. MSHV requires no special modes. And yet someone accused people of DQRM, calling FT4GL below 1000 Hz, when the DX was using MSHV, not FH.
What causes all these odd observations? I believe they all resolve to a single cause -- people are calling DX they cannot hear. That's right, people are calling DX stations they aren't decoding at all.
This is fundamentally wrong. I wrote about this years ago on how to bust a pileup. You cannot work DX if you cannot hear them. If you aren't decoding the DX station, stop calling. Yeah, that's hard, but your calls won't net you a contact, and you may be actively depriving someone who can hear the DX from making one.
I think FT8 has made some people lazy. They hear some DX station is active on some frequency, probably through a spotting network. So they switch to that frequency, set their watchdog timers to an hour or more, and enable their transmitter. Then they go off and drink a few cool 807s while their computer works the DX for them.
Farfetched? No, it explains all the observations above.
Be a good FT8 operator -- don't call DX when you cannot decode them. Wait until you can decode them reliably, just about every cycle -- then start calling.
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....
Last spring, I wrote about using RealVNC to remote control a computer in my shack allowing me to make FT8 contacts on 6m. I have made many contacts using that remote system, including several new countries and grids.
I want to be able to operate the Gwinnett county station remotely -- on any mode or band, as if I were sitting there. Doing this required several connections over the internet, and, being behind on other software projects, it seemed a daunting one.
A company called Microbit (www.remoterig.com) has a solution. The RRC-1258MkII is a pair of devices that establish multiple audio, serial and control links over the internet. One unit sits with the Radio, the other is called the Control. They are similar boxes, with subtle differences: the Control box as a CW speed knob, but the Radio box does not. These units work with a number of radios, including the Elecraft K3.
One operating mode is K3 Twin. In this mode, the Control K3 acts as a front-end to the remote Radio K3. All the knobs and buttons operate the remote radio. Indeed, Elecraft made special, stripped down, non-RF versions of the K3 for this purpose (K3/0, later the K3/0-mini).
This seemed perfect, as I owned two K3 radios. Obtaining the RRC-1258MkII was more difficult. Microbit is based in Sweden. Due to the pandemic and subsequent supply chain issues, they no longer sold them in the USA. I had to find them used.
I managed to find Kirby, VE6IV, who had a set surplus to his needs, and we agreed on a price. Then ensued a much longer negotiation on how to get the funds to Kirby in Canada. Eventually, we figured it out, and a week later, the devices were delivered.
Configuration
Configuration was not plug-and-play, by any means. These boxes are designed to connect to 10/100BaseT networks. I found an old router and set up a local network to do the initial configuration. First step was to update the firmware. This did not work over the network, and I had to use the USB connection. After a few tries, I successfully updated both units to the latest firmware.
The local web server in each box allows configuration of the other parameters. There are dozens of settings, and the manual leaves a bit to be desired explaining all the details.
First order of business was the IP configuration. I opted to define a static IP addresses on my local network. 192.168.1.64 for the Radio, 192.168.1.65 for the Control. You can use DHCP for the Control, but it is easier to change configuration settings when you know the address.
The Radio device needs to be accessible from the public internet. Since I don't have a static public IP address, I opted to use dynamic DNS. RemoteRig supplies such a service, at ddns.remoterig.com. They automatically set up a host address based on your serial number.
I set the web site username and password, as well as the SIP password. Audio was set for 16 bits and 8 kHz dual channel. The COM ports were set with COM1 inactive, COM2 in logical parallel with COM0, and COM3 inactive.
Setup
Next step was to integrate the Radio unit into the Gwinnett station. I still needed to use the station locally. I found that I could connect the local computer through the COM1 port on the Radio unit and still be able to run WSJT-X locally. One caveat - the RemoteRig devices don't pass through the DTR and RTS signals, so you can't do CW keying from the serial port. You also can't update K3 firmware. Both of these require direct connection of the computer to the rig.
The manual shows the Radio unit connected with seven different cables, but only six of them are described in the manual. The seventh cable connects from the I/O port on the back of RemoteRig to the ACC jack on the K3. The Radio unit turns the K3 off when you disconnect remotely. Without this seventh cable, you cannot turn the K3 on when you connect. That took some experimentation to figure out.
Initial Connection
Puzzling out the rest of the operation was easier on the local network. I programmed my Control unit to connect directly to the Radio unit's local IP address. Initially, I couldn't get anything to work. I would have brief periods where the Control unit would connect. I could hear the audio of the radio, and then it would disconnect. Nothing was happening with the Control K3.
Part of the problem is my Control K3 had been upgraded to a KIO3B, so it did not have an RS-232 jack. Generally, I used the USB port. The KIO3B has an RJ-45 jack labelled RS-232/P3, and I had a cable designed to plug into the P3. I used that cable, but it didn't work. I decided I needed a special cable from Elecraft, part #E980297, an RJ-45 to DE-9S.
The new cable didn't work either, and that lead to more sleuthing. I tried using the K3 Utility on this cable, and it didn't work either. I then discovered that the CONFIG:RS-232 menu had to be set to 38400 b for the serial connection to work. That was part of the problem.
A bit more checking and I determined that the RemoteRig COM2 jack required a null modem cable between it and the K3. I had that, and it required a male/male DB-9 adapter. Both these items were in the batch of cables that Kirby shipped me.
With CONFIG:RS-232 and the correct cabling, the Control unit placed the Control K3 into TERM mode. I successfully connected locally.
Remote Connection
Connecting through the dynamic DNS address was the next step. I figured I had to change the SIP Contact parameter on the Control unit. That was correct, but it would not connect. Then I thought perhaps it didn't work because I was trying to connect on the same IP address on the public network. So, I packed up the K3 and the Control unit and took them back to Warren county. But, it didn't work there, either.
This was frustrating. Then it occurred to me that perhaps I had to re-program the firewall of my Gwinnett county router to let certain traffic pass. I lamented that those experiments would have to wait until I could pack it all up and go back to Gwinnett county to fix. Then it dawned on me that I could use the RealVNC connection to my shack computer to re-program the firewall remotely.
Programming the router was not simple. I used the IP Allocation mode of Default Server to direct all incoming traffic to the Radio unit IP address. That worked! I was able to connect and control the station.
This configuration worried me. RemoteRig uses four UDP ports, plus TCP port 80 for the web server configuration and port 23 for telnet configuration. Having those TCP ports open on the public internet seemed like a bad idea. A single password protected access, which seemed to invite hacking.
Instead, I wanted to pass the traffic on the four UDP ports and block everything else. This was accomplished by setting up four custom "gaming" services for each UDP port. I then assigned these services to the RemoteRig Radio IP address. Bingo.
Operation
Operation is pretty straightforward, even though the RemoteRig manual isn't. To activate the system, you simply turn the Control K3 on. Within 20-30 seconds, the devices connect across the Internet, the remote K3 is turned on and the Control K3 goes into TERM mode, and audio starts streaming into the Control unit. All of the knobs, buttons and indicators on the Control K3 operate the remote K3.
When you are finished, you turn the Control K3 off, and the remote K3 also turns off. If you happen to lose your internet connection, the remote K3 turns off in about a minute.
During my experiments, I was able to confirm operation of WSJT-X using the remote shack computer. I've also been able to transmit CW, using the paddle check on the Control unit. So far, though, I haven't figured out how to transmit voice signals. Most likely, I have another cable or configuration problem.
Limitations
The system has a few rough spots. The audio volume is controlled from the Control K3 volume control. Certain operations stop the audio stream -- switching into or out of SUB receiver mode, or into or out of DIVersity reception. Moving the volume control brings the audio stream back.
In my set up, the audio occasionally has small drop-outs, perhaps when a UDP packet fails to arrive in time. For this reason, I would not recommend using RTTY across the audio connection. One can operate a remote computer to run RTTY, just as I do for FT8. There may be a configuration option to help this.
Next Steps
While I can operate my Gwinnett K3 remotely now, I need to automate other parts of the station. I cannot change antennas, rotate rotators or switch the K9AY direction. I'm working on solving those problems.
Update: Sad News
Unfortunately, about two weeks after I started writing this article, my Control unit fails to power up. I apply power, but the PWR LED does not come on. I've tried with two different power supplies, no luck. RemoteRig support indicates this could be a failure of the CPU. Sadly, they don't offer repairs in the USA, and will have no replacement units available until May, 2023.
In the meantime, I'm back to Remote Operation - Level 0.
Cable management trays added to back of desktop selves.
Now that my station desktop is on wheels and has a set of nice shelves, I wondered might be done about the rats nest of wires hanging down from the back of the desk. Some kind of cable management system was needed.
These systems can be expensive. I found a solution on Amazon.com that worked pretty well. It is a kit of eight cable raceway trays about 15" long, 1.5" wide and just under 1" tall. All for just about $20.
These worked well with my desktop shelves. Three cable trays fit neatly on the back of the shelves just under the copper pipe ground bus bar. I mounted them using three short wood screws on each tray.
The tops of the trays either slide or snap off. The fingers on the sides are easily displaced to insert wires of just about any size. In some cases, cables are routed in the trays from one end of the shelves to the other.
From the picture, there are still a lot of wires, but it is neater and more manageable than before. Many of those are antenna coax or power connections. The antenna coax will be moving to the back wall of the basement once the Single-Point Ground (SPG) panel is in place.
I also improved the bonding between units. I'm using 1/2" tinned copper braid, a fork lug and a cable clamp around the 1/2" copper tube grounding bus. This creates a low-impedance connection between the equipment and the station ground. In a few cases, I had to drill a hole and add some #6 screws and nuts to make the connection.
The best part is, I still have five left-over cable management trays to use elsewhere.
Login
