The Operating
Skills

Contents

Skills at a Glance

Three skills, one operating system. Each in one view — what it governs, and what you get. One full page per skill inside.

Installing the Skills

Each skill ships inside its MCP package — install the server, and the skill travels with it. Nothing is configured separately.

In Claude Desktop .mcpb bundle — recommended

In Claude Code / Cowork

Verify thirty seconds

Your First Session — Claude for Hams

You do not need to know anything about AI to run this station. If you can install fldigi and type a sentence, you can operate. This chapter is the whole learning curve.

What you're actually installing

Claude is an assistant made by Anthropic. It runs in an ordinary desktop program — the Claude Desktop app (Windows or Mac), which looks like a messaging window: you type at the bottom, answers appear above. The two MCP servers in this project are best thought of as rig-interface cables: one plugs Claude into fldigi, the other into N3FJP. You type plain English; Claude works the programs. Nothing about your fldigi or N3FJP setup changes — they run exactly as they always have.

Setup, once

Operating is a conversation

There are no commands to memorize and no syntax to get wrong. You type what you would tell a competent operator sitting at your rig:

How the System Works

A QSO is a loop with four states. fldigi-operating governs the radio in every state; contest-operating decides what to say and when to log.

• Skills trigger on plain language. No commands to memorize. Say “call CQ until someone answers, then work them and log it” and both skills engage. You can also ask for a skill by name when you want a specific lens.
• The radio layer runs first because it changes everything above it. An over that doesn't drop PTT on time transmits idle carrier on top of the answering station — no exchange strategy survives that. The ^r handoff is not optional.
• The two skills chain deliberately. fldigi-operating delivers clean overs and an honestly-read RX stream; contest-operating consumes that stream, runs the exchange, and hands a confirmed QSO to the logger. Findings that die on a garbled callsign become an AGN request instead of a log entry.
• The operator stays in command. Say “stop” at any time — transmit → abort drops PTT immediately and discards queued text. The callsign gate means an unconfigured station cannot transmit at all.

The Operating Standard

Six rules, inherited by both skills. Every one of them exists because we broke it once — on the air, at Field Day 2026.

fldigi-operating

Governs the radio: transmit, hand off to receive, listen properly.

Transmitting an over

transmit → send "<over text>\n"   (return_to_rx=true, the default)

One call: clears the TX buffer, appends ^r, keys the radio. End messages with a real newline (\n) — the two-character string ^n transmits literally. If building an over incrementally with text → add_tx, the last fragment must end in ^r, with nothing added after it.

Listening

• Delta reads only. text → rx_length for the end position, then text → read from your last position. Save the new position.
• Restart detection. rx_length smaller than your last position means fldigi restarted — re-baseline and continue.
• Listen window. After get_trx_status returns "rx", listen ~10 seconds (1–2 polls) before the next CQ. PSK31 operators type slowly.
• Validate callsigns against [A-Z0-9]{1,3}[0-9][A-Z]{1,3} before any directed reply — QRM garbage looks call-ish.

loop:
  transmit → send "CQ CQ de <MYCALL> <MYCALL> pse k\n"
  poll controls → get_trx_status until "rx"
  listen ~10 s  (1–2 polls of text → rx_length)
  if plausible callsign in new RX text → work the station
  else → loop

contest-operating

Governs the contest: what to say in each state, when a QSO is real, and when it goes in the log.

The exchange, tuned on the air

• Double everything important. 2A 2A STX STX copies far better than 2A STX through QSB and QRM.
• Echo their exchange back in the TU (QSL 1D AZ TU W7XYZ …) — the other station verifies you logged them correctly before you QRZ.
• Callsign-only callers are normal. Some operators send just their call and wait. Send your exchange; theirs arrives in the next over. Others send everything up front — then you go straight to TU after your exchange.
• Log while the TU is still transmitting. The radio is busy ~15 seconds — exactly the time logging takes. When TX drops you are ready to CQ.

Logging in one call

log → log_qso  {"call": "W7XYZ", "contest": "field_day",
                "exchange": {"class": "1D", "section": "AZ"}}

Exchange fields go in the exchange dict — they are not top-level parameters. Success is logged: true in the response; chapter G has the full protocol and its quirks.

signal-hunting

Finds a station worth working the way an operator reads the waterfall: name what is there, rank the one that sits still and calls CQ, tune to it, confirm in twenty seconds.

What the tool sees

fldigi's XML-RPC exposes no spectrum, so signal_hunt taps the audio fldigi is listening to (the Audio input device setting names it) and returns ranked candidates. It needs the optional extra fldigi-mcp[hunt], numpy and sounddevice. Each candidate is where the cursor goes, what modem to run, and why it ranks where it does.

With the Signal Browser patch proposed, not yet in fldigi

fldigi's own Signal Browser, the left-hand panel, is a bank of thirty demodulators with DCD; it copies PSK, RTTY and CW stations too faint for any spectrum to rank. On a build that carries the patch, browser channels or signal_hunt method="browser" returns every channel with its carrier and the text already copied, line breaks kept: the confirm step is done before you tune. Four synthetic PSK31 stations from 0 to −26 dB: all four copied in full. The browser names no mode; hunt the audio first when the band's mode is unknown. Building it yourself is three lines, in the README.

Letting the station name its own mode proposed, not yet in fldigi

Naming a mode from its shape is guesswork for the hopping modes: Olivia and Contestia share a grid, so do THOR and DominoEX. Most operators on those modes send an RSID burst at the start of an over, and fldigi's detector hears it across the whole passband. Set RxID to notify only and the detector reports the mode without switching the modem, so the pass you are running keeps its browser. rsid hits then gives {utc, mode, hz} for every burst: the mode name is exactly what tune_to takes, and the frequency is where the cursor goes. Ask the band before you guess at it, especially when the analyser says unknown on a strong signal.

How a mode is named

From the signal's shape, the way you would from the waterfall, with the numbers checked against the Signal Identification Wiki. Two narrow lines a standard shift apart (170 Hz in amateur use) is RTTY, carrier at the midpoint. One 30 Hz line is PSK31, unless it is keyed on and off with gaps of 40 ms or more, which makes it CW. The hopping modes show as a grid of discrete dots when you look at where the energy is from one 30 ms frame to the next: Olivia, with tones = bandwidth / spacing; MFSK16, 16 tones at 15.6 Hz; DominoEX and THOR, 18 tones. MT63 is a flat continuous block. Contestia looks like Olivia and THOR like DominoEX; only RSID separates those.

The loop

signal_hunt seconds=20 (contest: mode="RTTY", seconds=40)
read candidates highest score first
tune_to carrier_hz, fldigi_modem   (RxID off during a classified pass)
wait 20 s, then text → read
if CQ and a callsign-shaped token, twice → hand to fldigi-operating
elif modem → get_quality below 30 → next candidate
else a QSO in progress → wait for SK or 73

The Special-Case Playbook

All seven encountered live at Field Day 2026 — none of them hypothetical.

Worked Examples from Field Day

Three real QSOs from the session log, 14.070 MHz BPSK31 — transcribed as decoded, garble included. All callsigns are anonymized (ARRL-style sample calls) out of respect for the stations worked; the exchanges, flow, and garble are verbatim.

Logging to N3FJP

The verified protocol, and every quirk we hit on the air.

Preferred: one call

log → log_qso  {"call": "W7XYZ", "contest": "field_day",
                "exchange": {"class": "1D", "section": "AZ"}}

Manual alternative

log → set_many  {"CALL": "W7XYZ", "CLASS": "1D", "SECTION": "AZ"}
log → enter

Quirks, observed live

• set_many → calltab can trigger an ENTEREVENT directly (the band/mode/dupe check fires on callsign entry). If it does, the QSO is logged — do not send another enter.
• calltab also populates COUNTRY/STATE/section lookups — useful for checking that the section you copied is plausible for the callsign.
• A CALLTABDUPEEVENT means the call is already in the log for this band/mode — usually a sign you (or a retry) already logged it.
• Exchange fields belong in the exchange dict of log_qso — passing them as top-level parameters silently logs nothing.

About & Provenance

These skills were not designed on paper. They are the distillate of one real autonomous contest session.

At ARRL Field Day 2026, a class-2A club station ran 20-meter BPSK31 with an agent operating fldigi and N3FJP through fldigi-mcp and n3fjp-mcp — calling CQ, working callers, and logging contacts, with the human operator supervising and able to stop transmission at any moment. Every rule, timing, and special case in this guide comes from that session's after-action report, n3fjp-mcp/docs/LESSONS-FIELD-DAY-2026.md.

Corrections and additions are welcome — open an issue on either repository.