Reporting a Test

Reporting a Test

Many radios in Open Rig Programmer have been built from the makers' own published protocol manuals and tested against simulators, but never connected to a real one — only the FT-710 has. Reading is safe on every supported radio: the programme only sends the maker's documented read commands. Writing stays switched off until you switch it on for that radio, and even then every send is previewed, snapshotted and read back. If you own one of the opt-in radios, please try it and say how it went — a report from a real radio is the most useful thing anyone can send.

Start at the new issue chooser and pick the template that fits.

"I own one of the unverified radios and can test it"

Fields, in the order the template asks for them:

1. Radio — a dropdown of the opt-in radios, plus "FT-710 on Linux" and "FT-710 on Windows amd64" (the two platform gaps for the verified radio).
2. Firmware version — as shown on the radio.
3. Computer — macOS, Windows or Linux.
4. Connection — how it's wired: USB cable straight to the radio, a CI-V interface, a USB-serial adapter…
5. What you are willing to try — checkboxes: read the memories and report whether the channels look right; switch on unverified writes and send one edited channel with the read-back result; or send the output of rigprog probe, plus a redacted excerpt from a rigprog read. read always saves every slot — there's no single-channel option — so read privately, then copy out just one occupied channel's line from the saved file and redact the callsign to MYCALL, per docs/fixtures.md.
6. Anything else — which serial port answered, how the radio is set up (CI-V address, baud rate, menu settings), and anything the programme said that surprised you.

"Bug report"

Fields, in the order the template asks for them:

1. Radio — a dropdown of the supported radios, plus Demo (simulated radio) or Not radio-specific.
2. Platform — macOS, Windows, Linux (.deb), or Linux (tarball or built from source).
3. Version — the output of rigprog version, or the version shown in the app's status bar.
4. What happened — what you did, what you expected, and what happened instead; paste any refusal text as shown.
5. Command output or screenshot — for the command line, the exact command and its output; for the app, a screenshot of the preview or error.

The template itself asks you to omit the whole memory file: it carries your callsign and your channel list. One channel's line is plenty.

What rigprog probe and rigprog version give you

rigprog probe --port <path> (or --fake for the demo radio) opens a session and prints the radio's model, CAT ID, port, USB serial, region, and 60 m/EMG inventory. rigprog version prints the release version on its first line and the build's Go toolchain and platform on its second; an unstamped build reports dev and says so — quote that line verbatim in a bug report rather than guessing which release you have.

What a finished record looks like, and what to leave out

docs/hardware-notes.md is the shape a finished evidence record takes, once redacted. docs/fixtures.md is the redaction policy behind it: "Raw radio backups and serial protocol transcripts captured from a real radio contain personal data: the owner's callsign, and whatever frequencies, memory labels and channel contents happen to be programmed into that radio at capture time. This data must not end up in a public git history." Don't post those raw captures — blank callsigns and trim to one channel's line, as the issue templates ask.

If you switch on writes for a radio that hasn't been verified yet, see Unverified Writes first.

As of v1.9.0 (commit bec7df97).