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.

Remote Heaven

UPDATE: I have since made additional changes to even have my Elecraft KAT500/KPA500 combo into the remote control fold as well. See https://motopota.blogspot.com/2026/05/the-pi-in-sky.html

Freezing toes! My "ham station" is tucked into a corner of the room that gets incredibly cold during the winter. Whenever I brought this up to my XYL, she had a simple suggestion: "Why don't you just put on thicker socks?" But no self-respecting ham would settle for such an easy fix. I wanted to be freed from that icy corner and operate in comfort from my favorite spot—the recliner in the living room. This is the story of my journey to make that a reality.

My base station is an Icom IC-7610, which features built-in networking. When paired with the stellar wfview software, it allows for nearly complete remote operation. However, I am primarily a CW operator. While wfview supports remote CW, it is limited to keyboard entry. For me, the true joy of CW lies in the tactile experience of using physical paddles.

Solutions for this exist, ranging from pricey dedicated hardware to free software like Remote CWKeyer, which uses inexpensive USB-to-serial adapters to send CW over a network. Unfortunately, the latter was Windows-only, and I didn’t have a spare Windows box to dedicate to the task.

What I did have was a spare Raspberry Pi, a few FTDI serial adapters, and a cheap Chinese electronic keyer I’d bought for rigs lacking a built-in keyer. Since the IC-7610 exposes COM ports via USB and can be configured for Morse keying by asserting the DTR or CTS pins, I had the building blocks for a solution.

During my research, I discovered that the RigPi Hub and RigPi Station Server (RSS) combination seemed to offer exactly what I needed. The RigPi Hub installs on a Windows client and translates keyer clicks from a COM port into UDP packets. These packets are sent to the RSS, which "replays" them on a connected serial port. Easy peasy! I asked an AI search tool if I could send keyer data from my Windows machine and replay it as USB keying data on the IC-7610's built-in port via the RSS. The AI gave me a resounding "yes" and even provided the necessary configuration.
I burned the RigPi image and configured everything as instructed. On my Windows box, I set up the RigPi Hub and connected it to my FTDI adapter and paddles. The hub tested perfectly, showing it was receiving my clicks correctly. But when I put it all together? Silence.

Time to troubleshoot. After verifying it wasn't a networking issue or dropped UDP packets, I started digging into the RSS code. I eventually discovered that the keyer port in RigPi is always initialized as a Winkeyer device—which is incompatible with the IC-7610’s internal USB keying. Furthermore, the "RigPi Keyer" setting was designed specifically for RigPi’s proprietary hardware, not a DIY Raspberry Pi setup. I finally confirmed this in a buried piece of documentation. So much for trusting AI results!

RigPi Hub setup on windows. Notice the RigPI IP and the RigPI CW Port. Keyer connected on COM22

I had a choice: fork the RSS code and modify it, or build something myself. Since the RSS code was a bit inscrutable, I opted for the simpler route. I wrote a Python script to listen on a UDP port and assert the DTR pins upon packet arrival. By analyzing the packets sent by the RigPi Hub, I realized they were sent in a simple format and repeated to account for UDP packet loss. Once I could parse the data and ignore duplicates, I mapped the output to the DTR pins of the IC-7610. (Note: The IC-7610 exposes two COM ports, USB A and B; you must ensure CW keying is enabled for the specific port you're using). Once it was working reliably, I created a systemctl service to ensure the script would launch automatically at boot.

For my first QSO, I stayed near the rig just in case. My caution was justified: a few wires worked loose from the adapter, resulting in a "stuck" key. Once that was repaired, it was time for a real test. I heard a CQ on 30m and answered at 22 wpm, carefully avoiding the physical buttons on the radio to maintain the remote simulation. The QSO went flawlessly.

My Laptop screen ready for remote action. wfview on bottom left for rig control. I use the RigPi Hub (top left) Key button to initiate tuning.

Emboldened, I moved my laptop a few feet away and tried sending a CQ. This time, something was wrong—the cadence was off. Another troubleshooting session revealed that my laptop was entering a "power save" mode on battery, even though the charge was full. Once I plugged in the power adapter, the timing returned to normal. Happiness restored!

Finally, I moved the laptop and paddles to the living room, put my feet up in the recliner, and balanced the keyer on my lap. I heard a friend calling CQ and responded with a wonderful QSO at 28 wpm. A happier ham I could not be!

I realize that relying on COM ports and UDP makes this solution vulnerable to OS lag and network hiccups. However, unless you’re a serious contester, this setup is more than adequate for casual rag-chewing. It’s a perfect solution for operating remotely within the house, with the reassurance that I can always walk to the shack if something goes wrong. That said, I’m curious to see how it holds up when I’m truly remote, connecting back home via VPN.

Morse from the recliner by the fireplace. I used an external electronic keyer for me to be able to use a paddle because the RigPi Hub only supports a straight key

To Summarize: The final setup

1. Morse key connected to FTDI USB Serial adapter [CTS and ground pins]

2. RigPi Hub pointed at the COM port for the ahove when plugged in. 

3. RigPi Hub connected to my Raspberry pi host and at the port that my python script listens to.

4. The Python script on the PI interprets the UDP packets from RigPi Hub

5. The Python script tickles the DTR pins of the serial port of the ICOM radio

6. CW Tones emitted.

Note: If you do not have a Radio with built in serial port, you can use another FTDI adapter connected to the Raspberry Pi and have its DTR activated. You can then connect a simple audio cable to the radio's straight key input for triggering the radio.

UPDATE: I have since made additional changes to even have my Elecraft KAT500/KPA500 combo into the remote control fold as well. See https://motopota.blogspot.com/2026/04/remote-heaven.html