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.
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.
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 on air not connected
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.]
Another update in November 2024: MB7IVR back on the network!
I brought MB7IVR back into the shack with the aim of finding a CTCSS controlled squelch signal under the covers which could be used to replace the apparently non-CTCSS controlled squelch pin on the packet output port.
Strangely the service manual for this rig doesn't seem to completely match up with what it does in practice (or operator error?), a candidate signal was found but it didn't behave as expected.
Further study of the service manual revealed that while the 1200 baud packet audio port which was currently used was subject to some narrow filtering, the 9600 baud output was extracted before the filters. The interface was modified to use this output, and ASL3 was configured to use the usbradio driver which can do software CTCSS decoding with a built-in DSP.
Following a last minute, on-site addition of a 3dB attenuator on the audio output (made possible due to some random resistors found in the back of G7HMV's car), MB7IVR is now back on 6m & 10m and no longer kerchunking the network with every bit of QRM it hears.