FT891.Core 1.2.0

FT891.Core

The library at the heart of the solution: a complete, async CAT client for the Yaesu FT-891, the protocol engine that drives it, the command table it relies on, and the transport abstraction that lets it talk to either real hardware or the simulator.

Target framework: net48 · Language: C# latest · No runtime dependencies beyond System.IO.Ports (for the serial transport).

Folder layout

FT891.Core/
├── Enums/
│   └── Enums.cs              OperatingMode, AgcMode, MeterType, TunerState,
│                             ScanMode, BreakInMode, BandSelect
├── Models/
│   ├── RadioInfo.cs          record: frequency, mode, TX, S-meter, split, channel
│   └── MeterReading.cs       record: meter type + value
├── Protocol/
│   ├── CatSpec.cs            command → reply-length table (the source of truth)
│   ├── CatSerialEngine.cs    the single byte-count-driven TransceiveAsync
│   ├── FT891Cat.cs           ICatInterface implementation (one-liners)
│   ├── ICatTransport.cs      the byte-pipe abstraction
│   ├── SerialPortTransport.cs   real radio (RS-232 / USB, 8-N-2)
│   ├── TcpCatTransport.cs    virtual serial port over TCP
│   └── Num.cs                Clamp helper (Math.Clamp is absent on net48)
├── Interface/
│   └── ICatInterface.cs      the full public surface
└── Properties/
    └── IsExternalInit.cs     polyfill so records/init compile on net48

How it fits together

1. CatSpec — the response-length table

A single dictionary maps each 2-letter command to the total number of bytes its reply contains, including the prefix and the trailing ;:

{ "FA", 12 },   // "FA014250000;"  → 2 + 9 + 1
{ "MD",  5 },   // "MD0" + 1 hex mode digit + ";"
{ "IF", 34 },   // full status frame
...

This is the only place that encodes per-command knowledge. 58 commands are described. The lengths were derived from (and kept consistent with) the exact frame formats FT891Cat builds and parses, so a count-driven read always lands on the right boundary. (A handful of lengths were corrected from the original single-file source for self-consistency — see the table at the bottom.)

2. CatSerialEngine.TransceiveAsync — the only I/O

public async Task<string> TransceiveAsync(string command, int expectedBytes = -1)

• Ensures the command ends with ;.
• If expectedBytes is -1, looks it up in CatSpec from the 2-char prefix.
• expectedBytes == 0 → a set-only command; write and return immediately.
• Otherwise it reads exactly expectedBytes bytes in a loop (handling partial TCP/serial reads) — never scanning for a delimiter.
• A SemaphoreSlim serialises access so concurrent callers can't interleave a write/read pair.

3. ICatTransport — serial or TCP

public interface ICatTransport : IDisposable
{
    bool IsOpen { get; }
    void Open();  void Close();  void DiscardInBuffer();
    void Write(string data);
    int  Read(byte[] buffer, int offset, int count);
}

• SerialPortTransport — wraps System.IO.Ports.SerialPort configured the way the FT-891 expects: 38400 baud, 8 data bits, no parity, two stop bits, ASCII encoding, 2000 ms read/write timeout.
• TcpCatTransport — treats a TCP socket as a virtual serial port. A socket read-timeout is surfaced as a TimeoutException, so "the radio said nothing" always looks the same regardless of transport.

4. FT891Cat — one-liners over the engine

Every method is a single expression that builds a frame (for a set) or builds a frame, awaits the reply, and slices out the value (for a read):

public Task SetVfoAFrequencyAsync(long hz)      => Set($"FA{hz:D9};");
public async Task<long> GetVfoAFrequencyAsync() => long.Parse((await Read("FA;")).Substring(2, 9));

Three constructors let you choose the transport:

new FT891Cat("COM3");                                  // real serial port
new FT891Cat(new TcpCatTransport("127.0.0.1", 4000));  // simulator / network
new FT891Cat(existingCatSerialEngine);                 // bring your own engine

API surface (ICatInterface)

Values are clamped to the radio's valid ranges before transmission (e.g. TX power 5–100 W, key speed 4–60 WPM) via the Num.Clamp helper.

Running modern C# on .NET Framework 4.8

The original source used several APIs/syntax that don't exist on net48. They are handled so the code stays clean and idiomatic:

Reply lengths corrected from the original single-file source

These keep the count-driven reader perfectly aligned with the bytes a real radio (and the simulator) emits.

READMEs written by Claude Code Opus 4.8m Context - From CodeBase - TSGBMPPT