../ft8900r-remote-control

Yaesu FT8900r Remote Control

Herts Repeater Group have recently been building a new, dual band Allstar node covering 10m and 6m bands, MB7IVR.

Unfortunately this rig doesn't have a CAT interface, so I found myself trying to find a way to control it from an Allstar node, sothat the band can be changed remotely. The rig has a detachable head interface which I found sends regular bursts of data back to the radio body.

Test setup for FT8900r

I got a little way figuring out the hardware protocol before discovering that Cormac had built something similar based on work by another amateur, the latter of which has sadly disappeared from the internet. Cormac's version works well, however I wanted to preserve the ability to use the radio as normal (which Cormac's version does not), as well as add networking features.

Also helpful was this blog post which details the structure of the packets flying between the two parts of the rig.

A cable was constructed to route the RX (TX from head) pin on the head side to the serial RX pin on a Raspberry Pi Model 3b. The TX pin from the Pi was then connected to the RX (TX from head) of the cable on the body side, such that the Pi is able to receive data from the head and pipe it back in to the body on the RX (TX from head) line.

Pinout of FT8900r head unit cable

All other pins should be connected so that the radio can continue to operate normally.

The Pi uses 3.3v logic, so a voltage divider was added to shift the level down (2.2k and 3.3k resistors). Fortunately the radio is fine with a 3.3v '1' so no shifting was required from the Pi's TX.

This then allowed me to write github://mattmelling/ft8900-remote which intercepts the packets, and dispatches keypresses when a command appears on a network socket. We were then able to plumb this in to Allstar such that a DTMF command received in Allstar sends a UDP packet to the remote daemon.

The remote program will accept keypress commands like k1k4k5k0k0k0 to enter 145000. This was a bit slow, so added the ability to select a hypermemory using hN. Then we programmed hypermemory 1 with the 10m settings, and hypermemory 2 with the 6m settings. Since we can intercept and generate any valid head packet, it could be extended to support any feature that the radio supports from the front panel.

[Update in November 2024: MB7IVR is still going strong, although lack of CTCSS squelch on the packet port (which we use for audio in/out) means that it can't stay connected to the network permanantly due to local QRM.]