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

If you own a Yaesu FT-710 and have looked at remote control at all, you've met the SCU-LAN10 — Yaesu's network dongle that bridges the radio to your LAN. It works, but it is an extra box, a proprietary protocol, and a closed black box. This article is about a different path: controlling a FT-710 over a single USB cable, reading its real spectrum/waterfall data, and streaming audio — with no additional hardware at all.

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.

Anatomy of the FT-710 USB port

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

Interface	USB endpoint	What it carries
Enhanced COM Port	CP210x UART	CAT commands at 38400 baud
FT4222 SPI Bridge	FTDI D2XX	850-point FFT spectrum for two receivers, ~30 fps
USB Audio Codec	C-Media	44.1 kHz RX audio capture + TX playback

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.

The FT4222 SPI bridge: spectrum without a dongle

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.

Inside the 4096-byte scope frame

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

Offset	Size	Content
0–849	850 B	WF1 spectrum (inverted; each byte corrected with ~b & 0xFF)
850–1699	850 B	WF2 spectrum (second receiver)
1700–2899	1200 B	Reserved / additional data
2900–3049	150 B	Metadata block
4092–4095	4 B	Sync tail 0xFF 0x01 0xEE 0x01

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.

CAT control over the Enhanced COM Port

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.

From SPI to browser: the data pipeline

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.

What happens when you transmit

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.

Graceful degradation: S-meter fallback

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.

FT-710 + USB vs the SCU-LAN10

	SCU-LAN10	MRRC FT-710 (USB)
Hardware	Separate network dongle	None — the USB cable you already own
Spectrum path	Proprietary UDP over Ethernet	Raw 4096-byte SPI frames, decoded open source
Client	Yaesu software	Any modern browser (WebSockets)
Spectrum fallback	None	S-meter synthetic spectrum when FT4222 is absent
Auditability	Closed black box	Fully documented frame format and CAT implementation

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 project's Software Design Document. The code is open source on GitHub, and a live demo runs at mrrc_ft710.vlsc.net.