X6100

R1CBU 0.31.2 has been out for a while, so I finally upgraded. The only fix didn’t matter to me so much, but it was time to get up-to-date.

The activation at King’s Gap Environmental Education Center, US-4361 was tough-going, even though I was at the top of the mountain. I used the GRA vertical whip with tapped coil. Internet access flaked early, so successfully spotted myself on APRS with APSPOT.

Changes

R1CBU 0.30.0 brings several notable changes:

• The ATT/PRE indicator has been split again, allowing them to operate independently.
• A fix for storing/loading of the ATU network has been implemented. This is a different implementation from the PR I submitted.
• Controls for an alternate patched baseband have been added, though I haven’t tried the new baseband yet.

Testing

The software continues to reload preferences from the previous version, which is good. The UI changes look promising. However, the Maximum Usable Frequency (MUF) has been low for the past couple of weeks, making 20M barely usable today. Despite that challenge, I can still see my reports on PSKReporter on 20M. I’ve been keeping my power at around 2W for the past couple of months. My first contact with this new firmware was hunting a park near Memphis, TN, on FT8, using 2W.

I encountered a bug with the ATU in the X6100 running R1CBU firmware version 0.29.2.

The ATU networking information is stored in both a cache and the params.db file. When setting multiple tunings close to each other (e.g., 7073, 7074, 7075 kHz), the radio would rapidly cycle through them as the VFO was spun. This behavior cluttered the configurations and made it difficult for the ATU network to hold a stable tune near a signal.

Upon investigation, I discovered that while the cache retained all these closely spaced tunings, the params.db only saved one of them. The intention behind the new feature in R1CBU was to remove the hard boundaries between ATU configurations (which were previously every 25 or 50 kHz), allowing a single tuning network to be effective within approximately 25 kHz in either direction. The database would correctly update a nearby frequency to the middle, but the cache’s retention of every tuning caused the “thrashing” effect. Switching antennas or cycling power would reload the sparser collection of networks from the database, temporarily resolving the issue.

I filed a bug report, and submitted a pull request to fix it.

I patched the ATU code to reload the cache from the database immediately, effectively discarding the extraneous nearby networks.

I encountered a bug using the ATU on R1CBU 0.29.2. I had lots of tunings very near each other, so it switched a lot. It queries and uses the nearest tuning to current frequency, so lots of close tunings will cause thrashing as you move. I cleared the atu table in params.db to alleviate the problem for a bit.

I visited Gifford Pinchot State Part, US-1356, and strung up the EFHW from a picnic table to a tree. I managed it in 1 throw to a nice spot. I made 20 contacts:

• 18 FT8
• 2 CW, including N4T, the Dry Tortugas DXpedition

Using R1CBU 0.29.1, I knew to pay special attention to undo the AM bug from SWR Scan by switching through modes after an SWR Scan. In this firmware, though, WSJTX would set digital mode (USB-D) and it would bounce back to USB, which doesn’t take sound from the connection to the computer. I had to work around it by disabling WSJTX’s ability to set the mode. Then I could set USB-D and it would stay there.

After my park outing, I returned to find an update to R1CBU 0.29.2. It includes fixes for:

• SWR Scan that leaves the radio in AM mode
• CAT control of modes

My X6100 started freezing up its user-interface. This happens sometimes when the radio board shuts off, but the UI board hasn’t yet. It would happen when I was transmitting, even very low power, 2W. It even did it after a long time just listening.

I unplugging the USB-C from the computer, and it would allow the UI to shutdown, so the USB-C was powering the UI board, while the radio board had shutdown. The internal battery indicator looked like it may have shown low for a moment, but I was on 12V.

I finally realized I had enabled battery charging all the time. Charging the mostly-worn-out battery caused this new shutdown problem. I disabled charging, and now the radio is running fine again.

I ordered 2 new internal battery packs from Amazon to install. I used to be able to run the radio on internal battery for a little while, but now as soon as I unplug external power, the battery will read something terribly low like 7% and about 6 volts.

Xiegu released another updated firmware for the X6100: APP 1.1.9 & BASE 1.1.8, dated 2024-09-23.

1. I downloaded it from Radioddity, and wrote it to an SD card:

$ sudo dd if=sdcard.img of=/dev/sda bs=1M status=progress

2. I booted the new card for the app upgrade to 1.1.9,
3. I applied baseband 1.1.8 from the menu in the UI.
4. I tried the CW key in the stock firmware, and it transmitted (unlike last time).
5. I booted back to R1CBU, and it looked good there as well.

I did a little FT8, decoded some CW, and listened to some SSB on 40m. I found I could to turn the RF Gain closer to 100 instead of below 63. It may be reading slightly lower power on the display before ALC kicks in: up to but not over the 5W, where it used to often push a little past.

It’ll stay.

Radioddity had the new firmware for the X6100. I downloaded it, wrote it, installed it, and rebooted it to see the stock APP 1.1.8 and BASE 1.1.7. That mostly-useless audio spectrum is gone. The strange jump at 63 in RF GAIN is fixed.

BUT transmitting gave NO POWER. R1CBU also exhibited the problem. When I downgraded to BASE 1.1.6, it transmitted again. Others had seen this problem as well, while others had it work. It must have depended upon variations in the hardware.