Open Rig Programmer v1.3.0

Open Rig Programmer v1.3.0: a free memory-channel programmer for
Yaesu and Icom radios. Read the memories into a file, edit them in a
grid or a spreadsheet, send them back over the radio's ordinary USB
cable. Desktop app and rigprog command line for macOS, Windows and
Linux.

Which radios are supported, and how far each has been tested, is in
docs/radio-notes.md.
Only the FT-710 has ever been connected to this program; every other
radio's writes stay switched off until you switch them on for that
radio, as the
README
describes under Switching on writes for an unverified radio.

What changed in this version

• Windows. An installer (app + command line) and a command-line zip,
  each for amd64 and ARM64, built on a Windows host by the release
  pipeline. Installed and driven end to end on a Windows 11 ARM64
  virtual machine with a real FT-710 attached (05/09/2026): driver,
  serial ports, app, command line, two writes and a byte-identical
  restore. The amd64 app has never been launched by anyone, and no
  physical Windows PC of either architecture has been tried.
• The Yaesu FT-891 is now supported, for reading and for opt-in
  writes, on the same terms as every other manual-derived model. Its
  menu addresses are four digits where the other Yaesu radios use six,
  and files accept either. Its CAT speed is a guess (38400; menu 0506 on
  the radio is the only remedy), its USB socket presents two serial
  ports and the manual does not say which carries CAT, and the manual
  contradicts itself about whether a memory channel may be read at all,
  so a refused read of a channel plainly in use is reported as what it
  is. A CHIRP file's CW, CWR and RTTY rows are not imported on
  this radio.
• The serial port is opened with RTS and DTR requested low on every
  platform, so a radio wired for RTS/DTR keying is never keyed by the
  act of connecting.
• CSV import tolerates a UTF-8 byte-order mark and CRLF line endings,
  as saved by Windows spreadsheets.
• An unanswered Icom field can no longer slip past the send gate by
  being saved and reloaded, or by a round trip through CSV. IC-7610,
  IC-7760 and IC-7851 refuse a frequency the record cannot hold at read
  time, with the value and the limit.
• Every Icom tier column has an editor in the grid, chosen by the
  field's kind, and the connection bar says when the radio is a
  receiver.
• The application has an icon of its own on all three platforms.
• The README is rewritten for radio owners; per-radio limits live in
  docs/radio-notes.md; a CHANGELOG.md lists every release.

Everything else is internal and carries no change a user can see. The
stored comparison output of every previously registered radio is
unchanged apart from the lists of supported models, which gain the
FT-891.

Downloads

Platform	What it is	File
macOS (Intel + Apple Silicon, universal)	App (.app, zipped)	open-rig-programmer-v1.3.0-darwin-universal.app.zip
macOS (Intel + Apple Silicon, universal)	Command line	rigprog-v1.3.0-darwin-universal.tar.gz
Windows amd64	App + command line (installer)	open-rig-programmer-v1.3.0-windows-amd64-installer.exe
Windows arm64	App + command line (installer)	open-rig-programmer-v1.3.0-windows-arm64-installer.exe
Windows amd64	Command line only (zip)	rigprog-v1.3.0-windows-amd64.zip
Windows arm64	Command line only (zip)	rigprog-v1.3.0-windows-arm64.zip
Linux amd64 (Debian, Ubuntu, Mint)	App + command line (.deb)	open-rig-programmer_1.3.0_amd64.deb
Linux arm64 (Debian, Ubuntu, Mint)	App + command line (.deb)	open-rig-programmer_1.3.0_arm64.deb
Linux amd64	Command line	rigprog-v1.3.0-linux-amd64.tar.gz
Linux arm64	Command line	rigprog-v1.3.0-linux-arm64.tar.gz

The Windows installers are native-only: the amd64 installer refuses to
run on an ARM64 PC even though ARM64 Windows can emulate x64 programs.
The Debian package installs the app, the command line, a desktop entry
and the ModemManager udev rule; sudo apt install ./<file> resolves
its GTK and WebKit dependencies (built and tested on Ubuntu 24.04;
Ubuntu 22.04, Debian 12 and the Mint releases built from them carry the
same packages but have not been tried). On other distributions take
the command-line tarball, a single static binary.

SHA256SUMS covers every file above. Verify with:

sha256sum -c SHA256SUMS --ignore-missing     # Linux
shasum -a 256 -c SHA256SUMS --ignore-missing # macOS
certutil -hashfile <file> SHA256             # Windows, one file at a time

First launch

• macOS: the app is only ad-hoc signed, so Gatekeeper refuses it
  the first time. Right-click the app, choose Open, and confirm. Once.
• Windows: the installer is unsigned. Edge may flag the download,
  and SmartScreen shows Windows protected your PC the first time:
  click More info, then Run anyway. The app needs Microsoft's
  WebView2 runtime, which Windows 11 already ships; if it is missing
  the installer is set to download it, a path this project has not
  tried. On ARM64 install Silicon Labs' CP210x
  driver by hand before connecting; the radio shows as two COM ports
  and only one answers. See
  docs/windows-setup.md.
• Linux: join the dialout group and log out and in; keep
  ModemManager off the radio (the .deb installs the rule; the tarball
  needs it by hand). See
  docs/linux-setup.md.

FT-710 firmware: memory programming needs V01-10 or later. There is
no CAT query for the version; check the radio's front panel.

Which version you have: rigprog version prints it (on Windows,
.\rigprog.exe version from the folder that holds it; the installer
adds nothing to PATH). The app shows it at the right-hand end of the
status bar. Quote it in any bug report; a build reporting
dev (unreleased build) did not come from this page.

What the hardware evidence covers

Every "works on the radio" claim comes from recorded sessions against
one UK FT-710, on macOS and, since 05/09/2026, on a Windows 11
ARM64 virtual machine;
docs/hardware-notes.md
is the record. Not yet exercised against a real radio: Linux (the
packages have been installed and launched on Ubuntu 24.04 virtual
machines, never with a radio attached, so which serial node is the CAT
port and whether the udev rule keeps ModemManager off it are
unconfirmed); Windows on amd64, or any physical Windows PC; and
every radio other than the FT-710, all of which come from the
makers' manuals and simulators built from them, which is why their
writes are opt-in. Each of those drivers carries a register of every
assumption it makes and the capture from a real radio that would
settle it. If you own one of these radios, a read of a single channel
is the most valuable thing you could send:
open an issue.

Open Rig Programmer v1.2.2

Open Rig Programmer v1.2.2 — an open-source, cross-platform
memory-channel programmer for the Yaesu FT-710, built as a free
alternative to RT Systems' YPS-FT710, with fourteen further Yaesu and
Icom models — thirteen transceivers and one receiver — registered for
reading and for opt-in writes (see below).

What changed in this version

• IC-R8600: a write can no longer overwrite a channel nothing read.
  The receiver's memory is discovered by a bounded walk, and that walk can
  miss an occupied channel whenever a later group's channel 00 is empty.
  Before this release, writing to such a slot went ahead and destroyed the
  stored channel silently. The pre-write read now refuses instead, whenever
  the receiver answers with a record for a slot this session never listed.
  The refusal names which walk ran, because the remedy differs: after the
  bounded walk the slot may simply lie outside its reach, so re-discovering
  the receiver is worth trying; after a full read of all 10,000 addresses it
  cannot, and the channel must have arrived after the session opened — at
  the front panel, or from another controller.
• IC-7100: an absent transmit frequency is no longer read as 0 Hz. A
  memory record that carries no transmit frequency or no repeater offset
  now reports those fields as unavailable, the way the other Icom drivers
  do, instead of a known value of zero. Neither the grid nor the saved file
  now shows a transmit frequency the radio never sent.
• IC-9700: a wrong sibling is reported as the wrong radio. A record
  whose length does not match this model — how a different Icom answering
  the same CI-V address shows up — now identifies itself as a wrong-radio
  refusal as well as a record-length one, matching what the other drivers
  do with the same mistake.
• The IC-R8600's scan-skip refusal is now written down. A channel the
  operator has marked as skipped is refused rather than rewritten as
  unskipped. That was already true; the README simply never said so.

Everything else in this release is internal hardening and carries no change
a user can see: citation pins that hold the four newest Icom drivers to the
documents they were derived from, a byte-identity golden and pinned sparse
load rules for codeplug schema 5, a CI-V drain test that no longer
depends on scheduler timing, and corrections to comments and test prose. No model was
registered, no radio was connected, and the support table below is
unchanged.

What it does

• Read every memory channel into a codeplug file you can keep,
  diff and re-send. On the Yaesu models this is the 99 regular
  memories plus the 9 PMS (Programmable Memory Scan) pairs, over CAT;
  each Icom model has its own CI-V memory-slot shape instead (a
  group-addressed space, or CALL channels alongside it, per model —
  see the per-model honesty rows in docs/icom-models.md).
• Edit channels in a spreadsheet-style grid (GUI) with keyboard
  navigation, paste, per-column editors and drag copy/swap/move.
• Send changes back safely (FT-710): read-before-write, a snapshot
  of the radio's existing contents taken before anything changes, a
  reviewed diff you confirm against a digest, and per-channel verify
  after each write. Anything that cannot be written is shown with the
  reason rather than attempted.
• CSV and CHIRP import/export, with a report of anything a CHIRP
  file cannot express.
• Read the radio's menu (EX) settings, on the Yaesu models, into
  the same file and view or export them — every documented menu
  address for the connected model (FT-710: 296; FTdx10: 197;
  FTdx101D/MP: 193). None of the ten Icom drivers expose a settings
  surface.
• Both a desktop GUI and a rigprog CLI, sharing one core.

Supported radios, and what "supported" means for each

Model	Read channels	Write channels	Read menu settings	Evidence
FT-710	Yes	Yes	Yes	Proven against real hardware (docs/hardware-notes.md)
FTdx10	Yes	⚠️ Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101D	Yes	⚠️ Opt-in (unverified writes, off ...

Open Rig Programmer v1.2.1

Open Rig Programmer v1.2.1 — an open-source, cross-platform
memory-channel programmer for the Yaesu FT-710, built as a free
alternative to RT Systems' YPS-FT710, with fourteen further Yaesu and
Icom models — thirteen transceivers and one receiver — registered for
reading and for opt-in writes (see below).

What changed in this version

• FT-710 read fix (field report, 30/08/2026). v1.2.0 aborted a whole
  read — rigprog read, the GUI's Read Radio and clone preparation — on
  a radio whose PMS pair answered the MR read with kind byte 0
  (ft710: MR answer for slot "P1L" carries kind '0', want one of {'1','5'}). The radio sets that byte itself, on a channel this
  program had written months earlier and nobody had touched since; it is
  not a statement about the slot, so the read no longer refuses it. PMS
  slots now accept the same kind bytes the regular memories always did.
  Recorded in docs/hardware-notes.md (§P7 kind drift). If you hit that
  error on v1.2.0, this release is the fix.
• Five more Icom models registered (the Icom additions tier):
  IC-7851 and IC-7850, IC-7760, IC-7100, and the IC-R8600 receiver — the
  first receive-only model, with its per-channel receiver settings
  (tuning step, attenuator, preamp, antenna, IP+) carried in a new
  codeplug schema (5). All five are document-derived and unverified on
  hardware, exactly like the six Icom models of v1.2.0; the support
  table below says what each can and cannot do.

What it does

• Read every memory channel into a codeplug file you can keep,
  diff and re-send. On the Yaesu models this is the 99 regular
  memories plus the 9 PMS (Programmable Memory Scan) pairs, over CAT;
  each Icom model has its own CI-V memory-slot shape instead (a
  group-addressed space, or CALL channels alongside it, per model —
  see the per-model honesty rows in docs/icom-models.md).
• Edit channels in a spreadsheet-style grid (GUI) with keyboard
  navigation, paste, per-column editors and drag copy/swap/move.
• Send changes back safely (FT-710): read-before-write, a snapshot
  of the radio's existing contents taken before anything changes, a
  reviewed diff you confirm against a digest, and per-channel verify
  after each write. Anything that cannot be written is shown with the
  reason rather than attempted.
• CSV and CHIRP import/export, with a report of anything a CHIRP
  file cannot express.
• Read the radio's menu (EX) settings, on the Yaesu models, into
  the same file and view or export them — every documented menu
  address for the connected model (FT-710: 296; FTdx10: 197;
  FTdx101D/MP: 193). None of the ten Icom drivers expose a settings
  surface.
• Both a desktop GUI and a rigprog CLI, sharing one core.

Supported radios, and what "supported" means for each

Model	Read channels	Write channels	Read menu settings	Evidence
FT-710	Yes	Yes	Yes	Proven against real hardware (docs/hardware-notes.md)
FTdx10	Yes	⚠️ Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101D	Yes	⚠️ Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101MP	Yes	⚠️ Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
IC-7610	Yes	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-7300	Yes	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-7300MK2	Yes	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-705	Yes*	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-9700	Yes	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-905	Yes*	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-7851	Yes	⚠️ Opt-in (unverified writes, off by default)	No	Instruction manual §18 + simulator only; no real radio has been connected
IC-7850	Yes	⚠️ Opt-in (unverified writes, off by default)	No	Instruction manual §18 + simulator only; no real radio has been connected. Shares the IC-7851's manual, add...

Open Rig Programmer v1.2.0

Open Rig Programmer v1.2.0 — an open-source, cross-platform
memory-channel programmer for the Yaesu FT-710, built as a free
alternative to RT Systems' YPS-FT710, with nine further Yaesu and Icom
models registered for reading and for opt-in writes (see below).

What it does

• Read every memory channel into a codeplug file you can keep,
  diff and re-send. On the Yaesu models this is the 99 regular
  memories plus the 9 PMS (Programmable Memory Scan) pairs, over CAT;
  each Icom model has its own CI-V memory-slot shape instead (a
  group-addressed space, or CALL channels alongside it, per model —
  see the per-model honesty rows in README.md).
• Edit channels in a spreadsheet-style grid (GUI) with keyboard
  navigation, paste, per-column editors and drag copy/swap/move.
• Send changes back safely (FT-710): read-before-write, a snapshot
  of the radio's existing contents taken before anything changes, a
  reviewed diff you confirm against a digest, and per-channel verify
  after each write. Anything that cannot be written is shown with the
  reason rather than attempted.
• CSV and CHIRP import/export, with a report of anything a CHIRP
  file cannot express.
• Read the radio's menu (EX) settings, on the Yaesu models, into
  the same file and view or export them — every documented menu
  address for the connected model (FT-710: 296; FTdx10: 197;
  FTdx101D/MP: 193). None of the six Icom drivers expose a settings
  surface.
• Both a desktop GUI and a rigprog CLI, sharing one core.

Supported radios, and what "supported" means for each

Model	Read channels	Write channels	Read menu settings	Evidence
FT-710	Yes	Yes	Yes	Proven against real hardware (docs/hardware-notes.md)
FTdx10	Yes	⚠️ Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101D	Yes	⚠️ Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101MP	Yes	⚠️ Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
IC-7610	Yes	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-7300	Yes	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-7300MK2	Yes	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-705	Yes*	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-9700	Yes	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected
IC-905	Yes*	⚠️ Opt-in (unverified writes, off by default)	No	CI-V guide + simulator only; no real radio has been connected

* IC-705 and IC-905 each discover their memory channels by a BOUNDED
default walk rather than a read of the whole address space (a
100x100-slot, group-addressed space on both). A channel stored outside
that walk's range is simply not read; its absence is not evidence the
channel is empty. See README.md's Icom models section for each
model's exact bound.

Writes to the nine manual-derived models are refused until you enable
unverified writes for that radio, one radio at a time — rigprog settings unverified-writes <model> on (say rigprog settings unverified-writes FTdx10 on, or rigprog settings unverified-writes IC-7610 on), or in the GUI the question it asks once just after you
first connect to such a radio, or its Unverified writes… button at
any time. Both faces read and write one settings file
(rigprog/settings.json under your user configuration directory), so
a decision made in either holds for both, and an "off" is stored
rather than forgotten. "Unverified" means documented in the
manufacturer's own CAT or CI-V reference and exercised against a
simulator here, not proven on a real radio. The FT-710 is unaffected:
its writes are hardware-verified, so it has nothing to consent to.
Consent changes what the tool is allowed to send, not how it sends it
— the read-before-write, the snapshot, the reviewed diff and the
per-channel verify all still run; README.md's Unverified writes
section has the full mechanism. Each of the nine drivers carries a
register of every assumption it makes and the specific capture from a
real radio that would verify it — if you own one of these radios and
want to help, open an issue.

What it deliberately does not do

• It does not write menu settings, and will not. This is a settled
  design decision taken on evidence, not an unfinished feature — the
  FT-710 CAT manual's menu chart proved wrong in both of the two
  respects a read could check, and nothing in the read direction
  establishes what the radio accepts in the write direction. The
  reasoning, and what would have to change to revisit it, is in
  docs/menu-write-decision.md.
• It cannot erase a channel over CAT. The four Yaesu models have
  no CAT erase command at all; the app says so, and tells you the
  front-panel procedure, rather than silently doing nothing. The six
  Icom models are different: their CI-V references print a clear form
  for a memory channel, but this project deliberately ships no erase
  builder for any of them — spec D1 admits exactly three builders per
  driver (ID read, memory read, memory set), and a clear/erase frame
  is not one of them (core/civ/doc.go:64).
• It does not read per-channel CTCSS tone frequencies. The FT-710
  does not report them over CAT (established against real hardware —
  docs/hardware-notes.md), so the app preserves whatever is on the
  radio instead of guessing.

Downloads

Platform	What it is	File
macOS (Intel + Apple Silicon, universal)	GUI (.app, zipped)	open-rig-programmer-v1.2.0-darwin-universal.app.zip
macOS (Intel + Apple Silicon, universal)	CLI	rigprog-v1.2.0-darwin-universal.tar.gz
Linux amd64	CLI	rigprog-v1.2.0-linux-amd64.tar.gz
Linux arm64	CLI	rigprog-v1.2.0-linux-arm64.tar.gz
Linux amd64 (Debian/Ubuntu/Mint)	GUI + CLI (.deb)	open-rig-programmer_1.2.0_amd64.deb
Linux arm64 (Debian/Ubuntu/Mint)	GUI + CLI (.deb)	open-rig-programmer_1.2.0_arm64.deb

Either Debian package installs the GUI, the rigprog CLI, a desktop
entry and the ModemManager udev rule; sudo apt install ./<file>
resolves libwebkit2gtk-4.1-0 and GTK 3 if they are missing. On a
stock Ubuntu 24.04 desktop both were already installed, so the install
fetched nothing extra; a minimal or server image,...

Open Rig Programmer v1.1.0

Open Rig Programmer v1.1.0 — an open-source, cross-platform
memory-channel programmer for the Yaesu FT-710, built as a free
alternative to RT Systems' YPS-FT710, with three further Yaesu models
registered for reading and for opt-in writes.

What it does

• Read every memory channel from the radio over CAT — the 99
  regular memories plus the 9 PMS (Programmable Memory Scan) pairs —
  into a codeplug file you can keep, diff and re-send.
• Edit channels in a spreadsheet-style grid (GUI) with keyboard
  navigation, paste, per-column editors and drag copy/swap/move.
• Send changes back safely (FT-710): read-before-write, a snapshot
  of the radio's existing contents taken before anything changes, a
  reviewed diff you confirm against a digest, and per-channel verify
  after each write. Anything that cannot be written is shown with the
  reason rather than attempted.
• CSV and CHIRP import/export, with a report of anything a CHIRP
  file cannot express.
• Read the radio's menu (EX) settings into the same file and view
  or export them — every documented menu address for the connected
  model (FT-710: 296; FTdx10: 197; FTdx101D/MP: 193).
• Both a desktop GUI and a rigprog CLI, sharing one core.

Supported radios, and what "supported" means for each

Model	Read channels	Write channels	Read menu settings	Evidence
FT-710	Yes	Yes	Yes	Proven against real hardware (docs/hardware-notes.md)
FTdx10	Yes	Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101D	Yes	Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101MP	Yes	Opt-in (unverified writes, off by default)	Yes	CAT manual + simulator only; no real radio has been connected

Writes to the three manual-derived models are refused until you enable
unverified writes for that radio, one radio at a time — rigprog settings unverified-writes FTdx10 on, or in the GUI the question it
asks once just after you first connect to such a radio, or its
Unverified writes… button at any time. Both faces read and write one
settings file (rigprog/settings.json under your user configuration
directory), so a decision made in either holds for both, and an "off"
is stored rather than forgotten. "Unverified" means documented in the
manufacturer's CAT reference and exercised against a simulator here,
not proven on a real radio. The FT-710 is unaffected: its writes are
hardware-verified, so it has nothing to consent to. Consent changes
what the tool is allowed to send, not how it sends it — the
read-before-write, the snapshot, the reviewed diff and the per-channel
verify all still run. Each of the three drivers carries a register of
every assumption it makes and the specific capture from a real radio
that would verify it — if you own one of these radios and want to
help, open an issue.

What it deliberately does not do

• It does not write menu settings, and will not. This is a settled
  design decision taken on evidence, not an unfinished feature — the
  FT-710 CAT manual's menu chart proved wrong in both of the two
  respects a read could check, and nothing in the read direction
  establishes what the radio accepts in the write direction. The
  reasoning, and what would have to change to revisit it, is in
  docs/menu-write-decision.md.
• It cannot erase a channel over CAT. These radios have no CAT
  erase command; the app says so, and tells you the front-panel
  procedure, rather than silently doing nothing.
• It does not read per-channel CTCSS tone frequencies. The FT-710
  does not report them over CAT (established against real hardware —
  docs/hardware-notes.md), so the app preserves whatever is on the
  radio instead of guessing.

Downloads

Platform	What it is	File
macOS (Intel + Apple Silicon, universal)	GUI (.app, zipped)	open-rig-programmer-v1.1.0-darwin-universal.app.zip
macOS (Intel + Apple Silicon, universal)	CLI	rigprog-v1.1.0-darwin-universal.tar.gz
Linux amd64	CLI	rigprog-v1.1.0-linux-amd64.tar.gz
Linux arm64	CLI	rigprog-v1.1.0-linux-arm64.tar.gz
Linux amd64 (Debian/Ubuntu/Mint)	GUI + CLI (.deb)	open-rig-programmer_1.1.0_amd64.deb
Linux arm64 (Debian/Ubuntu/Mint)	GUI + CLI (.deb)	open-rig-programmer_1.1.0_arm64.deb

Either Debian package installs the GUI, the rigprog CLI, a desktop
entry and the ModemManager udev rule; sudo apt install ./<file>
resolves libwebkit2gtk-4.1-0 and GTK 3 if they are missing. On a
stock Ubuntu 24.04 desktop both were already installed, so the install
fetched nothing extra; a minimal or server image, which would have to
pull the WebKit runtime in, has not been tried. That WebKit runtime
package exists on Ubuntu 22.04 and later, on Debian 12 and later, and
on the Mint releases built from those — not on anything older. On
other distributions, take the CLI tarball or build the GUI from source
(wails build -tags webkit2_41 in app/); either way,
docs/linux-setup.md covers the serial-port setup.

SHA256SUMS (attached below) covers every file above. Verify with:

sha256sum -c SHA256SUMS --ignore-missing

Checking which version you have

rigprog version prints it; the GUI shows it at the right-hand end of
the status bar. Quote that string in any bug report. A build that
reports dev (unreleased build) did not come from this release page —
if you downloaded it here, please say so in the report, because that
would be a packaging fault.

Firmware requirement

Memory CAT (read and write) on the FT-710 requires firmware V01-10
or later. There is no CAT query for the firmware version — check the
radio's front panel or SD-card version screen before connecting.

macOS: first launch

The .app is only ad-hoc signed (no Apple Developer ID), so Gatekeeper
will refuse to open it the ordinary way the first time. In Finder,
right-click (Control-click) the app and choose Open, then confirm
in the dialogue that appears. This is only needed once; after that it
opens normally.

Linux: serial port access

• Add yourself to the dialout group and log out/in (or newgrp dialout) before either the GUI or the CLI can open the radio's
  serial port: sudo usermod -aG dialout "$USER".
• ModemManager can probe a newly-plugged serial adapter and interfere
  with it; excluding the radio's USB-serial bridge from ModemManager
  via udev is recommended. The Debian packages install that rule for
  you; for the CLI tarball or a build from source, create it by hand —
  docs/linux-setup.md has the full instructions and a ready-to-use
  rule.

What the hardware evidence covers — read this

Every "works on the radio" claim in this project comes from recorded
sessions against one physical UK FT-710, on macOS, and
docs/hardware-notes.md is the record. Channel reads and writes were
proven on that radio; the menu-settings read was proven separately.
One radio, one region, one firmware version.

What this release has not been exercised against:

• Linux with a real radio. The Linux CLI binaries are
  cross-compiled (the version stamp is asserted on the amd64 binary,
  which the build runner can execute; arm64 takes the same ldflags),
  and the serial stack is the same code on every platform. The Linux
  GUI is built from the same source on every push to main and every
  pull request, and launched under Xvfb on an amd64 CI runner to
  prove it starts; the release build packages it into the
  Debian packages above, whose contents the same release b...

Open Rig Programmer v1.0.0

Open Rig Programmer v1.0.0 — an open-source, cross-platform
memory-channel programmer for the Yaesu FT-710, built as a free
alternative to RT Systems' YPS-FT710, with three further Yaesu models
registered read-only.

What it does

• Read every memory channel from the radio over CAT — the 99
  regular memories plus the 9 PMS (Programmable Memory Scan) pairs —
  into a codeplug file you can keep, diff and re-send.
• Edit channels in a spreadsheet-style grid (GUI) with keyboard
  navigation, paste, per-column editors and drag copy/swap/move.
• Send changes back safely (FT-710): read-before-write, a snapshot
  of the radio's existing contents taken before anything changes, a
  reviewed diff you confirm against a digest, and per-channel verify
  after each write. Anything that cannot be written is shown with the
  reason rather than attempted.
• CSV and CHIRP import/export, with a report of anything a CHIRP
  file cannot express.
• Read the radio's menu (EX) settings into the same file and view
  or export them — every documented menu address for the connected
  model (FT-710: 296; FTdx10: 197; FTdx101D/MP: 193).
• Both a desktop GUI and a rigprog CLI, sharing one core.

Supported radios, and what "supported" means for each

Model	Read channels	Write channels	Read menu settings	Evidence
FT-710	Yes	Yes	Yes	Proven against real hardware (docs/hardware-notes.md)
FTdx10	Yes	No — disarmed	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101D	Yes	No — disarmed	Yes	CAT manual + simulator only; no real radio has been connected
FTdx101MP	Yes	No — disarmed	Yes	CAT manual + simulator only; no real radio has been connected

Writes to the three manual-derived models are disarmed in the code
itself (nothing is writable on a real-hardware session), not merely
untested. Each of those drivers carries a register of every assumption
it makes and the specific capture from a real radio that would verify
it — if you own one of these radios and want to help, open an issue.

What it deliberately does not do

• It does not write menu settings, and will not. This is a settled
  design decision taken on evidence, not an unfinished feature — the
  FT-710 CAT manual's menu chart proved wrong in both of the two
  respects a read could check, and nothing in the read direction
  establishes what the radio accepts in the write direction. The
  reasoning, and what would have to change to revisit it, is in
  docs/menu-write-decision.md.
• It cannot erase a channel over CAT. These radios have no CAT
  erase command; the app says so, and tells you the front-panel
  procedure, rather than silently doing nothing.
• It does not read per-channel CTCSS tone frequencies. The FT-710
  does not report them over CAT (established against real hardware —
  docs/hardware-notes.md), so the app preserves whatever is on the
  radio instead of guessing.

Downloads

Platform	What it is	File
macOS (Intel + Apple Silicon, universal)	GUI (.app, zipped)	open-rig-programmer-v1.0.0-darwin-universal.app.zip
macOS (Intel + Apple Silicon, universal)	CLI	rigprog-v1.0.0-darwin-universal.tar.gz
Linux amd64	CLI	rigprog-v1.0.0-linux-amd64.tar.gz
Linux arm64	CLI	rigprog-v1.0.0-linux-arm64.tar.gz

There is no Linux GUI AppImage in this release: its build job runs
only on Linux CI, which is not in use for this release. Linux users
have the CLI, or can build the GUI from source (wails build in
app/; see docs/linux-setup.md for the build dependencies).

SHA256SUMS (attached below) covers every file above. Verify with:

sha256sum -c SHA256SUMS --ignore-missing

Checking which version you have

rigprog version prints it; the GUI shows it at the right-hand end of
the status bar. Quote that string in any bug report. A build that
reports dev (unreleased build) did not come from this release page —
if you downloaded it here, please say so in the report, because that
would be a packaging fault.

Firmware requirement

Memory CAT (read and write) on the FT-710 requires firmware V01-10
or later. There is no CAT query for the firmware version — check the
radio's front panel or SD-card version screen before connecting.

macOS: first launch

The .app is only ad-hoc signed (no Apple Developer ID), so Gatekeeper
will refuse to open it the ordinary way the first time. In Finder,
right-click (Control-click) the app and choose Open, then confirm
in the dialogue that appears. This is only needed once; after that it
opens normally.

Linux: serial port access

• Add yourself to the dialout group and log out/in (or newgrp dialout) before the CLI can open the radio's serial port:
  sudo usermod -aG dialout "$USER".
• ModemManager can probe a newly-plugged serial adapter and interfere
  with it; excluding the radio's USB-serial bridge from ModemManager
  via udev is recommended. See docs/linux-setup.md for the full
  instructions and a ready-to-use udev rule.

What the hardware evidence covers — read this

Every "works on the radio" claim in this project comes from recorded
sessions against one physical UK FT-710, on macOS, and
docs/hardware-notes.md is the record. Channel reads and writes were
proven on that radio; the menu-settings read was proven separately.
One radio, one region, one firmware version.

What this release has not been exercised against:

• Linux with a real radio. The Linux CLI binaries are
  cross-compiled and version-stamp-verified, and the serial stack is
  the same code, but no real-radio session has been run on Linux yet.
  docs/linux-setup.md carries the port-setup instructions; treat the
  first Linux session as exploratory and read-only first.
• Any FTdx10, FTdx101D or FTdx101MP. Everything about those three
  models is derived from the manufacturer's CAT reference manuals
  through a documented transcription-and-cross-check process, and
  exercised against simulators built independently from the same
  manuals. No real radio of any of the three has ever been connected.
  That is why their writes are disarmed.

Anything the project has not observed is labelled as such in the code
and documentation rather than assumed. Reports from real hardware —
especially the three read-only models, and the FT-710 on Linux — are
the most valuable contribution this project can receive right now.