Introduction

This page records the development of DXLab — Thetis Bridge, an integration tool that allows DX cluster spots aggregated by the DXLab Suite to be displayed live on the panadapter of the Thetis SDR software — used by ANAN and other ExpertSDR-family transceivers.

The work spans the original conception, multiple prototype iterations in Python, a full rewrite to C# for production deployment, and a focused two-week reverse-engineering effort to extend the integration with full QSL-status colour information.

Bridge is published under the MIT licence and is endorsed and listed by the DXLab Suite. It is in active use by amateur radio operators worldwide who run an ANAN or ExpertSDR transceiver with the DXLab logging suite.

Why Bridge exists

Two software ecosystems coexist in modern amateur radio operating that don’t natively talk to each other:

• DXLab Suite — Commander, SpotCollector, DXKeeper, DXView — a comprehensive logging, spotting, and station-management toolkit, mature and feature-rich, but designed primarily for traditional CAT-controlled transceivers.
• Thetis — the open-source SDR console used by ANAN transceivers and other ExpertSDR-compatible hardware. Thetis has a powerful panadapter with rich graphical spot-rendering capabilities, and exposes a modern WebSocket-based control interface (TCI) for third-party integration.

Until Bridge, an operator using both — and many do, since Thetis offers panadapter visualisation that contest-grade logging needs, while DXLab provides best-in-class spot aggregation and QSL tracking — could not see DXLab’s curated spots painted on Thetis’s panadapter. The two systems ran in parallel without sharing the most operationally valuable visual layer.

Bridge’s purpose is to close that gap: take the spots that SpotCollector has carefully coloured according to need-status and QSL confirmation, and paint them on Thetis’s panadapter in real time, with the full colour information preserved.

Phase 1 — Python prototype

Initial development was in Python, optimised for fast iteration and easy reverse-engineering of DXLab’s wire protocols. The Python prototype validated the feasibility of consuming Commander’s UDP spot stream, performing the local DXView background-colour lookup, and forwarding spots to Thetis via TCI.

Key engineering decisions made during this phase:

• Tk-based GUI with separate config and debug windows
• ODBC connection to DXView’s .mdb for the LoTW/eQSL lookup tables
• WebSocket client implementation for TCI delivery
• Colour mapping from DXLab’s foreground+background two-channel encoding to TCI’s single ARGB colour argument
• Configuration persistence via JSON file

Phase 2 — C# rewrite

Once the Python prototype was stable and the protocols understood, Bridge was rewritten in C# (WPF) for production deployment. Reasons for the rewrite:

• Distribution as a single MSI installer with no Python runtime dependency
• Better integration with Windows-native UI conventions — tab dialogs, system tray, modal config windows
• Improved performance under sustained load — 500+ spots per minute during contests
• Easier code-signing for users who require it

The C# version preserved the architecture and feature set of the Python prototype while being more maintainable as the public release. It is the version published on GitHub and listed by the DXLab Suite.

On AI-assisted development

This entire codebase — both the Python prototype and the C# production version — was written with substantial AI assistance. The author is a domain expert in amateur radio, DXLab operation, and SDR — but not a professional programmer.

The collaboration model that produced Bridge:

• The author defined goals, captured evidence, and validated correctness — the irreducibly human roles where domain expertise matters most
• AI implemented code, refactored, and suggested fixes — based on clear specifications and direct evidence from debug logs, packet captures, and error messages
• Iteration was tight — typically a single round-trip per feature: specify, implement, deploy, observe, refine
• Evidence was the final authority — every claim about protocol behaviour was grounded in actual log output, not assumptions

The artifact that emerged is a working tool that contributes meaningfully to the amateur radio community. Its quality is not diminished by the development methodology — if anything, the rigour required to specify behaviour precisely enough for AI implementation forced clearer thinking about the protocol than ad-hoc development would have.

Acknowledgements