R1cbu

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.

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

There’s a new person building onto Oleg’s R1CBU firmware. He first made a patch TGZ available, and then an entire image.

He has a repo for this work, and it includes some build instructions which reference the buildroot and submodules. I think I’m close to being able to build it, but I’m seeing some errors trying to find the xkbcommon headers.

I did patch his source with my DB changes. I built the DB: sqlite3 params.db < params.sql, mounted the DATA partition, and copied my custom params.db to it.

It’s looking nice so far. I can use flrig and have wsjtx and fldigi both talk to it simultaneously. That’s the main improvement in my mind, but it includes some other fixes:

• volume encoder can be spun quickly now
• smoothing of the TX/SWR graphs
• finer detail in the waterfall

I updated the bands on my X6100 running R1CBU to follow the US band plan/privileges:

• Clone source: https://github.com/strijar/x6100_gui
• Update sql/bands_ham.csv to break bands by plan and privileges for US
• Update sql/params.sql to not import band_params.csv, but to instead build it from the bands table
• Rebuild the db: sqlite3 params.db < params.sql
• Copy the new params.db to the DATA partition of the SD card

Rebuilding the database loses all your settings on the radio, so you have to put those back, but I can now see where the general privileges start and end on each band.

I updated my X6100 to R1CBU 0.20.1. Oleg provided a tgz with only the updated files, so I dropped the file into /DATA partition, started up the radio, and it unpacked the update. The tgz contained the x6100_ui binary and params.db.

This can be an interesting way to make my own updates without needing to know how to rebuild the entire image. I see the changes applied to his x6100_gui github repo, so I know that’s a good base for making future changes.

Learning to do make updates is interesting, because the original maintainer, Oleg, is likely done updating this firmware in favor of building his own radio in the image of the X6100. He’s frustrated trying to get help and documentation from Xiegu. I run the R1CBU firmware full-time.

A new R1CBU firmware is available for the X6100.

I wrote the image to the micro SD card:

$ sudo dd if=x6100_r1cbu_v0.20.0_sdcard.img bs=1M of=/dev/sdb status=progress

It’s working fine. Auto levels for waterfall and spectrum seems useful, but it still shows the min/max level settings that do nothing while in auto. I had to set up all preferences again, since it comes with a new database on the image.