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.

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/04/remote-heaven.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

Stinker from an old timer

Note: I have redacted names, callsigns and dates in the narrative 

I was surprised to see an email titled "Interference with XXXX" in my inbox from a fellow operator. Here it is in its entirety. Note this was the second email (with a previous one nearly identical to this one. I am omitting that one for brevity)

Dear Ram,

I have to admit, I am a bit disappointed you started operating on the frequency I was using this evening. Especially with another SKCC member. I am operating a Special event Station (XXX) on x.044 @XX:XX this evening. Worst of all, you never first check to see if the frequency was clear (QRL?). If you had I would have zero beat to your freq to let you know I was there operating. Back in the day we all listened first, then put out a QRL. I realize with more crowded bands and younger hams getting their ticket in a weekend, and lack of ELMERS, it becomes paramount to be more courteous than ever. Since you took over the frequency I was operating, I will bow to you and stop operating the Special event station so you can operate your more important POTA. In the future, I kindly ask that you listen first, then send out a QRL to double check the frequency is in use before you just take it. 

--73--

XXX

I was a little shaken. I was saying to myself what did you do? Questions started racing in my mind. Did I stomp on someone else? I always put out QRLs. Did I forget it that day? So hurriedly I look up the log and found that I was operating 500Hz above the frequency mentioned. Even though the tone of the email irritated me and made some unreasonable assumptions about my operations (such as not putting out QRLs) , I sent the following replies. Originally I had checked the wrong date and responded with the following. Subsequently after realizing that error, verified the date and time in question and sent the second email below.

I looked up RBN Again and only see me on x44.5. I'm wondering if your filters were wider...

73 

XXX,

Rechecked XXX XX. I see no spots for me on x44 for me around the time frame.  All spots for me are on x44.5. Please see attached image. I usually shy away from round number frequencies especially when on the field. I typically operate 5w QRP or at most 10W on bad days. I was 10W that day with a simple wire antenna on the tree.  As a QRP operator I have been run out of the frequency many a time by inconsiderate operators and contesters some of whom are old timers from the halcyon age you allude to. So let's not tar and feather the whole crop of newer operators as there are examples of bad operators of varying tenure and skills. I've learnt to grow a thicker skin than having to dwell on that too much. 

Wishing you the best in the future. 

Ram

KE8UEX

73

Note: Not posting the RBN image was attached to the email that indicated the frequency and dates I was operating on.

I was hoping this clarification should be sufficient. However, I get the response below indicating that operating 500Hz above on CW is considered stomping on the frequency 500Hz below.  The request now seems to be that I should stay 1KHz from his station? He also acknowledged he heard my QRL and walks back his early accusation of me not doing so. Instead of saying sorry he goes on to patronize me for putting out the QRL.

Hello Ram,

I can understand your response, however, the confusion lies in that I was the one on xx.044 holding QSO's for the special event, not you, In looking at my notes I did hear you start out with QRL, which I replied to let you know I was operating 500Hz below you then you started calling CQ pushing me off a frequency because of other stations not zero beat, which got to the point I had to QSY off. I think the issue may lay in if you were using a CW filter? If you were and most CW filters are usually set around 2-300Hz, which means your filters tight response you would not have heard me because I was out of your window. All I am suggesting, in the future maybe open up your filter a bit when putting out a QRL. I commend you for doing that. As crowded as the bands are today because we now have to share our coveted bands with Chicken banders (CB'ers). I guess, really no harm done since I did a lot of QSO's volunteering for the week long special event station and was only kicked off the frequency once. Hahaha! I appreciate your reply.

Hmm... the bands must have been especially favorable for me as a 10W station to push out a QRO special event station 500Hz away! Needless to say, this reply irked me further as the as he still insists I was in the wrong. Other than the suggestion about widening the filter the patronizing/dismissive attitude added to the irritation. The concluding statement dripping with sarcasm made me determine a more direct approach was needed to get the point through. I sent the following reply. Note it is split into two emails because the send button was hit accidentally during composition

xxx,

You said: the confusion lies in that I was the one on x.044...

There is no confusion here.  I clearly understood your original missive. I am responding to your unjust accusations you raised in your original email.

You said: I am a bit disappointed you started operating on the frequency I was using this evening. 

This is clearly not borne out by the evidence I have presented. Operating 500Hz above you on CW is in no way operating on your frequency. This is at the highest end of ARRL recommendations for separation of 150-500Hz separation between stations. This should accommodate even the most egregious non zero-beaters.

You said: Worst of all, you never first check to see if the frequency was clear (QRL?). 

I see that you recanted this in the subsequent email. I understand apologizing is hard, but I appreciate you conceding that this was also an unfounded accusation not based on facts.

You said:  ... it becomes paramount to be more courteous than ever... I will bow to you and stop operating the Special event station so you can operate your more important POTA

Courtesy should extend beyond the air. While I understand the irritation of operating in crowded bands, I respectfully push back on the tone in your original email. I'm sure if you were sitting across from me you would not have used that tone. I'm not sure where the condescension for POTA operations come from given that you're an active POTA hunter as well. I also believe operating special event station does not confer any special privileges on the amateur bands. 

You said in the later email:  All I am suggesting, in the future maybe open up your filter a bit when putting out a QRL
A good suggestion that I may consider especially when expecting a lot of vintage gears on the air. I still do believe expecting a 1MHz separation for CW operations seems a little bit excessive.

You said: we now have to share our coveted bands with Chicken banders (CB'ers)

You said:  really no harm done since I did a lot of QSO's volunteering for the week long special event 

I am glad that you had a successful event. I did have a great outing at the park that day as well. I still wonder if QSYing was such a non event, what prompted the vitriolic email in the first place. 

===== THE SECOND EMAIL TO COMPLETE THE ONE ABOVE

xxx,

Sorry the previous reply was unfinished. Few corrections and the completion of the email follows: 

I said: . I still do believe expecting a 1MHz separation for CW operations seems a little bit excessive

It should read 1KHz

You said: we now have to share our coveted bands with Chicken banders (CB'ers)

I try to stay away from in-group and out-group thinking. We amateur radio operators work with what we have been granted

Hope you have fun on the air

73

Ram

KE8UEX

To which I got the classiest of replies from a courteous old-timer. 

It's clear we think differently, and no sense wasting anymore of my time with you. 

--73--

This goes on to prove age and wisdom does not equate to class. If this operator believes he is trying to educate other hams, taking a softer tone initially would probably fall on more receptive ears. For whatever it is worth, this operator has impressive credentials in the QRZ page which I respect. His supercilious attitude and sense of entitlement... I do not. 

I responded with the following. What would you have done?

XXX.

Sorry you feel that way. Wish you the very best

Ram

73

KE8UEX

Humble Pi(e) day!

 Saturday, March 14 2026 [3/14]. For some math enthusiasts who subscribe to the US centric view of writing dates, it is Pi day. For some ham radio enthusiasts like me it was strange day with weird propagation.

I started of the day to get my early morning CW fix. Nothing like beginning the day with a good ragchew QSO. On weekends, I usually lurk on the 80m bands very early in the morning and then switch on to 40m as the propagation there gets better.  But today, the bands were flat and I did not hear any of the regulars on the band. This early harbinger should have informed me to be the tough band conditions that day.

But the information did not percolate in. Instead, I spent some time solving the New York Times Crossword and their other puzzles. A little while later, my wife wanted me to run some errands. Unwilling to let this chance go by, I decided to go in for a POTA activation. However, I was not prepared for how rough the bands were. It usually takes me about 20-30 minutes to rustle up 10 contacts. What should have been a quick 30 minute detour into the park turned into a 90 minute nailbiter. I hopped all over the bands. Very few CQs were answered. I knew that if I waited for someone to contact me after hearing my CQ it was going to take much longer to get my 10 contacts. I decided to answer the CQs of other POTA activators. I usually do not do that as I am at topped out at 10W on my POTA setup. I cannot compete with the KW stations in a pileup. But today, it was different. It was a mix of desperation and desire to help out other activators facing rough conditions. Most hunters decidedly stayed away due to rough band conditions; there was no pileup. It was miraculous that some of the POTA stations heard me. I eventually ended up with 11 contacts with about 7 of them being park-to-park QSOs initiated from my end.

I reflected on the day and wondered why I even decided for an activation that day. Then I realized this was perhaps due to the strange propagation I experienced earlier in the day. I was looking at my RBN reports of my CQs on 40m in the morning. I noticed that while most of the usual stations in the 300-600 mile range did not hear me, I was heard loud and clear in ZL. Perhaps I was hoping for a first ZL contact from the park. Perhaps one day that dream would come true!