Monday, January 30, 2023

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 ( 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 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. for the Radio, 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 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. 


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


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.

Forty Years of Personal Computing - BBUG


In the early 1980s, I was excited about the MC6809 processor. I wanted one. But my student budget couldn't afford it. I studied all material about the MC6809 I could get my hands on.

In 1981, I obtained the source code to SBUG-E, the SWTPc ROM monitor for the MP-09 board. I was familiar with the source code to the MC6800 ROM monitors MIKBUG and SWTBUG. SBUG-E demonstrated the elegance of the MC6809 processor.

As I understood SBUG-E, I wasn't satisfied with it. I began to modify the source to suit my own purpose.  I called this resulting monitor BBUG. 

I worked on BBUG for a couple of years, off and on. My earliest printout is from April 1981. I wrote code using a cross-assembler and pour over the listings. I hunted for ways to make BBUG compact, as it had to fit in a 2 KB ROM. But the code never ran until I built the Homebrew MC6809 CPU board in mid-1983. (Which is another story)

BBUG's command structure is similar to SBUG-E, as is a lot of the code. Here are the differences.

Commands Removed

I removed several commands from SBUG-E. My plan for an MC6809 computer had floppy disks, so the cassette tape operations were the first to go. The DMAF1/2 8" disk system seemed incredibly expensive, so I removed that boot command, and used the D command character for an SS-30 floppy disk controller boot. Finally, the stack memory dump didn't seem useful to me, so I pulled it, too.

In summary:

  • D - no DMAF1/DMAF2 boot - no DMAFx 8" disk controller
  • L - no cassette tape operation
  • P - no cassette tape operation 
  • S - stack memory dump didn't seem useful
  • U - changed this command to D, see below

Commands Added

I added a couple of new commands for BBUG. The first was a memory fill command. SWTBUG had this as well. I also added a help command.
  • F start-end byte - Fill Memory from start to end address with given byte value
  • Z - Help - prints a summary of commands

Other Changes / Refactorings

Other parts of SBUG-E were re-written and improved:
  • Q - I spent some time in college investigating memory test methods. I re-wrote this test to use a modulo 255 memory convergence test with nine total passes. This is a fast test that detects most kinds of memory errors.
  • U - Changed this command to D and completely re-wrote as an improved boot from an SS-30 Floppy Disk Controller. Major changes include:
    • Performs up to sixteen tries, allowing recovery from soft errors.
    • Alternates single and double density between tries, so it can boot from double-density disks.
    • Works with FD1771 and WD2797 controller chips
    • Works with 5 1/4" and 8" versions of controller board (more on this later)
  • Command code positioned in alphabetical order in source. This made no difference in the space requirements or efficiency of the monitor, but it made it much easier to find the commands I was working on.
  • Alter register commands refactored to use less space.
The last iteration of BBUG v1.91 fits in a 2 KB EPROM with 1 byte to spare. 

4 KB Version

In October 1986, I experimented with expanding BBUG to fit a 4 KB ROM. This version has a test string at address F000, and the rest of BBUG at address F800. You can see this version at the bottom left in the picture above. 

The test was successful, and this left space for more commands. At that point, however, I was more interested in OS-9, and had less use for BBUG.

Future Changes

If I make any future modifications to BBUG, the first thing I'd do is a fix a bug. The extended memory initialization assumes that the E-block is at physical address FE000, so it writes F1 into that block. That's not compatible with the current Homebrew MC6809 V2 board (which is another story), where the value should be 01 instead. This would also match the value written by OS-9 Level 1. 

There's also 2 KB of additional space for more commands. Extended memory functions would be welcome. A command to catalog all the extended memory blocks would be useful, as well as running memory tests on extended memory blocks. That would be a start. And I might bring back the stack memory dump command.