Polishing Up the Rx Antenna Controller

Many software projects are never fully complete, as there's always something to add with a small change to the software. The Rx Antenna Controller isn't any different. 

The initial version of this project was basically done. But pressing the antenna selection buttons resulted in a response on the serial port. This could cause problems with computer control if the response was not anticipated.

I added a new command: &AI; and &AIn;. This gets and sets the Auto-Info mode, respectively. With &AI1;, pressing an antenna button results in an &ARn; response on the serial port. &AI0; turns off Auto-Info mode -- button presses do not result in a serial port response. The default is &AI0;.

I"m very happy with the way this project has turned out. While I have ideas for a Version 2, it mostly involves hardware changes to the remote switching box to allow selection of the AUX antenna for diversity reception.

Rx Antenna Controller

Rx Antenna Controller is QRV.

I started building this unit a couple of months ago. I called it the Beverage Controller, because my motivation was to select amoung the three Beverage antennas I had erected. Yes, I've managed to erect three 500 foot Beverages, one to the NE, SE and NW.

Performance of these antennas is convincing -- 1-2 S-units lower noise than the inverted-L or dipole antennas I use on 160 and 80m, respectively, plus a directional signal boost if the beverage is pointed in the right direction.

I discussed my design issues with this unit in the previous article. Debugging the serial port took another month.

Serial Port Debugging

The reason I had chosen the PIC16F18426 for this design was because of the built-in EUSART. Receiving worked just fine. I could send commands to the controller and it would act on the commands. But it sent no response. 

I had configured the PIC to use RC5 (pin 5) for the EUSART receive input, and RA5 (pin 2) for the EUSART transmit output. After a bit of troubleshooting, I found no action on RA5. It remained at 4.5 V the entire time. Was this a wiring problem, or a programming problem?

I ended up writing another PIC project and setting up a chip on a solder less breadboard to solve this. This project simply sent "Hello World!" at 300 baud every 5 seconds. It also drive two LEDS on the C port pins. The LEDs which alternate during a 1-second startup. When transmitting, the second LED would light up. 

My serial test project worked perfectly. LED 2 flashed for about 1/2 second every five seconds, just as expected. So, why didn't the beverage controller project work?

I modified the beverage controller project to also send "Hello World!" every 5 seconds. Except it didn't work. I traced the wiring in the controller head. RA5 was connected to the MAX232E pin 11. It was the MAX232E that was driving the pin to 4.5 V. With the MAX232E out of the circuit, RA5 stayed at 0 V all the time. It was like the software had configured RA5 as an input, not an output.

I got to the point that I could test both projects on the solder less breadboard. I even programmed the same chip with the serial test project -- and it worked. Programmed the same chip with the beverage controller project -- and it didn't. This was definitely a programming problem.

I tried several modifications of the configuration, eventually applying the serial test project configurations to the beverage controller project. At some point, it started working. I still don't understand what I changed to make it work.

Putting It Together

Remote relay box

After such a struggle, I was happy to finish. I re-programmed the chips to send and receive at 9600 baud. This is plenty fast enough for this purpose.

The controller supports one Kenwood/Elecraft-style command, which takes two forms - a Get and a Set operation:

• Get - &AR; -- responds with &ARn; where n is 1 through 5
• Set - &ARn; where n is 1 through 5 -- selects the antenna specified by n, responds with &ARn;

With the serial port transmit working, I could remotely interrogate the controller to determine which receiving antenna was currently selected. And selecting an antenna would respond to ensure that the controller had received my command.

The controller mounts nicely on the equipment shelf. I used some temporary stick-on labels until I find my computerized label-maker. 

What's Next

The current firmware sends an &ARn; response when a button is tapped. I probably need to make that configurable with a serial command.

I've also thought about adding a scanning feature. The controller could automatically switch antennas after a few seconds. Holding a button could add/remove that antenna from the scan.

However, after a couple of months of using the controller, I've found a glaring deficiency in my design. The Rx Antenna Controller only selects one antenna for the RX ANT port. I use a broadband splitter to also connect to the AUX port for diversity reception. But this only permits diversity reception of one receiving antenna against the transmit antenna. I can't do diversity reception between two receiving antennas. 

What would be nice is to have the remote relay box select the antenna for the RX ANT and AUX port. This would require twice as many relays and a way to control them individually. Doing this requires a re-design of both the remote relay box and the controller box. 

RTTY Contest Operation and Messages

In 1985, I built a home-brew decoder and experimented with RTTY, but I never got it to work. I've since decided that I didn't know how to tune RTTY properly. Things changed in 2005 when I downloaded CocoaModem made my first RTTY contacts. 

Since I was involved in contesting, I naturally turned to RTTY contesting. Today, it is unusual to hear RTTY signals on the bands except during contests. Thirty or more years ago, RTTY was commonly heard on 80 and 20m. 

Characteristics

Several characteristics of RTTY must be understood in order to communicate effectively: 

• RTTY has no error correction or detection -- unlike AMTOR, Packet, FT4 or FT8. This means whatever that prints might be wrong. And if it is wrong, you will not know. 
• RTTY prints garbage. Without a signal, random characters print. This further complicates determining what is correct and what is not. 
• RTTY does not handle multiple signals well. When two or more stations call at the same time, RTTY will not print reliably. Certain decoders may print the strongest signal, if you are lucky.
• RTTY text comes in a continuous stream. Long lines wrap to the next, or one can force a new line by sending a carriage return / line feed combination. Wrapped lines are often difficult to read.
• RTTY has two shift states, LETTERS and FIGURES in the Baudot encoding. RTTY rests in the LETTERS state. An unprinted FIGURES character is transmitted to shift to the FIGURES state. A similar LETTERS unprinted character can be sent to shift back, or one can automatically unshift on a space character. 

Principles

For effective RTTY contest communication, several principles apply. 

• Brevity - every character sent must have a purpose. There should be no wasted characters.
• Duplication - every important element should be sent twice. This contradicts the brevity principle. Because RTTY prints incorrect characters, sending important elements twice helps ensure correct reception.
• Scrolling - each message starts a new line, but ends with a space. This technique keeps lines from wrapping, and avoids the end of message being confused by garbage characters when the signal drops. 
• Shifts - avoid needless shifts. Any sequence involving the unprinted FIGURES or LETTERS characters takes longer to send. 

Messages

(I'm using N1MM messages for my examples. Other software may have different macro names and techniques, but the same principles apply)

Every message starts with a {TX} and ends with {RX}. This transitions the software to transmit and back to receive. 

S & P

Let's say you want to answer someone's CQ. This means you need to send your call. For that, you'd use a macro like this:

{TX}{ENTERLF}{MYCALL} {MYCALL} {RX}

or

{TX}{ENTERLF}* * {RX}

(For N1MM, the asterisk and {MYCALL} macros are the same)

Notice the message starts with {TX}, performs a carriage return / line feed with {ENTERLF}, sends the call twice, ends with a space and then {RX} to go back to receive. Sending the call twice helps to ensure the recipient receives it correctly.

If you are lucky enough to get a response, you'll have to send the exchange. The exchange will vary by contest, but it could be a message like this:

{TX}{ENTERLF}! 599 GA GA DE {MYCALL} {RX}

This is what I send in the RTTY Roundup. First is the recipient's call (!). Then 599 -- don't use 5NN, because that actually takes longer to send in RTTY -- and send it only once, because it isn't important. Then the exchange is sent twice, followed by the prosign DE and my call, followed by a space. 

N1MM's authors recommend you use the ! character rather than the {CALL} macro. The reason is that {CALL} isn't subject to correction -- it sends the contents of the Call field at the start of the message. The ! character will send the Call field as it is being corrected in real time. As a practical matter, most RTTY contest contacts involve pointing and clicking on callsigns, so there's less typing, and therefore fewer corrections involved.

A couple of things here. Notice I did not use the {EXCH} macro above. When there are multiple elements to the exchange, I put the repetitions together. So, I tend put the exchange information into the macro directly. For example, here's an S & P exchange for CQWW RTTY:

{TX}{ENTERLF}! 599 GA GA 5 5 DE {MYCALL} {RX}

GA for Georgia, and 5 for zone 5. For NAQP RTTY, it would be:

{TX}{ENTERLF}! 599 BILL BILL GA GA DE {MYCALL} {RX}

Some might balk at the use of the DE prosign, particularly for exchanges that involve a state or section, since DE might be confused with Delaware. However, I think this prosign is useful, as it establishes the callsign is of the answering station, and not the CQing station.

CQing

Calling CQ in a contest is the most-used message:

{TX}{ENTERLF}CQ RU {MYCALL} {MYCALL} CQ {RX}

Note that the important information -- the callsign -- is repeated. The other curious thing is the "CQ" at the end. This indicates I finished a CQ message. This is important because one cannot tell when potential callers tune in to your signal. If they do so during the first callsign, the can't tell if you are calling or answering a CQ. Putting "CQ" at the end establishes you are calling CQ. And it is shorter than "QRZ?".

Naturally, one indicates the contest in the CQ message. Here it is "RU" for Round Up. Use whatever is appropriate for the contest, or simply "TEST".

When someone answers your call, you send an exchange message:

{TX}{ENTERLF}! 599 GA GA ! {RX}

Note that the exchange is sent twice, and if there were more than one element to the exchange, I'd send those twice as well:

{TX}{ENTERLF}! 599 BILL BILL GA GA ! {RX}

Another item to notice is there is no {MYCALL} macro in this message. Instead, the caller's callsign (!) is sent twice, once at the beginning and once at the end. There are two reasons for this. First, it follows the principle of sending important information twice. It could be the caller's callsign printed incorrectly to me, or perhaps it will print incorrectly when I send the message back. If I only send the callsign once, the caller might or might not correct it if is wrong, or they may correct it if it printed incorrectly to them. 

Unnecessary corrections are a waste of time, but necessary corrections are desired. 

Second, it may be that during the response with the exchange, other stations may also be calling. This, creates a good chance that the initial callsign in the response will print incorrectly. If you don't send the callsign again at the end, it could be unclear who you responded to. 

Once you've received the exchange from the caller, one sends an acknowledgement:

{TX}{ENTERLF}! TU DE {MYCALL} CQ {RX}

Short and simple. Two features here. One is the DE prosign, to indicate this is the transmitting station's call, and ending with "CQ" to invite new callers.

Turnaround

Occasionally, multiple callsigns will print in response to a CQ. You can only respond to one at time.  Since you can only respond to one at a time, this leaves someone waiting. Rather than have them call again, you can use a turnaround message which acknowledges a completed contact and starts a new one:

{TX}{ENTERLF}! TU {LOGTHENGRAB}NOW..{ENTERLF}{F5} 599 GA GA {F5} {RX}

This message omits {MYCALL}, and uses the {LOGTHENGRAB} macro to first log, then grab the callsign off the automatic decode stack, then it follows with the normal exchange. If you use Single Operator Call Stacking, you can use {LOGTHENPOP} instead. See the N1MM manual.

Note that instead of using the exclamation point (!), we use the {F5} macro. Both the exclamation point and the {CALL} macro won't be updated by the {LOGTHENGRAB} macro, but {F5} will.

Short

When signals are strong, and the bands are quiet, perhaps the principle of sending information twice doesn't apply. Most RTTY contests allows contacts on multiple bands, and the exchange doesn't change. In these cases, you may want to have short messages handy. Here are some examples:

{TX}{ENTERLF}! 599 BILL GA DE {MYCALL} {RX} -- short S & P exchange

{TX}{ENTERLF}! 599 BILL GA {RX} -- short exchange for S & P or CQing

{TX}{ENTERLF}599 BILL BILL GA GA {RX} -- repeat of just the exchange 

{TX}{ENTERLF}CQ RU {MYCALL} CQ {RX} -- short CQ

{TX}{ENTERLF}TU DE {MYCALL} CQ {RX} -- short acknowledgement

All these should be used when you have solid copy, want to get back to other callers quickly, or you are fairly certain the other operator already has your exchange information from a previous contact.

Tips

Some tips I've picked up over the last decade that are helpful.

• Use Slow AGC - Fast AGC can confuse decoders and introduce print errors
• Use TX Filtering on AFSK - If you are using MMTTY or similar software, use the 512 tap TX Filter. It helps transmit a cleaner signal.
• Listen with Headphones - sometimes you can hear signals that don't always print, if you listen with headphones, you can hear the stations calling you. It also helps you improve your timing in a pile.

On that last tip, turn the volume on the headphones way down. You just have to sense when signals are there, you aren't decoding them. (I believe it was the late Irv Hoff, W6FFC (SK) -- a RTTY pioneer -- who suffered hearing loss at 2125 and 2295 Hz from listening to RTTY signals)

Practical Messages 

There are a handful of other messages you may wish to have handy. Here's one I use often, when you didn't copy anything sent:

{TX}{ENTERLF}AGN AGN {RX}

Or perhaps you need a fill of one element:

{TX}{ENTERLF}STATE? STATE? {RX}

{TX}{ENTERLF}NR? NR? {RX}

{TX}{ENTERLF}NAME? NAME? {RX} 

 Before you open up with a CQ on a frequency,  this is good one:

{TX}{ENTERLF}QRL? DE {MYCALL} {RX}

 Maybe if you are not sure someone is calling you:

{TX}{ENTERLF}QRZ DE {MYCALL} {MYCALL} {RX}

Or the short version:

{TX}{ENTERLF}QRZ DE {MYCALL} {RX}

Every once and a while, directed call is useful, especially when two stations are calling CQ on top of each other:

{TX}{ENTERLF}! DE {MYCALL} {MYCALL} {RX} 

Conclusion

RTTY contests are a ton of fun. Program a set of messages and try it. You'll like it.

RealVNC Changes Terms, without Notice.

Just over three years ago, I figured out how to Remotely operate FT8 using a product called RealVNC. 

RealVNC had a Home plan that allowed up to 3 users and up to 5 devices for non-commercial use. Perfect for remotely controlled computers in a ham radio shack.

Today, without any notice, RealVNC disabled my Home plan, and I had to choose between paying each month for a plan, or adopting their Lite plan, which allows 1 user and up to 3 devices for non-commercial use.

That's fine. They allow me to use their secure remote access software without fees. I can understand they might want to change the terms.

The Lite plan fits my usage. I've only ever had two devices active anyway, and it's just me as the user. 

But, without notice - that is just damned inconvenient. Since I switched plans, I need to visit each device and re-configure them to be part of the new plan. Which means I can't remote into those computers until that is completed. 

And, of course, since I'm remote, I'm not there.

Quite inconvenient.

FT8 is supposed to make DXing easy, why is it so hard?

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.

Halfway through the DXCC Challenge

Twenty years ago, when I first started uploading my logs to Logbook of the World, I began to pursue the DXCC Challenge award. I created lists of confirmations that I had, and began to try to fill in the band / countries I was missing. This has continued for years. 

In April of 2016, I gathered sufficient confirmations to earn the DXCC Challenge award. Since then, I've continued to pursue new band / countries practically every time I am on the air.

This month, I passed another milestone. Currently, there are 340 entities on the DXCC list. And the DXCC Challenge counts on ten bands, from 160m through 6m. That makes 3400 total items for DXCC Challenge. 

I recently collected confirmations over 1700 items on the DXCC Challenge. That's the half-way point. It's only going to get harder after this.

Nine-Band Worked All States

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....

Remote Operation - Level 1 (RemoteRig RRC-1258MkII)

RemoteRig RRC-1258MkII at Radio

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.

The Desktop Shelves

Updated shelves as of January 2022. The AL-80A
Amplifier is just off to the right side, on the desk.

Setting up my shack in my first home, in 1986, I needed to stack equipment. My operating position was a finished door on top of two filing cabinets, something that I used in my previous apartment. While the table was big enough, shelves were needed to easily access all my equipment. 

I came up with a design using 1x12 lumber. There are three shelves, one 1", 12" and 22" above the tabletop. I chose these heights because it allowed me to slip my paper log books and other operating aids under the bottom shelf -- under the bottom row of gear. 

I bought a stack of 1x12 boards, borrowed a friend's table saw and cut the pieces to length. I laid them on edge on the cement floor of my garage, glued the edges and pieced them together with wire brads. Everything lined up OK -- the result was pretty square.

35+ year old shelving unit, before
it was removed from desk

The shelves were 48" wide ( 8 foot boards cut in half ), and had two uprights under each shelf. These shelves worked for several decades.

Over time, I noted problems. The upright supports limited the equipment I could put side by side, because only so much would fit. And the lowest shelf was problematic -- it meant my computer was in front of the shelf -- which meant my arms hung off the desk, with my forearms resting against the edge of the desk. This caused a lot of fatigue when contesting. Plus, I had stopped using paper logs back in 2006, so there was no reason for the lower shelf.

Micro-shack, before I moved.

I liked the layout I had back in the micro-shack. The desk surface was small (just a couple of inches wider than 5 feet), and the primary equipment sat on the desk itself, with other gear on a shelf. This meant I could re-position my gear at will. Best of all, the computer could be front and center, with my forearms resting comfortably on the desk itself. 

After 35 years, the requirements came together. I needed a shelf unit with two shelves. The first shelf would be 12" above the desk, and the second shelf 22" above the desk. This left more than enough room to slide a 15-17" laptop under the bottom shelf. The shelves could be a little wider, to accommodate more equipment. Because my copper pipe grounding bar was a little more than 53" long, I opted to make the unit 52" wide. 

I liked having the AL-80A amplifier on the right side of the desk, canted slightly to make the controls accessible, and allow for good cooling airflow. With a 52" wide self unit, this meant about 8" of unused desk space on the left-hand side. That was fine. That part of the desk is right next to a wall, and I don't put equipment that deep -- usually that's where my headphones and operating aides end up.

The bottom and top shelves would be separated by two uprights, with openings of roughly 17" on the left and right, and 15" in the middle. Under the bottom shelf, there would be no uprights. Instead, to keep the shelves from bowing, I used a piece of 1x4 as a sheer web at the back of the unit. 

Here are the component dimensions used:

•   top (1x12) - 52” 
•   shelf (1x12)  - 50 1/2” 
•   ends (1x12) - 21 3/4” (2) 
•   separator (1x12) - 10” (2) 
•   shear web (1x4)  50 1/2” 

I bought the requisite 1x12 and 1x4 lumber, but didn't cut or assemble until later. This was unfortunate, because the lumber cupped a little bit as it dried out in my basement. This made the pieces a little harder to fit together. I used the same construction technique I used before -- glue and wire brads. 

And even though I put the pieces together on my very flat workbench, a little bit of twist was introduced in the bottom shelf. It doesn't quite line up in the front like it should -- something I'll be looking at for the next 30+ years. I considered busting it apart and starting over, but I decided it would do as is. 

Assembled unit with
grounding bar installed

I intended to stain it and seal with polyurethane. However, I found that my stain had turned into a solid mass of jelly and was unusable. Instead, I applied three coats of polyurethane. The resulting finish is quite handsome.

The shelf unit is relatively light and quite sturdy. I'm sure it would support my weight, but I didn't try. The copper pipe grounding bar fastens to the 1x4. I use small hose clamps to attach wires to the grounding bar. This ensures that all gear is properly bonded to ground.

I'm very satisfied with the end result - plenty of room for gear on the desktop, with other gear on shelves at a handy height. The bits and pieces of equipment are slowly coming back to the operating desk, and I'm being careful in deciding what goes where -- it can get awfully cluttered. 

I do love having a lot of space for computer gear on the desktop. I've had as many as three different laptops all running at the same time on the desk.

Now I've got to finalize where everything goes. I've already decided I need to move the P3, and the KK1L antenna switch matrix is going to end up on the basement wall on the Single-Point Ground panel.

Remote Operation - Level 0 (RealVNC)

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. 

4U1UN (and 4U75UN)

A little more than a year ago, I was looking at the Most Wanted list in ClubLog. I noticed that the United Nations HQ entity was number 30 on the list. In all my years of ham radio, I had never heard them on the air, much less worked them. I wondered if I'd ever have the opportunity to work them at all.

Well, the 4U1UN club has been busy, and late fall 2019, they finished their installation which allows them to remotely operate a transceiver near the top of the UN towers from a room on the ground floor of the building. Since that time, they have been sporadically active. 

I don't know what the rules are for operating 4U1UN, but the station has been active at least some time every month during the past year. They have gone from an entity you'd wonder if you'd ever work, to one that can easily be worked by anyone with a bit of determination.

Over the past year, I've kept a running DX Watch query going to see when they were on the air, and worked them any time I could hear them. They've been easy to work even with compromise antennas.

They confused me in September, as I thought they had gone silent. No, they just switched callsigns. They are celebrating 75 years of the UN with the call 4U75UN. There's a special certificate for working them. They should continue with that call until December 31st.

They'd be pretty easy from the USA on 160m, but I don't believe anyone has ever operated on that band. I doubt they have an antenna, and I head the noise level in NYC is extraordinarily high.

They QSL promptly through LoTW (be patient, it may take a week or two to be uploaded). I've gone from wondering if I'd ever work them to having them confirmed on nine bands (80m-6m) and three modes: CW, Phone and Digital. 

Keep an eye peeled on the spotting networks, and perhaps you can work a new one.

Improving the Shack Desk

Finished, standing against wall.

Thirty-five years ago, I asked my father-in-law to be for advice on lumber for an operating desk. He suggested I find a solid core door. I bought an 80x30" door and have used as my operating desk since. It has held up very well, surviving two moves, and three re-finishings. 

Originally, I bought the door and two small two-drawer filing cabinets. With the cabinets on either side of the door, the result was a very stable platform, strong enough for me to stand on. 

However, it wasn't the most perfect arrangement, as I wrote four years ago. Adding a 1/4" radius edge to the front, was a  dramatic improvement, mainly because the operating surface was just too tall. 

This year during Contest University,  Doug Grant K1DG gave a talk on Optimizing Your Station For Contest Operations. One of the salient points in his talk was that the operating desk needed to be at the right height for the operator. 

The door across the filing cabinets was 30 7/8" off the floor. Doug's talk indicates that the optimum for my height should be closer to 28 1/2". The micro-shack desk was about 30", and the luncheon table that serves as my workbench on the other side of the shack is 29" off the floor. What I needed were shorter supports. 

Box frame.

It is not possible to make the filing cabinets shorter, so I needed something else. It had to be strong -- the door itself is heavy, and the linear amplifier and other bits of equipment add up. I also needed to be able to get it through the door to my 6x15 foot room that is the shack. 

What I came up with is a set of box frames aligned by some cross members. The box frame is a "U" shape made out of 2x4s, capped with a 30" 1x4. A couple of 1x4s act as a shear web to keep the box frame square. It's held together with glue and screws. Three 58" 1x4s serve as the cross members. The cross members are each in a different plane, and give plenty of room for a chair to roll underneath.

Finished stand.

It's sufficiently strong that I can easily sit or stand on it.

And, here's the best part. It's on six castors, so I can move it away from the wall to get behind the desk to wire things. No more having to do my rig wiring blind!

I was worried that the tile floor might make it hard to roll the desk, but it's actually pretty easy. 

This design is pretty simple, and it came together quickly. The 30" 1x4s on top have a single wood screw on each end into the door, so the surface can't slide around. And the cross members are held on only with screws, so they can be removed when in order to get the whole assembly out of the shack.

Voila! Away from wall.

The door already has a couple of power strips mounted on the underside, which makes plugging in equipment that much easier. 

Based on what I was thinking four years ago, the next improvement will be the equipment hutch that goes on the desk. That's also a relic from 30+ years ago. I've already purchased the lumber for that project....

SoundBlaster X G1

I'm always on the lookout for good USB sound cards. I've found a few. Some were expensive, like the M-Audio Transit. Others were cheaper, like the Startech ICUSBAUDIOMH. Both of these are 96 kHz, 24-bit, stereo input and output sound cards.

And neither of them work any more. You see, these devices, although the hardware is perfectly capable, are no longer supported with current drivers. As such, they no longer function with the latest operating systems. It's a very disappointing situation.

So, I continue my search to find good sound cards. I look for 48 or 96 kHz, 24-bit devices, preferably with stereo input. Sadly, this last function is hard to find.

The SoundBlaster X G1 seemed promising. It was advertised as 96 kHz, 24-bit, stereo device. It was only about $30, so it fit my criteria as inexpensive. I received one at Christmas time and checked it out.

The SoundBlaster X G1 comes with a TRRS mini phone jack, which should have been a clue that it didn't have stereo input. It comes with an adapter that exposes the connections as a separate headphone and microphone jack. The microphone input is connected to the ring terminal, the tip having no connection. This is apparently pretty standard for PC microphones.

When I first tested the device, I was disappointed that it only had 44.1 kHz, 16-bit input and output. At least, that's the only function it would perform out of the box. While the input appeared on the computer as stereo, both channels are hooked to the single input channel -- giving you two copies of the same input signal.

Turns out, the SoundBlaster people have created a device that has multiple "profiles" and can appear as a device with different capabilities. The default profile is intended to be compatible with the Sony Playstation, and has minimal capabilities. Using a special Windows program, I reconfigured the profile to the Generic profile.

On the Generic profile, the device conforms more closely to it's specifications. 96 kHz operation is restricted to output-only. Input maxes out at 48 kHz. But both input and output are 24-bit.

Once configured, the SoundBlaster X G1 makes a decent sound card, although it is restricted to a single input signal.

SoundBlaster also makes the SoundBlaster Play!, which appears to have similar capabilities 96/48 kHz, 24-bit, stereo out, mono in. The Play! is about 20% cheaper, but both are inexpensive.

Ingenious Fan Holder for K2/100

Binder clip. I should have thought of this earlier!

The K2/100 is a nice little radio, but when running RTTY or other full-duty cycle modes, it lacks sufficient cooling. I couldn't run more than about 30-35 watts without the KPA100 amplifier heat sink becoming alarmingly hot.

I solved this problem a years ago with a small muffin fan on top of the heat sink. The fan is mounted on tiny rubber feet. It blows air upward, resulting in airflow across the fins. Placed just above the finals, it does a good job of keeping everything cool.

This fan is noisy at full speed, so I used a small resistor in series. The resulting half speed airflow is more than sufficient.

This worked great at my Gwinnett QTH for years, where the radio was raised above the desk a couple of inches by a shelf. The K2/100 sat almost flat, and the fan stayed in place. However, when I moved the K2/100 to the parsonage QTH, the radio rested on the desk, and I used the KAT100 tilt bail. Because of the tilt, the fan had a tendency to drift to the back. Every once in a while, it would fall off.

While I was readying the K2/100 for the 2020 ARRL RTTY Roundup, I wanted to make sure the fan stayed put. I came up with a very inexpensive solution. A small binder clip attaches easily to the heat sink fins. The ears of the clip rest against the fan body and prevent it from drifting.

Worked about eight hours over two days in the RTTY Roundup, and the fan never budged. I really wish I had thought of it sooner!

VP6D on 30m CW

Odd things happen. During a long DXpedition, like the current VP6D expedition to Ducie Island, they are bound to happen. They happened during the K1N Navassa Island expedition, for example.

Last night I'm trying very hard to put VP6D in as many DXCC slots as I can. I hadn't worked them on 30m, and they were running RTTY. 30m is often tough, since everyone runs 200 watts, tops, and my 100 watt signal doesn't really stand out. RTTY makes it even harder. I called for a half an hour with no luck. And then VP6D disappears.

I continue calling for a little bit. It's a sort of anxious hope that sometimes works. Maybe they had a generator die, and the first thing the operator will hear when the generator comes back to life will be my callsign. Right? Well, it could happen.

After a couple of minutes I stop calling. I'm sitting there with the headphones on. The left ear is listening to 10142 kHz at about 450 Hz wide, the right is listening up around 10144.5 kHz, about 2 kHz wide. And, I'm hearing nothing. Nothing at all.

About three minutes after I stopped calling, I heard a signal. It sounds like a CQ. A CW CQ. It's off frequency, so I can't really tell. I'm not set up for CW. I'm in DATA mode, with settings all flipped around with wide filters. But - there it is again - in my right ear, it sounds like VP6D calling CQ, in CW.

Switch things around to CW, with a narrow filter, and then tune for the right frequency. I'm sure I'm going to miss it, but no, I find him. There he is CQ VP6D UP2. Plain as day on 10144 kHz. That's not where you'd expect him to be at all. No, the published CW frequency is 10105 kHz. This frequency is out of position for CW, but there he is, calling CQ VP6D UP2. And no one is answering. No one.

This is my chance. I go into split, up 2, and give him a call. But, again, CQ VP6D UP2. A couple of times. No answer. So, I figure, hey, maybe he's actually listening up 1 and doesn't realize his memory keyer doesn't match. I dial in up 1, and call. No dice. After a few calls, I wonder where he's listening really. Maybe he's listening up 2 from 10105 kHz. I give him a call on 10107 kHz. Nothing. Perhaps he's listening on his own frequency?

At this point, he's been calling CQ on 10144 kHz for two solid minutes and no one has answered him. I figure it's worth a try without being a DX lid. I turn off split and dump in my call: AA4LR. AA4LR 5NN comes the response. R 5NN TU, I reply.

And bam, quick as that, he's in the log.

He goes back to calling CQ VP6D UP2. I listen for a couple more minutes, but no one is calling him. I post a spot on dxwatch.com and listen for a couple more minutes. Still no one. I begin to wonder if he's just clueless to where he is in the band, and that no one is looking for him there. So, I dare to send again on his frequency: FREQ? He responds to my question by sending 10144 twice. So, yeah, he knows where he is. I post another spot, hoping some other DXer will find him, too.

After about 10 minutes of this, he goes silent. A minute after, I find him down on 10105 kHz, once again calling CQ VP6D UP 2. And, people are calling him, and he's answering. Good, that's what's supposed to happen.

Looks like I'll may be the only one who worked VP6D on 10144 kHz CW. Cool.

What's Next for DXCC?

At the end of summer every year, I start thinking about DXCC. For several years, it was getting more confirmations for 80m DXCC, so I could complete 5BDXCC. Last year, I accomplished that, including the 30m endorsement.

At the time of this writing, I have 109 confirmations for 17m. That band will be next - I'll submit that this year. This will also push me over the 1000 confirmations threshold for DXCC Challenge - I'll do that one at the same time.

The downside of earning DXCC awards on each band is there are fewer bands left.  On 12m, I need just 17 more confirmation. Given the low level of sunspot activity, that might take some doing. However, I did manage to add 10 confirmations since last year, so it is possible.

160m would be the next one. With 46/45 confirmations, it's further off. I'm not even half way to the necessary 100. I will definitely put some work into 160m this winter. But, honestly, DXCC on 160m may take a few years.

Speaking of years, on 6m I have a whopping seven confirmations. In the spring, I figured out how to use FT8 on this band, and while I heard a ton of DX, I only managed to work a handful. Definitely looking forward to the winter sporadic-E season. I think the most excitement I'll get for a while is finishing off 10-band confirmations. I have USA, Canada, Mexico, and Suriname on all 10 bands -- but there's several countries where I just need a 6m contact.

I've inched closer to Honor Roll, with 279/276 confirmed Mixed. have worked about nine of the remaining 64, but I need confirmations. Perhaps it is time to learn more about QSLing effectively.

And, if nothing else, it's fun building endorsements for the bands I already have. That's the fun of DXing -- it's long-term fun.

OK, I'm an Idiot....

Sometimes, it helps to just admit it to yourself. Let me explain.

Back in December 1st 2017, I started using FT8. I set up the WSJT-X Mac software and made my first contact. Mostly operating on 17m, 30m, 12m. I later discovered 6m. Indeed, this last summer was a huge opportunity to work much of the country on sporadic-E (Es) on 6m. I was amazed to work 40 states in just one summer. On all bands, I've worked all fifty states, and quite a few countries with this mode.

So, I've been using FT8 for months. However, one thing bothered me - everything seemed off frequency. You see, there are standard frequencies that are published for FT8, 12m is 24.915 MHz. But if I dialed in 24.915 MHz, everyone was too high -- like no one was using frequencies less than 2 kHz, and some were visible at 3.5 kHz and higher.

My solution to the problem was simple -- I just tuned higher. I decided that 24.916 was more accurate, and operated that way for months. I even reprogrammed WSJT-X so the 1 kHz higher frequencies were the right ones.

But, it bothered me. It seemed wrong.

I managed to work Baker Island using FT8, but it was a bit of trouble, and I had one fellow email me saying I was calling too low for the fox/hound DXpedition mode. I used a higher frequency and almost immediately had an exchange. This made me think about this issue more.

Originally, I had my K3 set up for RTTY using AFSK. This means I was using the AFSK A data mode on each band. For FT8, I would select DATA REV, so it would use USB instead of LSB.

What I didn't realize is that AFSK A means the display frequency is adjusted to reflect the Mark frequency of (in my case) 1445 Hz. This accounts for my frequency being too low -- I was off by 1.4 kHz.

With that figured out, I switched to DATA A, which has the display frequency of the suppressed carrier, as it would for LSB or USB. The frequency jumped, and I tuned again to the standard frequencies (the real ones, not my artificial higher ones).

But, it didn't work. I couldn't hear any signals. Back to AFSK A, and they are there, but switch to DATA A, and they are gone. What?

Turns out, AFSK uses LSB by default, while DATA A uses USB. Since I was using DATA REV, this means DATA A was LSB. Oops. Back to straight DATA mode, using the DATA A sub-mode, and everything works just as it should. Gosh, that's too easy.

I'm an idiot....

I'll just have to remember to change the DATA MD back to AFSK when I'm doing RTTY.

The Venerable Elecraft K2/100

Elecraft K2/100 with KAT100 tuner, as it sits on the desk.

I cannot believe it has been fifteen years since I built the Elecraft K2/100!

When I first got interested in amateur radio, in the mid-70s, I wanted to build my own rig. While I studied for my novice, an elmer of mine insisted that each ham should build his own transmitter. He gave me some parts, and I made an honest attempt, but the "Novice" Transmitter didn't actually work until many years later.

Later, while preparing for college, I tried building a QRP transceiver I might use in the dorm. I built a 7 MHz FET VFO, a direct-conversion receiver, a 3 watt transmitter, and a even a KOX or Key-Operated Switch to do semi-break-in with side-tone and an relative power and S-meter.

This design never did work. Never heard a peep out of the receiver. While the transmitter produced a couple of watts output, it couldn't decide if those watts were on 7 MHz or 14 MHz. The key mistake I made in my youth was building the entire project before testing anything. The VFO worked, the KOX worked, but that was about it.

I had tried to build my own designs, without a lot of success.

I noted the Elecraft K2 introduction in 1999 with interest, but I wasn't excited. While relatively inexpensive, it only produced 10 watts output. I needed a replacement for the venerable Kenwood TS-430S, and that meant 100 watts output. When Elecraft announced a 100 watt PA for the K2 later in the year, I was hooked. Best of all, I could buy the rig in installments, adding options over time.

I joined the Elecraft mailing list, and read everything I could about this great little rig. Sold! On March 1, 2002, I placed an order for a plain Elecraft K2/10 and would receive Serial Number 2548.

On arrival, I spent and hour or two each night building. This wasn't something you could knock together in a couple of evenings. I wanted to do a good job as well, to savor the process, instead of just slap it together. In total, the basic K2 took me nearly 30 hours to build.

Wayne Burdick (one of the Elecraft founders) at some point asked me for any building notes or comments on the K2. This gives you an idea of how grassroots a company like Elecraft is. I sent him a series of four notes with my impressions and some detailed comments. I don't know if he actually used this material to improve the K2 assembly manual, but it's a nice thought.

The K2 is no Heathkit. A real Heathkit would have more drawings and diagrams at each stage of assembly. But, hey, Heathkit is out of business and Elecraft is not.

Any K2 builder can spin yarns about the joys of winding toroids. There are dozens of them in the K2. Frankly, I didn't have that much trouble winding toroids. Tinning the toroid leads, on the other hand, was a real pain. Especially when I didn't tin them up quite far enough and had to do it over.

After 20 hours of construction, I did the Alignment and Test II section and was listening to 40m signals coming through the receiver. Given my previous experience, this was very exciting. You have such a feeling of accomplishment when something you built actually operates.

For the most part, the K2 worked flawlessly after construction. I did have a problem with flaky AGC action, which was fixed with a resistor substitution and a replaced transistor. I also had an intermittent INFO 080 (the dreaded AUXBUS failure) which was caused by a bit of waxy burnt flux between two pins on the control board. The Elecraft mailing list and support email address gave me the information I needed to diagnose these problems.

With the basic K2 built, I started ordering and building options. The KSB2, the SSB module, was up first. The KSB2 has the densest board of all the K2 kits, making it the hardest to assemble. And the FT23-43 cores were so tiny, I originally thought they were fiber washers.

After the KSB2 came the KAF2. I had read enough to know that the K2 audio had an unpleasant hiss that was knocked out by the KAF2 audio filter. Beyond that, however I never found the audio filter to be that useful. While the KAF2 also has a real-time clock, I never found much use for it.

Next was the KNB2, the noise blanker. Having used the one on my Kenwood TS-430S, I felt that a noise blanker would be a required option. But the KNB2 isn't terribly effective at eliminating the noise sources I most often encountered. I was able to determine it was working, and later managed to make modifications to improve it's effectiveness.

The last option for the basic K2 I built was the K160RX -- which has to be the simplest option board I've built. Once installed, I had a very functional K2, with 160-10m coverage, CW, SSB, Noise Blanker, Audio filter. All I needed was to wait for the KPA100 option.

And, indeed, as soon as it was available to order, I placed my order the same day. And then I waited.

Fate intervened, however. While I was waiting for the KPA100 to ship, I was laid off from my job. This was the summer of 2002. The internet bubble had burst, and there were several shocks to the economy, what with the 9/11 tragedy, and the Enron and Adelphia Cable financial scandals.

Without employment, spending hundreds on the KPA100 didn't seem wise and I cancelled my order. I feared I might need to sell my K2. It took me nearly four months to find a new job, as the market was really tight. But as soon as I had a new position in hand, I re-placed my KPA100 order.

I had some trepidations about the KPA100, but it went together pretty easily, and it worked like a charm right from the start.

At this point, the K2/100 became my main rig. With computer control -- something that I had coveted for years -- contest band changes became much easier. I loved it.

Close up of the friendly face of the K2. 

Once built, for a few years I was regularly tearing into it to make modifications. The improved 2nd XFIL mod, the KI6WX improved CW filter rejection mods, alternative AF gain control. The massive A-to-B upgrade. The BFO temperature stability mod. Redoing all of the crystals with the K2KSB2XTALS mod. The KSB2 firmware update to v1.08. The PLL temperature compensation mod. The KPA100 Rev B upgrade with upgraded shield. K2 firmware update to v2.04. K2 Keying modification. The QSK improvement modification. KPA100 current consumption mod. The power control mod.

During these first few years, I also added the KAT100, the KDSP2 and my favorite, the Finger Dimple. The KAT100 really made the rig more versatile. The KDSP2 helped out on SSB with some needed bandwidth filtering, and the auto-notch filter. But the Finger Dimple made tuning the rig a much more comfortable proposition.

From Mid-2005 until 2010, K2/100 served as my main rig without any modifications. 2010 brought a flurry of final mods. The VCO Shielding mod. The KPA100 Rev D upgrade. The KNB2 response and threshold sensitivity mods.

Once I finished all this, I bought the Rework Eliminators kit -- that enables one to swap out option modules without making changes. I don't believe I've used them.

Although the K3/100 replaced the K2/100 as my main rig, I still use the K2 regularly. It is pleasant to listen to and quite capable. The K2 has earned an honorable place on my operating desk, and deserves to be called a venerable rig.

Life after 5BDXCC

For the last several years, I've started off the late summer thinking about my plans to complete 5BDXCC. This has meant figuring how who to make more DX contacts on 80m, whether that meant improving antennas or just being on the air more.

But, this June, I managed to wrangle enough confirmations to qualify. I'll likely submit these in November.

As that time of the season rolls around again, I have to think - what's next? What comes after 5BDXCC? It's a good question.

I still have a few other bands to add. On 17m, I have 87/87 confirmations, so that's likely next. It will be easier now that I've identified the problem with my WARC dipole. ON 12m, I have 73/73 confirmations is not that far behind, although old Sol is not likely to be active enough to sustain much propagation on that band for a few years.

160m seems less likely, where I have 42/41 confirmations. Given how hard 80m was, it may take quite a while to add many more entities there.

The DXCC challenge is still unclaimed. I have 835 current credits, and my unapplied LoTW confirmations will bring me up to 1125, if I applied them all. Plus at least five more QSLs I'll submit this year could get me all the way to 1130. I've decided a couple of years ago not to push for this too early. The 80m DXCC submission this year, plus all the band endorsements should get me over 950 credits. I'll make it over the 1000 credit requirement as soon as I complete another band.

And, of course, there's the DXCC Honor Roll. At the moment, I have 259 current confirmations, which puts be 80 away from the 339 total. And 71 away from the 330 required to make Honor Roll.  That may take quiet a while. I have two cards that I'll submit this year, and there's a dozen more entities I've worked that I need to obtain confirmations from.

Naturally, some of these remaining entities are increasingly rare. The good news is there are several exciting DXpeditions this year. I'll have to make plans to work them when I can.

So, yeah, still a lot of challenges left in DXCC.

5BDXCC - YES!

For the last four low-band seasons, I've been hoping I'd capture enough confirmations for 5BDXCC. I had already confirmed 40, 20, 15 and 10m DXCC, I just needed to get to the magic 100 entities on 80m. As I wrote in the fall, I just needed a few more to put me over the top.

At that time, I had 91/90 confirmed on LoTW, plus a couple of cards.

Today, I received a confirmation on 80m from CE2VMF, bringing my totals to 98/97 on LoTW. Plus, I have THREE cards with additional confirmations, which brings the overall total to 101/100.

I remember talking to Jim Streible K4DLI (who now, unfortunately, is a silent key) about his 5BDXCC plaque. Jim said he had spent 35 years earning that award. And Jim earned it back in the day before electronic confirmations, too.

So, when I apply for DXCC awards later this year, I'll be petitioning for 6BDXCC (got 30m, too!).

I'll have to seriously consider ordering the plaque.