Remote-Controlling a Yaesu FT-710 with Just a USB Cable

01 · Anatomy

Anatomy of the FT-710 USB port

One cable, three devices — CAT, spectrum, audio.

This is the story behind the MRRC FT-710 open-source project, and it starts with a fact most owners don't realize: the FT-710 already contains everything needed for high-quality remote control. The USB port on the back is not just a CAT serial port — it exposes three independent interfaces at once.

Plug one USB cable from your computer into the FT-710 and the OS sees three devices, not one:

The reason most people think "USB = CAT only" is that only the serial port is user-visible. The FT4222 SPI bridge and the C-Media audio codec are usually consumed internally by the front-panel display and by Yaesu's own SCU-LAN10. When you open the device with the FTDI D2XX driver by its descriptor string "FT4222 A", the hidden spectrum interface is right there.

02 · Spectrum path

The FT4222 SPI bridge: spectrum without a dongle

850 bins per receiver straight off the SPI bus — no dongle, no IQ stream.

The FT4222 is an FTDI USB-to-SPI bridge IC soldered onto the FT-710's main board. In our setup it is driven with a deliberately conservative configuration (mirrored from wfview's ft4222handler.cpp):

SPI mode:    single I/O (SPI_IO_SINGLE)
Clock:       SYS_CLK_24 (24 MHz) ÷ CLK_DIV_64  →  375 kHz SPI clock
CPOL / CPHA: idle HIGH, data on leading edge
Slave select: 0x01
Read size:   4096 bytes per transaction

The SPI clock divider is even tunable at runtime through the FT710_FT4222_CLK_DIV environment variable — handy when a particular USB cable or hub needs a more conservative timing. Each SPI transaction returns one 4096-byte scope frame.

Here is the key architectural point: what comes off the SPI bus is already-processed amplitude data, not raw IQ samples. The FT-710's internal SDR engine computes the FFT and hands us 850 amplitude bins per receiver. This is fundamentally different from streaming SDRs like a KiwiSDR or RX888, which ship raw IQ and push the FFT work to the host. For remote control, receiving pre-computed spectra means a laptop or even a Raspberry Pi can render a waterfall with trivial CPU.

03 · Frame format

Inside the 4096-byte scope frame

Two receivers plus a 150-byte metadata block, checked against a 4-byte sync tail.

Each frame is a compact structure that carries two receivers' spectra plus a dense metadata block:

That 150-byte metadata block is where the radio tells us almost everything about its current state: scope mode, preamp and attenuator bits, span, operating mode, the VFO-A frequency in both 5-byte BCD and 4-byte big-endian form, the raw S-meter value, and the scope's start frequency. Frame synchronization is validated against the 4-byte sync tail, and the SPI bus delivers roughly 30 frames per second.

One quirk worth knowing: the spectrum bytes are inverted. Early on, a naive read produced a waterfall that looked like a photographic negative — the fix is a single ~b & 0xFF per byte.

04 · CAT

CAT control over the Enhanced COM Port

Native Yaesu CAT at 38400 baud — no Hamlib, no rigctld.

Control runs over the CP210x serial port using native Yaesu CAT — no Hamlib, no rigctld. The project deliberately avoids the Hamlib dependency (an explicit architecture decision, AD-002 in the SDD): for the FT-710's CAT dialect, a direct implementation is smaller and faster.

The protocol is the familiar two-letter command format:

FA014200000;   # set VFO-A to 14.200 MHz

Key details that matter in practice:

• 38400 baud, 8N1, no flow control (the CP210x doesn't support RTS/CTS).
• On connect the server sends AI0; to disable the radio's auto-information stream, then polls actively instead. Passive polling is far more predictable than reacting to an asynchronous push stream.
• A 20 ms post-write delay between commands, matching Hamlib's post_write_delay — the FT-710 CAT processor simply doesn't keep up otherwise.
• Time-critical commands (PTT TX1;, tune TX2;) take a priority path that cancels in-flight polling, so keying up doesn't wait behind a poll round-trip.

Spectrum output on the SPI bus has to be enabled explicitly, via extended CAT register writes sent right after connect:

EX040101   # enable scope data output on the FT4222 SPI
EX040200   # set scope to CENTER mode (not FIX mode)

Without these two commands, the FT4222 sits silent no matter how hard you read from it — a classic gotcha for anyone starting from scratch.

05 · Pipeline

From SPI to browser: the data pipeline

A separate process reads, the server broadcasts, the browser draws.

Reading the SPI bus is blocking, and the FTDI D2XX ctypes calls can stall unpredictably. So the spectrum reader runs as a separate OS subprocess (scope_pipe.py), isolated from the server. If it crashes, the server detects the dead pipe and restarts it — the web client never notices.

The pipeline has three clean stages:

1. Hardware read: the subprocess reads 4096-byte frames from the FT4222 in a tight loop, validates the sync tail, parses the metadata, and emits length-prefixed frames on stdout.
2. Server broadcast: the FastAPI server decodes each frame and pushes a compact binary message to every /WSspectrum WebSocket client.
3. Browser render: the client draws an FFT polyline and a waterfall with 120 rows of history and six selectable colormaps.

The WebSocket frame format is deliberately minimal — 1701 bytes: a 1-byte version, then 850 bytes of WF1, then 850 bytes of WF2. The broadcast loop runs at 5 fps (200 ms intervals), which is smooth for a remote waterfall without burning bandwidth.

06 · Transmit

What happens when you transmit

The radio garbles its own scope stream, so the pipe closes and reopens.

The FT-710 garbles its scope stream while transmitting — the spectrum data becomes noise mid-key. Rather than fight the radio, the server pauses the SPI read loop during TX by sending TX:1 down the subprocess's stdin. On PTT release, the pipe does a full device close, settle, and reopen to re-sync the stream cleanly.

That close/reopen dance exists because an earlier version tried to just resume reading — and hit a fatal: too_many_reinits crash loop after repeated TX cycles. Re-opening the FT4222 device after each transmission turned out to be the reliable fix.

07 · Fallback

Graceful degradation: S-meter fallback

When the SPI bridge is missing, the interface still works.

Not every host has the FT4222 D2XX driver, and not every cable/OS combo cooperates. When the SPI bridge is unavailable, the server synthesizes a plausible spectrum from the CAT S-meter reading: a Gaussian peak centered in the current span, scaled by S-meter value, with secondary peaks and noise speckle for realism.

It isn't real RF data, but it keeps the entire UI functional — tuning, mode changes, band changes — so the remote experience degrades gracefully instead of dying. The fallback runs at the same 5 fps as the real path, and the client can't tell the difference from the protocol side.

08 · Comparison

FT-710 + USB vs the SCU-LAN10

What the dongle gives you that this does not.

The trade-offs are honest ones. The SCU-LAN10 puts the radio on your LAN, so any machine on the network can reach it. The USB path binds the radio to a single host computer — which then shares it out over the network itself. If you're running a 24/7 shack computer anyway, that's not a limitation at all; it's a simplification.

The full architecture — component inventory, WebSocket message specs, and the seven-layer PTT safety model — is documented in the Software Design Document. The code is open source on GitHub.

09 · Status

Where this path goes now

Archived 2026-09-12 — the USB path lives on in MRRC Modern.

Archived 2026-09-12. The original single-radio repository (cheenle/mrrc_ft710) is now read-only and its site 301-redirects to MRRC Modern, which drives the FT-710 as well as the IC-7300 / IC-7300MK2 through a pluggable backend. This article is kept as the technical record of how the USB path was discovered.