Feature Request - Mercury/OFDM mode

[craigerl]

https://github.com/Rhizomatica/mercury

OFDM open source is now reality, so we're promoting this as a VARA work-alike for Winlink servers and clients. This will likely be the year of OFDM (orthoganaly frequency division), so it'd be great to see Pat support!

thank you,
-craig
KM6LYW
digipi.org

[martinhpedersen]

Thanks for the suggestion. I will definitely check this out 🤩

[craigerl]

https://github.com/Rhizomatica/mercury (easy build/install)

It acts like a VARAHF modem, so pat technically already supports it,

$ pat --listen=varahf http

pi@digipi7:~ $ pat --listen=varahf http
2026/06/10 18:03:02 Listening for incoming traffic on varahf...
2026/06/10 18:03:02 Starting HTTP service (http://0.0.0.0:8080)...
2026/06/10 18:03:02 VARA modem () initialized

$ mercury

Loaded configuration from mercury.ini
Audio System: Advanced Linux Sound Architecture (ALSA)
18:00:17.095 [+0.000s] [INF] [main] Async logger initialized (min_level=INFO)
18:00:17.095 [+0.000s] [INF] [main] Initializing I/O from Sound Card
18:00:17.096 [+0.000s] [INF] [radio-io] Initializing radio (type=3073, device=/dev/ttyUSB0, hamlib_log_level=0, serial_speed=19200)
18:00:17.122 [+0.026s] [INF] [audio-play] I/O playback (plughw:0,0) int32 / 48000Hz / 2ch / 30ms buffer
18:00:17.124 [+0.029s] [INF] [audio-cap] I/O capture (plughw:0,0) int32 / 48000Hz / 2ch / 30ms buffer
18:00:17.128 [+0.033s] [INF] [radio-io] Serial speed overridden to 19200 baud
18:00:17.446 [+0.350s] [INF] [radio-io] Radio control: HAMLIB (model 3073, device /dev/ttyUSB0)
18:00:17.446 [+0.350s] [INF] [main] Initializing Modem
18:00:17.446 [+0.350s] [INF] [modem] Created data buffers for ARQ and BROADCAST datalink, tx/rx paths.
18:00:17.452 [+0.357s] [INF] [modem] Initialized persistent FreeDV mode pool (DATAC13/DATAC4/DATAC3/DATAC1), frames per burst: 1
18:00:17.452 [+0.357s] [INF] [modem] Active FreeDV mode at startup: 12 (DATAC3), verbosity: 0
18:00:17.452 [+0.357s] [INF] [modem] Modem expects sample rate: 8000 Hz
18:00:17.452 [+0.357s] [INF] [modem] Modem payload bytes per frame: 126
18:00:17.452 [+0.357s] [INF] [modem] Split control/data mode switching: ENABLED
18:00:17.453 [+0.357s] [INF] [arq-bus] Initialized channel bus
18:00:17.453 [+0.357s] [INF] [arq] Event loop started
18:00:17.453 [+0.357s] [INF] [arq] ARQ initialized (frame=126 mode=12)
18:00:17.453 [+0.357s] [INF] [bcast] Starting broadcast system...
18:00:17.453 [+0.357s] [INF] [bcast] Broadcast frame alignment OK (FreeDV mode 12, hermes mode 1): 126 bytes.
18:00:17.453 [+0.357s] [INF] [main] Initializing TCP interfaces with base port 8300 and broadcast port 8100
18:00:17.453 [+0.358s] [INF] [main] Initializing UI communication (WebSocket port 10000 | TLS WS | Waterfall enabled)
18:00:17.453 [+0.358s] [INF] [tcp-ctl] Listening on TCP port 8300
18:00:17.453 [+0.358s] [INF] [tcp-data] Listening on TCP port 8301
18:00:17.453 [+0.358s] [INF] [websocket] Initialized (url=ws://0.0.0.0:10000)
18:00:17.453 [+0.358s] [INF] [ui-comm] WebSocket server ready on port 10000
18:00:17.453 [+0.358s] [INF] [ui-comm] Publisher thread started
18:00:17.453 [+0.358s] [INF] [ui-comm] Publisher started - sending status every 500ms via WebSocket (port 10000)
18:00:17.454 [+0.358s] [INF] [tcp-bcast] Waiting for a client to connect...
18:00:17.454 [+0.358s] [INF] [ui-comm] Spectrum publisher started - sending spectrum every 50 ms via WebSocket
18:00:17.454 [+0.358s] [INF] [ui-comm] Spectrum publisher thread started
18:00:17.457 [+0.361s] [INF] [websocket] Server listening on ws://0.0.0.0:10000
18:00:17.958 [+0.863s] [INF] [modem-rx] Spectrum FFT active: nin=512 sr=8000 dB[0]=-41.9
18:00:20.336 [+3.240s] [INF] [websocket] Client connected (conn 0xeb9f80)
18:00:47.783 [+30.687s] [INF] [websocket] Client disconnected (conn 0xeb9f80, draining=1)
0000   16 03 01 02 00 01 00 01 fc 03 03 13 ed a2 64 b4   ..............d.
0000   16 03 01 02 00 01 00 01 fc 03 03 76 2e 3f 9e 6e   ...........v.?.n
18:00:53.835 [+36.739s] [INF] [websocket] Client connected (conn 0xeb9f80)
18:03:02.538 [+165.443s] [INF] [tcp-ctl] Control client connected
18:03:02.540 [+165.445s] [INF] [tcp-data] Data client connected
18:03:02.541 [+165.446s] [INF] [tcp-ctl] Command received: PUBLIC ON
18:03:02.543 [+165.447s] [INF] [tcp-ctl] Command received: CWID ON
18:03:02.544 [+165.448s] [WRN] [tcp-ctl] Unknown command: CWID ON
18:03:02.545 [+165.449s] [INF] [tcp-ctl] Command received: COMPRESSION TEXT
18:03:02.545 [+165.449s] [INF] [tcp-ctl] Command received: MYCALL KM6LYW
18:03:02.546 [+165.450s] [INF] [arq] My callsign: KM6LYW
18:03:02.546 [+165.450s] [INF] [tcp-ctl] Command received: LISTEN OFF
18:03:02.546 [+165.450s] [INF] [tcp-ctl] Command received: VERSION
18:03:02.546 [+165.450s] [INF] [tcp-ctl] Command received: BW2300
18:03:02.546 [+165.451s] [INF] [tcp-ctl] Command received: LISTEN ON

$ cat mercury.ini

[main]                                                                                                          
ui_enabled = true                                                                                               
ui_port = 10000                                                                                                 
ui_protocol = ws                                                                                                
waterfall_enabled = true                                                                                        
radio_model = 3073                                                                                              
radio_device = "/dev/ttyUSB0"                                                                                   
input_device = "plughw:0,0"                                                                                     
output_device = "plughw:0,0"                                                                                    
capture_channel = left                                                                                          
sound_system = alsa                                                                                             
arq_tcp_base_port = 8300                                                                                        
broadcast_tcp_port = 8100
verbose = false
freedv_verbosity = 0
hamlib_log_level = 0
radio_serial_speed = 19200

[arq]
no_progress_timeout_s = 180
disconnect_drain_timeout_s = 30

[audio]
tx_gain_db = -1.00

[craigerl]

[craigerl]

Great Success! Pat using MERCURY transport on HF,

https://www.youtube.com/watch?v=JkU0f3BeJcE

TNC commands (same api as varahf),

https://github.com/Rhizomatica/mercury/blob/mercuryv2/docs/TNC.md

[martinhpedersen]

Cool 🤩

Is the VARA Host Protocol the recommended interface method, or should we start planning for a new transport driver?

[craigerl]

Cool 🤩

Is the VARA Host Protocol the recommended interface method, or should we start planning for a new transport driver?

We might ask the Mercury guys. Pat sends some "unknown commands" but they're ultimately of no consequence. I think we should have a separate transport driver. You can see the TNC commands in the TNC link above.

I'm here to test. In fact, I'll probably be the guy that writes a linuxrms-mercury server at some point.

[mwthomson]

I'm a little biased, but I view Mercury as a separate implementation of OFDM completely and, thus, it should have its own transport driver.

[craigerl]

Mercury is quickly gaining traction, still experimental, but it's on par with VARA, works on Linux, Raspberry Pi, everything. It's certainly better than ardop.

Using Pat's VARAHF api to drive MERCURY is still a bit awkward as there's no CAT/frequency control.

Live pat/MERCURY demo:

https://www.youtube.com/watch?v=SDeZhU51sz4

The TNC commands are almost identical to VARAHF, so hopefully it's mostly cut-n-paste to add the MERCURY transport:

https://github.com/Rhizomatica/mercury/blob/mercuryv2/docs/TNC.md

I'm not a Gopher so I'm not sure I'm much help, but I can certainly test!

thanks,
-craig
KM6LYW
https://digipi.org/

[mwthomson]

We've got a couple of options if we decide to implement a new transport driver:

1. Extend Pat-Vara with another scheme ("mercury")
2. Create a new transport in la5nta/wl2k-go, mirroring where Ardop/AX.25/AGWPE/Telnet already live, which matches precedent and means no external maintainer risk
3. Build entirely inside la5nta/pat (like in internal/mercury)

This is your call @martinhpedersen.

I've already started looking at the implementation and I'm happy to dig in further.

[mwthomson]

One question I can't find the answer for: For RMS listing auto-discovery, does CMS advertise Mercury gateways? Pat doesn't control that, so connecting means either knowing the gateway in advance or requesting changes to CMS to advertise mercury gateways. Which comes first?

My take: we push forward with implementation with the caveat that gateways will have to be known before connecting, since they won't show up in the RMS list.

[martinhpedersen]

Cool 🤩

Is the VARA Host Protocol the recommended interface method, or should we start planning for a new transport driver?

Have we found an answer to this?

[martinhpedersen]

One question I can't find the answer for: For RMS listing auto-discovery, does CMS advertise Mercury gateways?

It would be very interesting to know if the Winlink Development Team are adding support for Mercury in their RMS software (and Winlink Express).

[mwthomson]

Cool 🤩
Is the VARA Host Protocol the recommended interface method, or should we start planning for a new transport driver?

Have we found an answer to this?

Yes, the answer is that we create a new Mercury transport driver. Mercury and VARA are siblings, not the same beast though. Mercury has, and will continue to develop, features not in VARA. It should be treated as a first class citizen of Pat. It just needs to be decided where it lives. (see my earlier post)