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!