Unverified Writes

Unverified Writes

Open Rig Programmer talks to many radios it has never been connected to. This page explains what "unverified" means, what switching writes on for one of those radios actually does, and how to switch it on and off. See the README's Switching on writes for an unverified radio section for the step-by-step version.

What "verified" means here

The README is direct about this, in its own words:

This started as a programmer for my own FT-710, and the FT-710 is still the only radio it has ever been connected to. Reading and writing there are verified on the real thing.

Many other radios have been added since, built from the makers' own published protocol manuals and tested against simulators. Reading them is safe. Writing stays switched off until you switch it on for that radio, and every write is previewed, snapshotted and read back.

So "verified" means proven on a real FT-710. Every other supported radio's write support is built from the manufacturer's own protocol manual and exercised against a simulator, not against real hardware — which is why writing to those radios is switched off until you opt in.

What opting in does — and doesn't — promise

The dialogue you see when opting in shows the application's own warning text, defined once in internal/radiotext/radiotext.go as UnverifiedWriteWarningTemplate (%s is the model name):

This project has never written to a real %s. Enabling unverified writes sends memory-write commands that are documented in the manufacturer's CAT reference and exercised against a simulator, but have not been proven on real hardware. Every write is read back and compared, and stops on any mismatch — but a misinterpreted frame could corrupt the targeted memory channel. You can revoke this at any time.

That's the whole promise: the write commands come from the manufacturer's own documentation and have been run against a simulator, every write is read back and compared and stops on a mismatch, and you can revoke consent at any time. It does not promise the commands have been proven correct on real hardware, and it says plainly that a misinterpreted frame could corrupt the memory channel it's writing to.

Mechanically, opting in only changes what the programme is allowed to send — it doesn't change how carefully it sends it. app/consent.go's SetUnverifiedWriteConsent records your decision (on or off) in the shared settings store and refuses to record anything for a model that's hardware-verified, since there's no unverified write there to unlock. A decision taken while already connected doesn't arm the running session — consent is read when a session is opened, so a change applies from the next connection onwards.

Switching it on and off in the desktop app

The app asks once, the first time you connect to a consent-eligible radio with no decision recorded yet. That prompt (UnverifiedWritesDialog.svelte, "arm" mode) shows the warning text above and offers two buttons — Not now and Enable unverified writes — and both record a decision, so you're never asked again for that radio; a decline is remembered too.

The Unverified writes… button opens the same dialogue's "manage" mode at any time: a list of every radio this build supports, each with its current state (Never asked, Not enabled, Enabled, or n/a — this radio's writes are hardware-verified for the FT-710), a toggle per radio, and an All radios toggle to grant or revoke every eligible model in one go. Toggling a radio you're currently connected to can require a reconnect; if that fails, the dialogue stays open and shows why, and nothing is changed. The manage panel also links to the project's GitHub issues, inviting a report if you do try an opt-in radio.

Switching it on and off from the command line

rigprog settings unverified-writes is the CLI equivalent, documented in cmd/rigprog/usage.go:

rigprog settings unverified-writes
rigprog settings unverified-writes <model> on|off

With no further arguments it lists every model this build supports — slug and current state. With <model> on|off it records a decision and reports it, for example:

rigprog settings unverified-writes IC-7610 on     # allow writes to the IC-7610

This sub-mode opens no radio session — --port/--fake aren't accepted. A model whose writes are hardware-verified (the FT-710) is listed as n/a (hardware-verified), and a grant or revoke for it is refused as a usage error rather than recorded. An "off" is stored, not discarded, so withholding consent is remembered and you aren't asked again.

Consent is per radio model

Both the desktop app and the CLI record and check consent per model, not as one global switch. app/consent.go's GetUnverifiedWriteConsent and ListUnverifiedWriteConsents read the decision for one model, or every model this build supports, from the shared settings store; SetUnverifiedWriteConsent(model, on) writes a decision for that one model only. Opting in to unverified writes for one radio — the IC-7610, say — has no effect on any other opt-in radio; each is asked, granted and revoked separately, and the desktop app's All radios toggle is just a shortcut for doing that one model at a time.

See also

• Command-Line — full rigprog command reference, including settings unverified-writes
• Reading-and-Writing — the read/preview/write/verify flow this consent gates
• The-Grid — editing channels before you send them
• CSV-and-CHIRP — importing and exporting codeplugs offline

As of v1.9.0 (commit bec7df97).