OpenX6X00 v0.3.7 Adds Band Plans and Winlink

The latest community firmware release gives the Xiegu X6100 and X6200 more region-aware operating tools, a clearer Winlink workflow and an experimental alternative modem. It also shows how much of a modern software-defined radio can be reshaped by software running on the radio itself.

An HF transceiver used to be defined largely by its front panel and the firmware supplied by its manufacturer. OpenX6X00 is changing that expectation for the Xiegu X6100 and X6200. Its latest release, v0.3.7, adds regional band plans, licence-class restrictions for US operators, revised Winlink tools and an experimental Mercury modem. These features join digital-mode applications, logging, remote browser control and other software that runs on the radio rather than on a separate computer.

That distinction matters in practical operating. A laptop can add digital modes and networking to almost any transceiver, but it also adds another screen, another set of cables and another device to power and troubleshoot. OpenX6X00 places many of those functions in the radio’s existing computing environment. The result is not simply a new screen design: it is a different way of using the radio, with software that can connect operating, logging and network features in one place.

Version 0.3.7 is a useful marker in that shift. The release does not introduce a new RF stage or change the radio’s underlying baseband firmware. Instead, it expands how the Linux side of the radio interprets operating rules, presents digital communications and protects its web-connected controls. The changes also reveal the demands of maintaining an open firmware project: new features have to fit into two related radios, respect differences between national operating plans and behave safely when software is exposed through a local network or remote connection.

From a replacement interface to a software platform

OpenX6X00 runs on the Linux side of the X6100 and X6200, using a microSD card. The radios retain separate baseband firmware for functions such as the DSP, RF, power control and keyer. OpenX6X00 communicates with that baseband software, but does not replace it. This division gives the project room to develop the user interface and applications while relying on the radio’s existing firmware for lower-level transceiver functions.

That arrangement is important because “open firmware” can suggest that every part of a radio has been replaced or made freely modifiable. Here, the project controls a substantial software layer, but the baseband remains a separate component supplied by Xiegu. The operating system, applications, control interface and web tools can change independently of the firmware that manages the radio hardware. For users, the practical boundary is that a feature available in OpenX6X00 may still depend on what the underlying baseband exposes.

The project’s lineage also helps explain its scope. OpenX6X00 was forked from an earlier open release of firmware for the X6100 after that upstream project became closed. Its maintainers describe removing services that called home and continuing development in the open. The resulting system has grown to include a browser-based control panel, a DX cluster display, logging, field-operation programs and several digital modes. The new release extends this software environment rather than treating each function as a separate accessory.

The radio’s internal computer changes the shape of a portable station. When a digital-mode program runs on the radio, the operator may not need to connect a computer merely to decode or transmit a supported mode. When a log or activation tool is also available on the same platform, some operating tasks can happen without moving between devices. Browser control adds another option: a phone, tablet or computer on the local network can operate the radio through a web interface. Together, these features make the transceiver less dependent on an external computer for common digital and networked tasks.

This integration has limits. The radio’s physical controls, screen, audio paths and baseband capabilities still determine what the software can do. A Linux application can provide a new workflow, but it cannot remove the constraints of the transceiver hardware or guarantee that every function behaves identically on both models. The distinction between the application layer and the baseband is especially relevant when users compare firmware features, investigate an operating problem or decide whether to update. A more capable software platform expands the radio’s uses, while the underlying design continues to set the boundaries.

Band plans that follow the operator

The most visible change in v0.3.7 may be its expanded band-plan system. Earlier versions of the on-screen band-plan strip knew only the IARU Region 1 plan. The new version adds IARU Regions 2 and 3, along with US plans for Extra, Advanced, General and Technician licence classes. This makes the display more useful to operators whose regional allocations differ from the plan the software originally supported.

Band plans are more than labels on a screen. They help operators understand where different emission types are appropriate or permitted, and they shape practical choices while tuning. The new system can show the selected plan in the band strip, including in the browser panel. It also feeds into related interface behavior, such as selecting a mode from the band plan and indicating when the radio is in a CW segment. In the US licence-class plans, portions unavailable to the selected class are marked in grey, with an additional “out” indication where relevant.

The automatic selection option uses available location information to choose an IARU region. It can use a GPS fix first, then the configured Maidenhead locator, then the country associated with the operator’s callsign. If none of those is available, the radio retains the region it had selected previously. That sequence makes sense for a portable radio, which may be used at different locations, while still providing a fallback for operators without GPS data or a configured locator.

Automatic selection deliberately does not choose a US licence-class plan. Knowing that a radio is in the United States does not tell the software which privileges its operator holds. A regional band plan alone cannot make that distinction, so US operators must select the country and licence class themselves. That is a useful design choice: automation can reduce setup where the necessary information is available, but it should not guess a regulatory attribute that the system cannot infer.

The regional plan also affects the radio’s band list in specific cases. In Regions 2 and 3, the 160-metre, 80-metre, 40-metre SSB and 6-metre entries can take their region’s edges on first startup after the update, provided the operator has not already edited those entries. In Region 1, existing band-list edges are not moved by this change. The difference matters because fixed frequency ranges that work for one region may not match another region’s allocations or operating conventions.

For someone operating portable, this can reduce small but consequential interface mismatches. A radio taken across a border, configured for a different region or used by an operator following a different national plan should present information that reflects that environment. The band-plan strip is not a substitute for knowing the applicable regulations, and the software cannot resolve every national variation through a single setting. It can, however, make the selected operating context more visible and help keep the tuning display aligned with it.

The project reports testing the display and band rows on a PC build and on a bench X6100 for Region 2, Region 3, US General and US Technician plans. That is meaningful evidence for the interface behavior, but it is not the same as a formal regulatory certification or an exhaustive test of every possible location and licence combination. The automatic choice from a GPS fix was not tested on a radio, according to the release notes. Those qualifications are worth keeping in mind: regional awareness is a practical software feature, but the operator remains responsible for selecting and following the correct privileges.

Winlink moves closer to an on-radio workflow

Winlink is one of the more consequential areas of the update because it connects amateur radio with store-and-forward email and messaging over radio networks. On HF, that can be useful when conventional internet access is unavailable or when an operator wants to exchange messages through a radio gateway. OpenX6X00’s Winlink workflow uses ARDOP, a digital protocol designed for radio data communications, and the new release focuses on making the connection process easier to inspect and diagnose.

The updated interface adds a “Before you connect” card that shows how Winlink is about to use the radio. A connection card explains why a connection failed and what action may help next. That moves the software beyond simply presenting a connect button: it attempts to show the conditions behind the action and make failures more understandable. For an operator troubleshooting an HF connection, that information can be more useful than a generic failure state, especially when radio setup, modem settings and gateway availability all affect the result.

The ARDOP bandwidth behavior has also been revised. The radio’s page now uses the widest ARDOP bandwidth for each connection, with 500 Hz as the default in the described configuration where the gateway list requested a 2000MAX setting. The release notes also describe preserving a password entered in the application’s own settings. These details may sound modest, but they address the kind of workflow friction that determines whether an integrated tool is dependable during a real operating session.

The connection interface is paired with changes to how the radio handles controls and logs while a digital application is open. The keyboard is unavailable in that state, and logs can be downloaded together with passwords masked. These measures reflect two different concerns: preventing awkward interactions while an application has control of the radio, and avoiding unnecessary exposure of sensitive information in exported logs. A radio that can communicate over a network needs to treat its configuration and stored data as part of the operating environment, not as incidental details.

Version 0.3.7 also adds Mercury as an experimental second modem option for Winlink. Mercury is associated with the HERMES project, and the compatibility requirement is specific: the peer must use Mercury 1.9.20 or later. The release describes selecting it in Pat using the VARA HF option, which is an operational detail users should understand before attempting a connection. Because Mercury is experimental in this release, its presence should be read as an additional capability under development, not a guarantee that every Winlink gateway or client will support it.

That qualification is important in radio networking. A modem is useful only when the other end can exchange data using a compatible protocol and configuration. A local implementation can be technically complete yet have limited practical reach if the wider network has not adopted it. The strongest immediate benefit of including Mercury may therefore be for experimentation, testing and early adopters who can coordinate with compatible endpoints. Broader usefulness depends on interoperability and deployment beyond the radio itself.

The project’s Winlink work also points to a larger design challenge. An on-radio application must make decisions that a desktop program might leave visible in separate windows: which modem is active, what bandwidth is being requested, whether the radio is ready to transmit and what happened after a failed attempt. Bringing these pieces together can simplify the station, but it also makes clarity essential. If the interface hides an important state, a compact setup can become harder to troubleshoot than a laptop-based one.

Digital modes and the portable station

OpenX6X00’s wider feature set gives context to the Winlink additions. The project supports on-radio applications for modes including FT8, FT4, FT2, JS8, WSPR, PSK31, PSK63, Olivia, RTTY, SSTV, WeFax and receive-only Navtex with DSC. The precise support varies by application and mode, but the overall idea is consistent: the radio’s Linux environment hosts software that would commonly be run on an attached computer. The v0.3.7 release builds on that foundation rather than introducing digital operation from scratch.

This can change the physical layout of a field station. A portable operator may already carry a transceiver, battery, antenna and a phone or tablet for maps or logging. Adding a laptop for every digital mode increases weight and power demand, while also adding cables and software configuration. When some of those tasks move into the radio, the station can become more self-contained. That does not make every laptop unnecessary: a larger display, familiar logging tools or specialized software may still be preferable, but the radio can handle more of the core workflow on its own.

Different modes create different operational demands. FT8 and related weak-signal modes rely on accurate timing, decoding and scheduled transmissions. WSPR is commonly used for propagation observation through low-power beacons. JS8 supports keyboard-style messaging and relay-oriented operation. Winlink addresses a different need, carrying messages through gateways. Combining these tools in the radio can make it easier to move between experimentation, contacts and practical message handling without rebuilding the station around a separate computer each time.

The display and control system are part of that experience. A waterfall can present signals in a way that makes tuning and activity easier to interpret, while a cluster can connect spots with the radio’s tuning controls. Browser-based operation can let an operator use a familiar device as a remote interface. The value lies in the relationship between these functions: a spot can inform a tuning choice, a digital application can manage a transmission, and a log can record the contact within one software environment.

Integration also concentrates complexity. A digital application needs reliable access to audio, frequency and transmit control. A browser interface must communicate with the radio without allowing an untrusted page to misuse those controls. Logging needs to preserve accurate contact data, while network services have to distinguish the radio’s intended users from unrelated clients. Each feature may appear small on its own, but combining them creates interactions that require careful design and testing.

The project’s history of incremental releases shows that challenge. Previous releases added support for the X6200, browser-based remote control, Winlink over HF and other features. The same development process has also surfaced defects in logging, TCI control, browser PTT and other areas. In v0.3.7, the maintainers say a review of v0.3.6 identified 14 defects, including issues affecting browser PTT, the configurator, TCI and the web interface. The release fixes them, illustrating that the work of an open firmware project includes both adding capabilities and correcting the ways those capabilities interact.

Security becomes part of radio operation

A radio with a web configurator, browser remote control and network services has a different security profile from a radio that exposes only physical controls. The new release adds protection against DNS rebinding, a class of attack in which a malicious website can cause a browser to treat a name controlled by that site as if it points to a device on the local network. If a browser can reach a radio’s configuration or control pages, a vulnerable design could expose settings or permit actions through a user’s browser session.

OpenX6X00 v0.3.7 restricts certain web actions to the radio’s own names, such as its local hostname or a name configured for it. The restriction applies to saving changes in the web configurator and to related pages and connections, while TCI programs can continue connecting by any name. That division reflects a practical need: browser-facing control surfaces and machine-to-machine interfaces do not always need the same naming rules. Limiting which names can perform sensitive web operations can reduce the chance that a remote page tricks the browser into interacting with the radio.

The release’s security work is tied to a broader set of audits and code reviews. The project says the v0.3.6 review found 14 defects and that those fixes are included in v0.3.7. Earlier independent audits also led to corrections in areas such as TCI control, ADIF data handling, log editing and browser session behavior. These are not merely cosmetic issues. A bug in transmit control can affect whether a radio keys or unkeys correctly, while a defect in data handling can corrupt logs or cause unstable behavior.

The attention to browser PTT is especially relevant because remote control changes the meaning of a push-to-talk button. A local front-panel switch is physically associated with the operator and the radio. A browser control depends on a network connection and software state. If a link stalls and returns, the interface must not unexpectedly key the transmitter based on stale input. The release notes describe fixing a case where a held browser PTT control could key the radio again after a stalled link recovered. This is the kind of edge case that a well-designed interface has to handle explicitly.

Security also affects how remote access features are exposed. OpenX6X00 can use Tailscale for remote operation, and v0.3.7 adds support for Tailscale Funnel to make certain browser pages available from outside the local network. The release distinguishes the Panel and Screen pages from other services such as the configurator, TCI programs and Winlink applications. That distinction matters because “remote access” is not one uniform permission: a live control panel, a configuration interface and a network service expose different capabilities and carry different risks.

The Funnel feature is described with specific boundaries. Pairing must occur before using the remote link, and a browser paired at home can be given a separate link for use away from home. The public service is limited to the Panel and Screen pages and their related sockets, with a limit on simultaneous remote browsers. Other services remain unavailable through Funnel. The feature was tested against a stand-in for the Tailscale daemon and on a PC build, rather than on a real tailnet and radio, so the maintainers explicitly invite reports from users who test it in that environment.

These details make the feature more than a convenience toggle. Publishing a service on the internet changes who can attempt to reach it and what kind of authentication is needed. OpenX6X00’s approach separates the remote browser’s access from the radio’s other services and requires prior pairing. The project also warns that the public hostname becomes visible in certificate logs. Operators who do not need remote browser access can leave Funnel disabled, while those who use it should understand which pages become reachable and which do not.

Power limits, maintenance and what v0.3.7 signals

The X6200’s transmit power behavior is another operationally significant change. In v0.3.7, the interface limits the selected power to 8 W, and to 5 W when the radio is running on battery. A software limit can be a useful guardrail, especially in a portable station where power supply conditions change, but it should not be confused with a general statement about the radio’s maximum capability. It is a limit imposed by this firmware’s control behavior and may affect how users configure the radio for different power sources.

The release also corrects a number of smaller behaviors. It changes the X6100’s default monitor level to zero, matching the X6200 behavior, while preserving a level that the operator has already set. It makes tuning one VFO across a band edge leave the other VFO where it was. It also addresses defects in browser control, TCI, Wavelog-related forms and the configurator. Each adjustment contributes to a more predictable operating experience, even when it does not add a headline feature.

Updating is designed to work from the radio for users already running OpenX6X00. The release notes say an X6100 or X6200 on a supported v0.2.x or v0.3.x installation can receive the update through the radio’s own update function. New card images are available for first installations and for radios that cannot boot far enough to update. Some older card images require replacement to obtain earlier bootloader or Wi-Fi driver changes, but those are model- and version-specific requirements rather than a need for every user to reflash for v0.3.7.

This separation between an update bundle and a card image is a practical advantage of the project’s architecture. Applications and web pages can be updated without rewriting the entire system image when the underlying kernel, drivers and boot components have not changed. The project says the v0.3.7 release did not require a new card image for radios already on the appropriate earlier images. It also preserves settings and logs on the card’s data partition, while recommending a backup before updating. Keeping the operating system layer and application layer distinct can make maintenance less disruptive, though it still requires users to understand when a full image is necessary.

Rollback is another important part of the update model. The radio keeps the previous version available for automatic rollback if a new installation fails to start successfully. That does not eliminate the value of backing up configuration and logs, nor does it make every update risk-free. It does provide a recovery mechanism that is particularly useful in an embedded device, where an update failure could otherwise require a more involved card-writing procedure.

The project is also revealing a broader trend in amateur radio equipment. SDR transceivers increasingly contain general-purpose computing hardware, networking and software-defined interfaces. That makes it possible to add capabilities after a radio has been sold, but it also makes the quality of software maintenance part of the product’s everyday value. Band-plan logic, modem interoperability, browser security, logging integrity and power control are all software concerns that affect actual operating. Open development gives users visibility into those changes and a way to report problems, while placing responsibility on maintainers to keep a growing system coherent.

OpenX6X00 v0.3.7 therefore matters beyond its list of release notes. Its regional band plans make the interface more adaptable to operators in different parts of the world. Its Winlink changes aim to make connections more understandable, and Mercury adds an experimental path for compatible stations to explore. The security fixes and audit work show how remote operation turns browser behavior into a radio engineering concern. Taken together, the release presents the X6100 and X6200 as platforms where firmware can shape how a transceiver is operated, networked and maintained long after its hardware design is fixed.

Image(s) used in this article are either AI-generated or sourced from royalty-free platforms like Pixabay or Pexels.

This article may contain affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you.