I have a Xiegu X6100. It is a small portable HF transceiver and genuinely good hardware. The stock firmware is not bad but it is missing things -- CTCSS transmit tones being one of them. I started looking into the custom firmware community a few weeks ago and it opened up a lot of possibilities. This is where I am so far.
The custom firmware story for the X6100 starts with a Russian developer who goes by r1cbu. He built a completely custom GUI and firmware stack for the radio -- better waterfall, digital mode support including built-in FT8 encode and decode, a much cleaner interface overall. The community around it is active on groups.io and GitHub.
At some point r1cbu announced he was stepping back from the project. He said he was no longer happy with the X6100 hardware quality and wanted to focus on building his own radio. This sent me looking for where the project had gone after that.
The answer is that it had not really died. There were forks and continuations. The version I was running at the time -- 0.31.2 -- was actually newer than most of what turned up in web searches, which told me someone was still cutting releases. The community around xiegu-x6100@groups.io had people like R2RFE making modifications and publishing updated builds.
There is also a tool called x6100-fw-mangler which lets you inspect and modify the firmware image itself. The X6100 firmware is encrypted with ChaCha20, so you cannot just unpack it and look around -- but the mangler handles that and gives you access to the internals.
I do Parks on the Air activations. When you are out in a field operating portable HF, one of the things you need to do is get yourself spotted on the POTA network so chasers can find you. The normal way to do this is with a phone app or a website. You enter your callsign, the park you are activating, the frequency you are on, and it posts a spot.
That works fine. But I started thinking about doing it without the phone.
JS8Call is a weak signal digital mode that runs on HF. It is built on the same foundation as FT8 but designed for keyboard-to-keyboard messaging and relay networks. One thing JS8Call operators do is relay POTA spots -- if you transmit a spot message in JS8Call format, other stations running JS8Call will receive it and relay it to the internet spotting network automatically.
So the idea was: find a clear frequency, press a button on the X6100, have the radio switch to the JS8Call frequency on the current band, transmit a spot message, then return to where you were. No phone, no laptop, no internet connection required at the operating position.
When I first described this to Claude, the response was a detailed plan for implementing the full JS8Call protocol stack inside the radio firmware. That was not what I was asking for. I pushed back and pointed out that you do not need to implement the whole protocol to transmit -- you just need to generate the right audio tones and key the radio. That reframing simplified the whole thing considerably.
The X6100 running r1cbu firmware is essentially a Linux computer. It runs a custom buildroot system on an Allwinner A33 processor. You can SSH into it. You can run scripts on it.
The first concrete idea was a bash script. The flow would be:
We sketched out what that would look like and got a working proof of concept structure. The CAT control side was straightforward -- the X6100 responds to standard Hamlib commands over the serial interface. The JS8Call audio generation was the harder part, and that is where it stayed as a concept for a while.
The r1cbu firmware GUI is built with LVGL, which is an embedded graphics library written in C. Adding a menu item to it is not trivial if you have never worked with it. I asked Claude to sketch out what a POTA spot menu would look like in the existing UI framework -- input fields for park reference and band, a spot button, status feedback.
The result was a C code skeleton that showed how to add a modal dialog to the existing menu system. I was not going to write that myself, but having it drafted meant I could understand what integration would actually involve and decide whether it was worth pursuing.
The answer at that point was: not yet. The audio generation side was not solved, so building the UI first would have been putting the cart before the horse.
Around the same time I was looking at other gaps in the X6100 firmware. CTCSS transmit tone support was one. The stock firmware does not support CTCSS on transmit, which means you cannot use the radio to access repeaters that require a tone. The custom firmware does not have it either.
The workaround I landed on was running the audio through a computer, adding the CTCSS tone in software using fldigi, and piping that back to the radio via the Digirig interface. It works but it is an extra step. I filed it away as something the firmware should eventually handle natively.
I also got the Digirig physically working on Linux around this time. The Digirig shows up as a C-Media USB audio device and a pair of serial ports for CAT control. Getting WSJT-X talking to the X6100 through it on KDE Plasma on Wayland took some troubleshooting -- mostly getting the right serial port (/dev/ttyACM0) and making sure the dialout group membership was actually active.
The X6100 is set up and working for digital modes on the bench. The POTA spotting idea is defined clearly enough to start building. The next step is solving the JS8Call audio generation side -- once that works the rest of it is plumbing.
The actual implementation -- the JS8 engine, the audio pipeline, the UI integration -- is still ahead. But the concept is solid and the firmware architecture is understood well enough to know it is doable. More to come as this moves forward.