My Journey to QRQ: From Zero to 35+ WPM

It is no secret: I am a CW aficionado.

I was originally a ham back in the 1900s, but I never operated on HF during that time. Living in a tiny apartment, I had no practical way to put up an HF antenna. VHF provided all the distraction I needed.

The Unexpected 13 WPM General Pass

That was the era when the FCC introduced the Technician Plus category. After I passed my Tech exam, a friend told me he had just passed his Tech Plus by copying Morse code at 5 WPM. Although I had no immediate intention of getting on HF, I didn't want to be outdone by my buddy.

I started learning Morse code just to upgrade. My friend handed me a bunch of cassette tapes, and I practiced diligently for the test. If I recall correctly, the code test simply involved listening to a simulated QSO and answering a few questions about the content—like identifying the sender's call sign. I passed with flying colors.

The VE administering the test looked at me and said, "Well, now that you're here, why not try the 13 WPM General test?" After making absolutely sure there were no negative consequences for failing, I gave it a shot. To this day, I have no idea how I managed it, but I eked out a passing grade. The only downside was that I now had a 365-day window to pass the written portion of the General exam to capitalize on it. I never did. So there I sat: a Technician Plus who had never sent a single letter of Morse code over the air!

Eventually, life became busy. I was increasingly drawn away from the radio, dropped the hobby completely, and let my license lapse.

The Pandemic Plunge and an Unpleasant Surprise

When the COVID-19 pandemic hit, I decided to take the plunge back into ham radio. I took my exams via a Zoom call, which was a pretty intense experience. The VEs had me pan my camera across the entire room to ensure no one else was present, and they even made me open my closet to ensure no one was hiding inside! I passed the General exam successfully and picked up my first modern HF rig, a used Icom IC-7100.

As I tuned around the HF bands for the first time, I finally heard live CW. Hmm. The dits and dahs made absolutely no sense to me. I was shocked to find that my CW recognition skills had completely degraded to nothing over those two decades. As it turns out, CW is nothing like the old cliché about learning to ride a bike—you absolutely can forget it if you don't use it!

Getting Back on the Wagon

I decided to get back on the CW wagon, purely as a personal challenge. Things were much different in 2022. There was a wealth of digital resources available to learn code. I used them all: smartphone apps, websites like LCWO.net, and even MP3s of literary classics like Moby Dick rendered entirely in Morse code.

While those tools helped immensely with copying, I still needed to practice my sending. It took me quite a while to regain my confidence. I practiced sending for hours by turning my rig's break-in (BKIN) function OFF and listening strictly to the side-tones. Thanks to modern rigs, there was no need for an external practice oscillator.

Finally, I decided I was ready.

I will never forget the sheer nervousness I felt when an operator responded to my very first CW CQ. I was so anxious that the details remain a blur; I was just glad when we finally exchanged 73s. The rest, as they say, is history. Today, I am a dedicated ragchewer who is perfectly comfortable copying and sending CW at speeds near 30 WPM.

Joining the QRQ Crew

It would not be an exaggeration to say that I am completely hooked on CW. I love conversational ragchewing and constantly strive to improve my operating proficiency. While groups like CWops are fantastic for bringing code enthusiasts together, many major organizations today tend to lean heavily toward contesting. Because I am not particularly into the contesting scene right now, I wanted to find a space focused purely on the art of high-speed conversation.

That pursuit naturally drew me toward QRQ crew, a group dedicated to promoting conversational CW at 35 WPM and above. It has been an incredible experience so far. I am thoroughly enjoying the challenge, the rapid-fire pacing, and the unique operating opportunities provided by the crew members.

If you are curious about high-speed operations and can sustain even a brief burst of conversational CW at 35 WPM, you should absolutely look into joining the crew.

The À-La-Carte Buffet of Amateur Radio: There’s Room for Everyone

 The "Isms" Dividing Ham Radio: Are We Our Own Worst Enemy?

Amateur radio is a deeply personal hobby. There are so many facets to being a ham. You can choose to tinker and build your own homebrew rigs, work QRP, chase DX, work satellites, brag about contest victories, or try your hand at SOTA and POTA.

There is, of course, one major factor that cross-cuts all these aspects: the mode. You can choose to do voice using SSB or AM on the HF bands, or FM on the VHF/UHF bands; you can pound brass on CW; or you can try wide-ranging digital modes, from the veteran RTTY to the more recent FT8 and FT4.

Nothing about these opportunities is mutually exclusive, and many amateur radio operators explore most of these options at some point in their journey. This à-la-carte buffet ensures there is no boredom, as there is always something different to try.

The Pitfalls of "In-Group" Thinking

It does pain me when I see online forums and even the airwaves filled with "in-group" and "out-group" thinking. There are purists who look down upon anyone who does not use a personally built rig, labeling them as mere "operators." I would prefer if they took pride in their own achievements rather than using them as a cudgel to put down other hams.

Then there are the "code" vs. "no-code" wars that never cease to elicit strong reactions from all sides. The removal of the CW code requirement for operator licenses seems to irk some of those who went through those rites of passage in the past. To them, it feels like a lowering of standards.

The code requirement was historically seen as a bulwark against the "CB riff-raff"—a way to keep them away from the pristine portions of the amateur bands. As an amateur radio operator who learned CW and finds great enjoyment in it, I understand the effort it takes to get proficient. I always have great respect for other amateurs who opt to do the same. I derive great pleasure from operating CW and wish more amateurs would give it a try. However, this pleasure is in no way diminished by others who enjoy being on the air in their own personal way, nor do I believe they are lesser hams.

The Polarizing World of FT8 and FT4

I dare not bring up FT8 or FT4 in any group of amateurs. Nothing divides the camps more than these weak-signal data modes. Even among those who love the mode, there is a rift between those who believe using high power is acceptable and those who do not. Then there is the fundamental debate about whether using computers makes it a true amateur radio pursuit.

I will grant you that these modes do not appeal to me personally, but I can certainly see the joy they bring to many amateurs with compromised antennas or the inability to run high-powered stations. From my interactions on local repeaters, I know of a senior amateur who gave up his favorite home and moved into a living arrangement with strict antenna restrictions. He is over 90 years old and regularly chimes in with excitement after making contacts through FT8.

A few other hams I know use a magnetic loop antenna inside their condos or have a hamstick out on the balcony just to enjoy being on the air. FT8 makes it possible for them. Objecting to it entirely discounts the technical intricacies that make FT8 possible in the first place.

Contesters: Spectrum Annoyance or Spectrum Protectors?

And finally, let's talk about contesters. Every time a major contest ends, the airwaves are filled with vitriol about how contesting is taking over the bands. This animus applies to POTA activities as well. Most critical opinions discount perfunctory exchanges with a standard signal report as going against the grain of amateur radio. Many comments also cite the "entitlement" of contesters.

I have been on the receiving end of this, where contesters muscle onto an active frequency. One moment all is fine and you're enjoying a QSO; the next moment, the contest starts and the airwaves explode with contesters calling CQ. Yes, busy contesting weekends can make the airwaves difficult to access for regular hams, which is especially pronounced on the voice portions of the band.

But I contrast this with the signal desert that symbolizes the airwaves during normal times. In this regard, contesters bring much-needed activity to the air. I believe that when the time comes to revisit amateur radio band allocations, the high utilization during contest periods will provide strong evidence to keep our current spectrum from diminishing.

Ultimately, amateur radio thrives because of its diversity, not in spite of it. Whether you are pounding brass on CW, chasing weak signals on FT8, or racking up contacts in a weekend contest, every operator plays a vital role in keeping our airwaves alive. Instead of building walls between our chosen modes, we should celebrate the fact that our spectrum has room enough for every kind of passion.

A-la-carte buffet with place for all

Ultimately, amateur radio thrives because of its diversity, not in spite of it. Whether you are pounding brass on CW, chasing weak signals on FT8, or racking up contacts in a weekend contest, every operator plays a vital role in keeping our airwaves alive. Instead of building walls between our chosen modes, we should celebrate the fact that our spectrum has room enough for every kind of passion.

Playing the field

 It was field day eve. It was the Friday and I did not have any specific plans for the ARRL Field day 2026. I was performing a regular scan of my spam folder to ensure nothing that was needed was lurking there. And lurking there was a piece that did not belong there. It was an email from Dan (KB6NU) wondering if I could work the CW Station for W8RP field activities. Fortunately, he had sent me his mobile number as well. So I immediately texted him, that I can fill in any slots if they still had a need. I get an immediate response from him that I can do the 8PM-12PM (0000UTC-0400 UTC). That suited me fine. 

Around 6:30PM on Saturday (2230 UTC) I head out to soccer fields adjacent to the Ann Arbor Municipal airport where the ARROW Club had set up the W8RP stations. It was a pretty grand affair with about 4-5 trailers and a tent. The info tent had information booth for curious visitors. I also believe there was a GOTA station. There were two CW stations running on two different trailers. One trailer was dedicated to data and possibly the other for SSB. After having IRL QSOs with fellow hams, I headed over to the CW station. The happiness on the ham operating the station was a sight to behold. He told he'd been at the station for over 7 hours. 

K4D at W8RP during field day

After a quick hello, I was ready to take over the operations. The radio for the day was an Elecraft K4D. It was paired with a KAT500 tuner and a contest filter paired to a dipole. It was further kitted with a large panadapter display and a Begali Sculpture to boot. I've never seen or operated a K4D before, and I was eager to jump in. So after a quick familiarization with the setup I jumped in to continue the operations. It was not a very busy day and the atmosphere there was not competitive. The previous operator was running in the mid 20wpm and I continued to do the same. At around 0100 UTC I switched over to the 80m band and continued operations there. I was almost entirely "running" the operation. I did not do search and pounce as a) I was not familiar with N1MM+ and did not want to change the settings b) The tuner was narrow Q and I may have to retune often. The latter involved bypassing the contest tuner, and turning on the LP tune mode on the K4D after engaging the KAT500 into the tune mode. All in all I believe I averaged just over 50QSOs per hour in the four hours I was operating there. Come midnight, it was time for me to leave. My XYL had to work the next day and I told her I will be there a little after 1AM. It was a cool night when I geared up for the ride home. There was still a near full moon out. It was eerie to see the football fields where the field stations were set up punctuated with the glow from the monitors and other electronics. I was on the lookout for deer on the way back, but fortunately none of them were active. Soon I was safely ensconced in my bed.

Field day setup at Maybury State Park. Operated as class 1B

The next morning, after seeing off my XYL to work, I headed over to my favorite park to have a combination field day and POTA outing. I operated as "1B" station and managed to have great fun. I was happy to see the bands buzzing with activity. After a while I decided to setup my station in the downtown Farmington (Michigan) area. I worked a few hours there hoping to attract any curious passers by. But strange as it may seem, there never was a curious glance or questions about what I was doing. Perhaps the fact I was right beside the local police station did not stir the usual suspicion in the public passing by. 

While this lack of curiosity was disappointing, the active bands more than made up for it! 

Breaking My Own Golden Rule (And How I Saved My uSDX+)

In my previous post, A Brick Becomes a Diamond, I confessed my absolute dread of firmware updates. I outlined my tried-and-tested workspace mantra: "If it ain't broke, don't fix it!" Applying the version 3.0 update to my MicroPA50 amplifier was a rare exception because that unit was genuinely broken from the factory, constantly rebooting on oversensitive SWR spikes. The update transformed that brick of junk into a rock-solid, 40-watt diamond.

Flush with that victory, I returned to my bench feeling a bit too brave. I looked over at my Chinese clone uSDX+ "White Buttons" QRP transceiver. It was sitting there, doing perfectly fine. Did it have a few quirks? Sure. But it didn't need surgery.

Naturally, I broke my own rule anyway.

I decided I wanted to upgrade the code to add a few custom Morse code CQ messages. It sounded harmless. Fast forward several hours, and I had successfully trapped myself in a cascading nightmare of software locks, ghost buffers, a backward tuning knob, and a radio that was transmitting on completely incorrect frequencies.

If you have ever let workspace hubris get the best of you, here is the non-technical story of how I battled the uSDX+ firmware—and how a single line of code saved the day.

---

Hurdle 1: The Modern Computer vs. The Unsigned Driver

To send the new code to the radio, I used a standard USBasp V3 hardware programmer. Modern Windows 11 has incredibly strict security rules regarding unrecognized hardware, and the standard USBasp driver files are essentially digital antiques. Windows immediately blocked the programmer, refusing to acknowledge its existence.

• How it was navigated: I had to bypass the normal Windows infrastructure using a modern utility called Zadig. Zadig wraps the legacy file in a clean, digitally signed security capsule. Windows finally stopped panicking, and the flashing tool successfully established a link.

Hurdle 2: The Bluffing Error Message

The moment I hit the upload button, the software log screamed in bright red text: Error: cannot set sck period; please check for usbasp firmware update. It looked like a catastrophic failure.

• How it was navigated: This turned out to be a total bluff by the programmer clone. After locating the physical JP3 (Slow SCK) jumper on the USBasp board and bridging it to slow down the data speed, I re-ran the program. The red error message still appeared, but the data stream pushed right past it, completing a 100% byte-for-byte verified flash. Lesson learned: sometimes you just have to ignore the warning text.

Hurdle 3: The Persistent Memory Lock

I booted up the radio, eager to see my changes. My new callsign showed up flawlessly on screen (MY_CALLSIGN lives in the main Flash memory), but my old Morse code messages were still sitting there, completely untouched. Even worse, I realized the tuning was completely off. The radio now assumed it had a standard 27 MHz system clock tracking profile, but my specific "White Buttons" clone board houses a physical 26 MHz crystal.

Because the software math and the physical hardware crystal were out of sync, the internal VFO math completely broke down. The radio interface looked normal, but the actual tuned operating frequency was wildly incorrect on every band. I tried manually clearing the memory using command-line commands and hardware erase flags, but the radio completely ignored them—reverting to its old 27 MHz data blocks on every single reboot.

Hurdle 4: Walking Backwards and Overridden Variables

Before I could even tackle the clock, I ran into another headache: spinning the main tuning knob moved the frequency in the completely wrong direction. The rotary encoder was reversed. I opened up the massive .ino file and changed a configuration constant (like SWAP_ROTARY) to make the knob turn the right way.

Next, I tackled the frequency issue. I used the search bar, located every single active occurrence of 27000000 (the clock frequency constant), and meticulously updated them all to 26000000.

I compiled the code and flashed it again. The result? Total disappointment. The knob turned correctly, but the radio booted right back into its broken 27 MHz loop, the tuned frequency remained incorrect, and the old Morse code texts remained. Updating the base constants in the code text was completely useless. The uSDX core engine is built to protect the system profile. On boot, if it detects any pre-existing structural initialization signatures, it completely ignores the user’s code edits and restores the old 27 MHz data framework over your changes anyway.

The Ultimate Solution: Tactical Interception

The breakthrough happened when I dug deep into the code and found the exact line where the system menu binds the clock parameters to the chip:

case SIFXTAL: paramAction(action, si5351.fxtal, ...)

This proved that the uSDX engine forces its built-in memory blocks to load after the initial variables are parsed, completely undoing any user edits right at startup.

Instead of fighting the radio’s complex formatting layout loops, I decided to use a bit of tactical code interception. I went to the absolute last line of the radio's startup sequence (void setup()), right before the code exits to hand control over to the live tuning screen. I injected a single, unyielding line of absolute code:

si5351.fxtal = 26000000;

By placing it at the absolute end, I let the radio finish its messy, stubborn startup loops first. Then, a millisecond before the radio actually woke up, my line stepped in, overrode the memory blocks, and forced the true 26 MHz clock frequency directly into the VFO processor.

The result was instantaneous. The radio booted up perfectly calibrated, and the VFO math was flawlessly restored—bringing the tuned operating frequencies back into perfect alignment across all bands.

---

The Virtue of Procrastination

When I updated my MicroPA50 amplifier, I learned that a little patience pays off, and that sometimes the next firmware release fixes the bugs you were planning to solder away.

But with the uSDX+ clone, I learned a different lesson: if you break your golden workbench rule and try to fix something that isn't broken, you better be ready to dig through thousands of lines of open-source math to find your way back out!

My portable field stack—the Elecraft KX-3, the MicroPA50, and the newly recalibrated uSDX+—is officially stable, accurate, and ready for action. But the next time I get the urge to touch a perfectly smooth piece of gear? I am leaving the USBasp in the drawer, turning off the soldering iron, and going out for a walk instead.

I Will Ride 200 Miles... And I Will Ride 200 More!

I am very last-minute when it comes to planning trips. I guess it is a holdover from planning motorcycle trips, which can be highly weather-dependent. Now, I am not averse to catching bursts of bad weather during a road trip. In fact, I cannot remember a single cycle trip where I didn't get at least a drop of rain on me. Such is life in the Midwest around the Great Lakes! However, I am also not crazy enough to ride straight into an extended patch of bad weather that blankets an entire geographic region.

Sometime early in the year, one of our POTA enthusiasts mentioned that the 3rd Annual Michigan POTA meetup was planned for June. I filed it away in the back of my mind. Unfortunately, I got distracted by some minor health concerns and work, and it entirely slipped my memory. Needless to say, when I finally tried to look up the dates on Thursday, I found out it was happening on June 6th, 2026—only a few days away.

I usually try to work in a camping trip around the POTA meetup. But this year, I was caught a little unawares. I didn’t have enough time to verify the state of my camping gear, so camping was out of the question. At best, this had to be a day trip. I checked the weather, and it was going to be a gorgeous day here in Michigan. In addition, this year's meetup was at Hartwick Pines State Park (US-1503) near Grayling, MI. It is in the central part of the state, so I knew there would be some new hams making the trip out there.

Riding weather

A quick check of the maps indicated about 200 miles each way, with an estimated riding time of roughly 3 hours per leg. I packed up my KX-3, my N7DDC tuner, the Micro PA50+, and a small snack bag.

I departed at 0630 AM local time. Of course, it was at the very tail end of a shower. So, my streak of never having a trip without a drop of rain remains unbroken! Thankfully, the temps were in the mid-60s (about 20°C), so the rain didn't really matter. About 15 minutes into the ride, the rain clouds cleared out and the sun started to peek through. I could not have asked for better weather. I was incredibly comfortable under my riding gear. On the ride up, I made a quick stop at a rest area to gobble down my yogurt and banana, followed by a quick stop for gas. I rolled into the park around 0940 AM. The organizers were already out and about setting up for the meet.

I decided to squeeze in a quick activation since I had never activated this park before. I set up the KX-3 and the JPC-12 vertical. I started off on 40m but didn't have much success there. After about 20 minutes, I was left with just a single QSO. It was still a little too early for 20m, but when you're desperate, you'll try anything. I adjusted the loading coil on the JPC-12 for 20m and found that it tuned to a 1.3 SWR. I set the ATU in the KX-3 to bypass and hooked up my Micro PA50+ between the transceiver and the antenna. This was going to be the second field test for this amplifier since the firmware upgrade. I started to run at around 30W. Success at last! The new firmware held up flawlessly, and I got about 14 contacts in the next 30 minutes.

After that, I packed up all the gear and headed over to the picnic shelter to see if I could help with anything. The area was already set up. A great feature this year was POTA Bingo. It's a little hard to explain, but the concept should be clear from the image below. This game ensured that the hams mixed freely and got to know one another. I thoroughly enjoyed it.

 

After shooting the breeze for a while, it was time for lunch. Some of the hams took the opportunity to secure a local activation. It was fun to work hams sitting right next to you via 2m/70cm. The occasional feedback squeal from being too close was hilarious to watch. For those who were short of their 10 contacts, walkie-talkies were passed around so other hams could help them establish a contact. I will need to check the activation status of US-1503 around that time block.

After lunch, it was time for the traditional raffle. Alas, my luck did not hold out for a prize! Not to worry, though—completing my bingo card netted me a custom Michigan POTA coaster.

I cannot thank the meetup organizers enough. I have been privileged to attend all three meetups to date, and I am glad to see this event thriving and getting better every year.

With a great smile on my face, I snapped a picture of the trip odometer when I pulled into the garage back home.

A brick becomes a diamond

 I dread firmware/software updates. Now I know they're necessary evil; but still that does not ease my tensions when embarking on an upgrade. One never knows what the effect of "fixes" may be. They could end up breaking your customizations that are running smoothly; or in worst cases can "upgrade" features by removing them, because some business overlord deemed that the formerly free feature now needs to go premium. My approach to updates/upgrades has been the tried and tested mantra: "If it ain't broke, don't fix it!"

But broke does not do effective justice to the Micro PA50+ portable amplifier that I had added to my collection. I had bought the amp to give my field activations a little more oomph on especially bad propagation days. I was hoping that it would complement my KX-3 CW activations well. However, after I bought it and tested it, I was in for serious disappointment. The power amplifier constantly rebooted or entered into protection mode making it unusable.  I could not rely on this amplifier in the field for serious activations.

After a thorough research, I found out that such issues were common among Micro PA50+. The root cause was found to be the overly sensitive SWR measurement by the amplifier. Some of the common fixes were to change the resistance of one of the legs of the SWR bridge to "trick" the amp into measuring SWR correctly. Additional fixes included using a capacitor to smooth out the instantaneous SWR spikes. Life got busy and I put off these mods for the time being. The power amplifier was relegated to my pile of "junk" equipment.

After several months, I found the time again to work on this issue. As I was scouring the web for authoritative fixes, I found a few mentions about the new 3.0 version of the firmware that as the "bee's knees". The few folks who installed it recommended that this solved "all" the problems. 

I had a "broken" Micro PA50+ power amplifier that exhibited all the symptoms that the update claimed to fix. If this didn't justify the application of the update nothing else would. So I downloaded the new firmware and proceeded to apply it.

Note that there are several variants of this amplifier around. Therefore, I am not providing links for the upgrade process here. You should be able to search and find the process for your particular variant. But in effect, in addition to the latest firmware you will use a USB Serial adapter and software that will flash the firmware. You would need to hook up about 4 or 5 pins from the serial adapter on to a header on your power amplifier

I ended up using  AVRDUDESS  for flashing the firmware. It provides a simple UI which allows you to select the COM port [corresponding to the USB serial adapter], the firmware file and the board type for flashing. Once I double checked all the values, I hit the upload firmware button. The process took about 15 seconds and went smoothly. 

I breathed a huge sigh of relief when the amp powered on again after the application of the firmware. The boot flash screen confirmed that the firmware version was indeed upgraded. Now it was time to put the amp through its paces.

Testing the Micro PA50+. Firmware 3.0 indeed seems to have made it more stable

For testing the update I drove the amp using uSDX+ QRP radio paired with N7DDC tuner.  The drive power varied from 1.8W to about 2.5W depending on the band. The Micro PA50+ was able to put out 40-50 watts across most bands. The difference was night and day. The Micro PA50+ was a transformed beast. It was rock solid during my tests. Its power and SWR measurements were now closer and seemed more accurate. It did suffer from a few reboots. It looks like it still suffers from instantaneous SWR spikes in CW call sequences. I was able to eliminate most such reboots by increasing the CW delay to about 500ms. This does mean that you may occasionally miss the first one or two characters of a CW response. However, I believe this is acceptable for field operations. My confidence in the amplifier was enhanced to a such an extent that I took this out for my field activation on 06/01. It performed almost flawlessly there. 

Field test of the Micro PA50+

There were one or two reboots in over 90 minutes of operation. I probably can overcome this by increasing the CW delay or it may very well be that I would still need the capacitor fix to smoothen out the instantaneous spikes. But if I learned the lesson right, perhaps I should procrastinate. The next firmware could very well address that issue as well. Who said that procrastination is not a virtue!

The Little Pi that could

  Bridging the IC-7610, KAT500, and KPA500

I’ve been working on a project to get my station fully remoted while keeping all my gear in sync. My goal was to have my Icom IC-7610 work seamlessly with my Elecraft KAT500 tuner and KPA500 amplifier, managed through a Raspberry Pi (running the RigPi image). I have documented my initial steps to facilitate operating CW remotely using wfview, RigPi Hub and some custom Python code.

Streamlining the Rig Control

I had previously set up the IC-7610 to a Raspberry pi running the rig control software. I was originally planning to use the RigPi web interface to control the radio, But the IC-7610 has a built-in remote server that has better features. So I ended up using wfview on my Windows machine to handle the direct operation of the rig. This greatly simplifies things because it manages the high-quality remote audio and spectrum display natively over the network as well as instant access to memory presets.

RigPi radio control allows to setup a Hamlib instance for each radio defined. But, wfview talks directly to the radio's internal server, the immediate operation of the rig doesn't depend on Hamlib. However, for radios not supported by wfview, or for other logging software the Hamlib server will come in handy. I personally use Log4OM for my logging, which connects via Hamlib to track frequency changes and keep my logs accurate in real-time. One can also control the frequency changes right from this software if desired.

Connecting the Elecraft Duo

The hardware side involves connecting the IC-7610, the KAT500, and the KPA500 directly to the Raspberry Pi via USB cables. For the KAT500 I used the Elecraft KXUSB cable. The KAT500 is picky. It did not accept my DIY cable with an FTDI/USB adapter. The KPA 500 was more forgiving and worked happily with a generic FTDI serial to com adapter with a DB9 terminator.

However, this is only half the battle. To make the Elecraft duo accessible to my Windows machine, I use a few key tools:

ser2net: This utility on the Pi "exposes" the physical USB ports for the tuner and amp as TCP network ports (e.g., ports 3002 and 3003). ser2net installs as a systemctl service on Raspberry pi and reads its configuration from /etc/ser2net.yaml. I added a configuration such as the following to expose the serial port that the KAT500 was connected to onto TCP port 3002. You should be able to find your device by listing the contents of the /dev/serial/by-id/ before and after connecting the KAT500. The new entry is the one that you have to use. You may have a few entries for them at various levels in the path, I chose the deepest path for the port [the one that includes the port number in the device ]

connection: &kat500

    accepter: tcp,0.0.0.0,3002

    enable: on

    options:

      max-connections: 7

      kickolduser: true

    connector: serialdev,/dev/serial/by-id/usb-FTDI_FT231X_USB_UART_DU0CUZN3-if00-port0,38400n81,local

After this you start the service similar to any other systemctl service. I had also marked the service to autostart so it restarts on every reboot. 

com0com & hub4com: On Windows, com0com creates a pair of virtual ports linked together like a software "null modem" cable. I then use hub4com to bind one end of this virtual pair over the LAN to the ser2net port on the Pi. This allows my Elecraft Utilities to connect to the other end of the virtual com0com pair, seamlessly remoting the connection to the Raspberry Pi. 

The following image shows the virtual port pairs created via com0com. The pair CNCA1<->COM18 is the pair created for the KAT500. 

The CNCA1 end of it is connected to the ser2net exposed port on the Raspberry pi. I use the following hub4com command to bind to the remote port. COM18 appears as a normal port that the KAT500 utility.

C:\Utils\hub4com-2.1.0.0-386>\com2tcp-rfc2217  \\.\CNCA1 192.168.x.x 3002

This connects local port COM18 over the net to the COM port on the Raspberry pi that the KAT500 is attached to. Similarly, I created the CNCA2<->COM19 pair for the KPA500.

As far as the utilities are concerned, they are operating with locally attached KAT500 and KPA500 respectively. 

Elecraft Utilities on windows believe they are talking to the devices attached locally to the COM ports. 

The Synchronization Script

The final piece of the puzzle was getting the Elecraft gear to follow the Icom's frequency. There are other hardware solutions possible, but Elecraft does not really play nice with the ICOMs frequency output. Their advice has been to rely on the lightning fast frequency counters within the KAT500 and KPA500. There are some commercially available software that can also provide this integration; but I was not willing to go down that route.

However, as we can see we have all pieces in place for a software solution. All we need is a glue that will tie the different protocols, I wrote a simple Python script that runs on the station server.

The script polls the radio's frequency through the Hamlib server and pushes the matching frequency and band commands to the KAT500 and KPA500 via the ser2net ports. By enabling multiple connections in ser2net, the script can handle the background tracking without interfering with the Elecraft utilities I have running on my screen.

Final Results

Here is the screen image of my remote windows station. It shows the KAT500, KPA500, wfview all living in harmony. In this instance I was testing the syncing software on my Windows machine. Once I validate all things working well, I moved the script over to the RigPi host,

As mentioned earlier, I also have my remote CW keying integrated into the Pi, making the whole system a very functional, modest-budget remote station where different brands of gear work together quite well.