In my last post on the Pluto External PTT I had done some preliminary testing of the external PTT output using a multi-meter before wiring it to the Pluto Charon and confirming it worked. It was at this point things took a jump to the left and then a step to the right…

What I noticed is I would hit the TX button in SDR-Console and there would be a pause, one, two, three, then click would go the transmit receive (TRX) relay. Hmm that’s not going to do, a 3s delay between the PC software PTT and the Pluto Charon external amplifier ain’t going to work on FM/SSB.

However if I hit the TX button in SDR-Console again the TRX relay would click and go off without any delay. Now that was strange and the asymmetric nature of operation required further investigation.

The first step was to rule out the hardware, so with a C.R.O on the Pluto Charon PTT line (connector A1) and another on the ADALM Pluto GPO0 pin (yellow and cyan respectively) we can check that the switching is nice and clean.

Nope nothing to see here, you can see the transistor on the Pluto Charon PTT board pulling the PTT line low and hitting zero volts in no more than 12us. Problem has to be elsewhere.

So now were into firmware and software territory, sigh this is going to be one of those rabbit holes.

I firstly tried the “for the brave” firmware that can be found on the Mini-kits support website, which is an early version of the PlutoDVB firmware. This changed the behavior entirely and there was a delay of 1-1.5s each time the external PTT changed state from ON to OFF. Not what I wanted, but better and perhaps more usable than the 3s ON and instant OFF I was seeing on the PlutoDVB revision 3.0.3 firmware + Rev C/D patch.

Further reading from the analog devices website suggested that the GPO pin connected my external PTT module could be controlled by some ENSM module within the AD9361-phy linux driver, so I tried some experiments with SDR-Console and the Analog Devices stock v0.38 firmware, that didn’t work either. It was clear that SDR-Console was not using this IIO method to switch the Pluto in to TX or RX.

So I revisited the latest PlutoDVB firmware (perseverance 3.0.3 + Rev C/D patch) once again reading and watching more closely this time.

It was while applying the patch I saw something interesting, I’ve highlighted it in red adjacent. I wonder what that script does ?

The whole reason the patch was required in PlutoDVB Perseverance 3.0.3 firmware was to get the PTT working with revision C & D hardware. I wonder if that is where I start ?

So let me log into the Pluto and take a peek at the script.

#!/bin/sh
#https://www.analog.com/media/cn/technical-documentation/user-guides/AD9364_Register_Map_Reference_Manual_UG-672.pdf
source /root/device_sel.sh
ptton()
{
    #PTT on GPIO 0 AND GPIO 2 (GPIO 1 should be not touched)
    echo 0x27 0x50 > /sys/kernel/debug/iio/iio:device$dev/direct_reg_access
    mosquitto_pub -t plutodvb/status/tx -m true
}

pttoff()
{
    echo 0x27 0x00 > /sys/kernel/debug/iio/iio:device$dev/direct_reg_access
    mosquitto_pub -t plutodvb/status/tx -m false
}

echo manual_tx_quad > /sys/bus/iio/devices/iio:device$dev/calib_mode
#Manual GPIO
echo 0x26 0x10 > /sys/kernel/debug/iio/iio:device$dev/direct_reg_access
pttoff

while :
do
inotifywait -e modify /sys/bus/iio/devices/iio\:device$dev/out_voltage0_hardwaregain
gain=$(cat /sys/bus/iio/devices/iio:device$dev/out_voltage0_hardwaregain)
if [ "$gain" = "-40.000000 dB" ] ; then
    echo "SdrConsole PTT OFF"
    pttoff
else
    if [ "$gain" = "0.000000 dB" ] ; then
        sleep 2
        gain=$(cat /sys/bus/iio/devices/iio:device$dev/out_voltage0_hardwaregain)
        if [ "$gain" = "0.000000 dB" ] ; then
            echo "SdrConsole Power Max PTT ON"
            ptton
        fi
        else
            echo "SdrConsole PTT ON"
            ptton
        fi
    fi
done

So reading my way through this script by the time I hit line 24 I had confirmed

• SDR-Console does not use the ENSM module within the Pluto ad9361-phy driver
• Instead the script uses the sysfs subsystem to read different values from the IIO driver
• SDR-Console varies the TX gain within the IIO driver between two limits that the script interprets and drives the relevant GPO pin
• In an attempt to prevent a race condition, line 31 introduces a 2s sleep function between successive reads of the gain value

Guess where the 3s delay I’ve been searching for comes from !?!

So a quick bit of hacking on this script, changing line 31 to read “sleep 0.1” or 100ms, then restarting the “watchconsoletx.sh” process increased the speed of the external PTT to the point where the delay between SDR-Console and the TRX relay on the Pluto Charon activating is nearly imperceptible. I’m not sure if using a fraction of one second is valid in this shell, it may have been ignoring it, but it proved my point.

However what I’ve done to this script and the way in which SDR-Console works I’m not convinced will work 100% of the time. The other problem is any changes that are made to these script files are not permanent they are only kept in RAM, so as soon as you reboot they revert to those stored in volatile memory (flash).

So it looks like I may have to reverse engineer the “pluto.frm” file and see if I can hack together a better script to make this work how I want. At least I now know where the 3s delay has come from and that there are possibilities to fix it.

That however will have to wait until the next post.