First of all, I made the “hack” modifications described in ADALM-PLUTO development kit for (not only) Es’hail-2 satellite . For this purpose, I used the PuTTY terminal program with the following settings: Serial – COMxx – 112500 (where xx is the COM port number at which Pluto appears in the system). After clicking “Open” I entered login: root and Password: analog. After Pluto appeared, I entered the commands:
# fw_setenv attr_name compatible
# fw_setenv attr_val ad9364
# fw_setenv maxcpus
# pluto_reboot reset

In the next step, I removed the board from the plastic housing and made the recommended connection (using a wire) of the USB connector cases with the GND point. Then I mounted the board in a metal housing and made connections to the PTT board: ground, + 5V (pad of unsoldered capacitor C185), GPIO0 and GPIO1. I connected the 40 MHz signal from the Pluto-clocker  board to the appropriate IPEX socket (see below).

To switch the source of the 40 MHz signal generator from internal to external, enter the command (after starting PuTTY or a similar terminal):
# fw_setenv refclk_source external

After restarting Pluto, I launched SDR Console – the screen showed characteristic peaks from the QO-100 satellite, but shifted upwards by about 9.6 kHz. I suspected the fact that the factory-set frequency of the external generator was different from 40 MHz, which I checked with the command:
# fw_printenv ad936x_ext_refclk
The result was: ad936x_ext_refclk = <39999804>. It is not known why the nominal value of 40,000,000 was not used! To change this value (according to  https://wiki.analog.com/university/tools/pluto/devs/booting) use the command:
# fw_setenv ad936x_ext_refclk ‘<40000000>’

After its application, theoretically it was OK:
# fw_printenv ad936x_ext_refclk
ad936x_ext_refclk=<40000000>

Unfortunately – after restarting Pluto the “old” frequency returned again:
# fw_printenv ad936x_ext_refclk
ad936x_ext_refclk=<39999804>

Using # fw_setenv ad936x_ext_refclk_override 40000000 and entering xo_correction = 40000000 in config.txt did not solve the problem. After rebooting, the “old” frequency always returned and there was an SDR Console receiving frequency offset that should not have occurred as both the 40MHz Pluto clock frequency and the 25MHz LNB reference frequency were very accurate.

I decided to check it with other versions of the Adalm-Pluto firmware. I started with the latest version v0.34 from the Analog Device website. Then I checked with the previously used version of the Evariste F5OEO. Finally, I installed (with patches) the latest available version of “perseverance 0303”, which is adapted to the Revision D and allows not only PTT support, but also the transmission of DVBT signals. This version is available for download at  https://www.f5uii.net/en/patch-plutodvb/ .

After downloading PlutoDVB perseverance firmware 0303: pluto.zip (26.6M) and the patch PlutoDVB Patch Detection Hardware Revision firmware perseverance 0303.zip – you need to unpack them. To install the new firmware, copy the pluto.frm file to the Adalm-Pluto disk. Then perform the operation “- Eject PlutoSDR (X :)”. It’s about the drive, not the entire device! The LED on the left side of Pluto starts flashing rapidly. Wait a few minutes until it returns to normal. The USB cable must not be disconnected during the update! Adalm-Pluto will appear in Windows as PlutoSDR (X :). Please run info.html – Let’s go to PlutoDVB (on USB connection) – Main mode selection: Passthrough (SDR Console,…) – Apply Settings.

To install the above-mentioned patches, click System – Maintenance, find the folder with unpacked files PlutoDVB Patch Detection Hardware Revision firmware perseverance 0303, and click: Upload. After loading is complete, select: Reboot the Pluto.

Unfortunately – the mentioned shift of the receiveing frequency in the SDR Console of 9.6 kHz was still present. There was also a transmission frequency shift of 2.25 kHz.

After many unsuccessful experiments, I decided to solve the problem at the application level. As all users of the QO-100 satellite know, the actual receiveing frequency at the Adalm-Pluto input is shifted 9750 MHz down from the actual frequency of the QO-100 transmitter (downlink) in the 10 GHz band and is in the range 739.5-740 MHz. In turn, the transmission frequency at the Adalm-Pluto output (uplink) is in the range of 2400 MHz, and the offset from the downlink frequency is 8089.5 MHz. It was enough to make the appropriate corrections in SDR Console (Select Radio – Definitions … – Edit):
RX: __9749.990.400
TX: __8089.497.750
and it is now possible to use the device as a transceiver as usual. As you can see in the picture below, the 10489.750kHz beacon frequency is in place.

Note – in May 2023 I decided to return to the frequency shift problem in the SDR Console described above. I’ve done a lot of experiments, the last one was:
– reinstalling the firmware version “perseverance 0303”
– remove old patches in Adalm-Pluto (System-Maintenance…)
– install the latest patch F5EOE PlutoDVB-Patch-Detection-Hardware-Revision-firmware-perseverance-0303-v2022-08-21.zip
– running (just in case) “hack” modifications
– # fw_setenv refclk_source external
– # fw_setenv ad936x_ext_refclk_override ‘<40000000>’

As a result, Pluto with SDR Console started working as it should, with the following settings: RX Offset 9.750.000.000 TX Offset 8.089.500.000. Even after the Pluto reset. At last!

Although command # fw_printenv ad936x_ext_refclk still gives ad936x_ext_refclk=<39999804>. Fortunately, it’s fake.

Miro SP5GNI