ADALM-PLUTO (SDR rx/tx) notes

Uit Projectgroep .540
Ga naar: navigatie, zoeken

General

The PG540 group is experimenting continuously. Every 2 weeks our groupmeeting is overloaded with people bringing in their (usually quite experimental) setups and gear. SDR has been on the agenda for along time - the first SDR notes on the PG540 group wiki date from 2014.

Lately (summer 2018), the ADALM-PLUTO SDR came to our attention. Rene PA1RKT decided to buy one, followed by others in the Autumn of 2018. This wiki page reflects our experiences, and just that - so it is not a review nor an objective performance measure of the Pluto. We just experiment with it and write down what we find.

The ADALM-PLUTO is an SDR for RX and TX with a broad frequency range. It is slowly being backed by operating systems and applications, the most notable being GNU Radio (on Linux) and some (D)ATV software on Windows (I will find out the name ;-)

Connecting and detecting / GNU Radio

Windows: The original ADALM-PLUTO website covers all aspects of connecting and detecting the ADALM-PLUTO, especially the things to check when using it on a Windows computer. The Device Manager is your friend on Windows.

Under Linux, my main objective is to experiment with the PLUTO and GNU Radio. This can be a bit cumbersome, as at the time of my first experiments (summer 2018) GNU Radio did not support the ADALM-PLUTO block 'out of the box' - so there is/was no binary support. I had to build the complete GNU Radio suite from the source, building and integrating the PlutoSDR block along the way. I decided to go the [Pybombs https://github.com/gnuradio/pybombs/blob/master/README.md] route for this. This took a lot of time and frankly, this is not a very transparent process to me. I managed, though, BUT I can at this moment not reproduce how I got there. I hope there will be out-of-the-box support in ordinary binary distributions soon.

Under Linux, I currently must cd to the installed PyBombs environment (this is the 'gr-sdrplay' directory in my user directory), then set the environment for the Python scripts that GNU Radio relies on, and then start gnuradio-companion.

cd gr-sdrplay

source setup_env.sh

gnuradio-companion

In GNU Radio, I now have PlutoSDR source and sink blocks to use for receiving and transmitting respectively. They are filed under "Industrial I/O" in the GNU Radio comapnion UI.....

Warning: the ADALM-PLUTO is not RF sealed and is also very sensitive regarding electric currents and shocks. If any common mantle currents or other electric discrepancies exist, the ADALM-PLUTO might not even show up in your system and appear dead. In this case, disconnect all other wires, leaving only the ADALM-PLUTO, even the antenna terminals not connected and see if the ADALM-PLUTO resurfaces.

Experiments on 70cm

Using GNU Radio, it is not very hard to find an example of a NBFM transmitter/receiver. Just replace the source (in case of receiver) and/or the sink (in the case of transmitter) with the PlutoSDR block. Its use is quite straightforward.

The PLUTO pushes out a few milliwatts (they say it is max. +6dBm, but I have no ways to measure this accurately). The signal sounds clean. However, when trying to use it as a real transmitter (or even transceiver), some problems (features :-)) have to be overcome.

I (PA1RKT) prefer to experiment with the Pluto in the 70cm band, preferably on our PG540 'channel 2' frequency of 430.540 MHz (see Huisfrequenties).

The local oscillator (LO) is always on

The Pluto has 2 independent LO's: one for receive and one for transmit. That means you can use it in full duplex mode. However, when you stop transmitting, the end-stage of the Pluto will stop working, but the LO-TX will keep oscillating. This can be very annoying if e.g. you want to make a simplex QSO - the receiver will experience interference from the TX-LO. The only way I have found to circumvent this is to set the LO-TX to some other frequency when not transmitting. There are a few drawbacks to this approach: the Pluto will break-in really ugly as it is re-adjusting to the right frequency when you start transmitting. Not really smooth. Furthermore, if you use some amplifier line after the Pluto (like my 'repeater experiment' see another paragraph in this Wiki) and you choose a 'dummy' frequency within the band that the amplifier(s) work in, you might damage the amplifiers in the long run as they will run continuously. I damaged some broadband 'Chinese' amplifiers/LNA's with this approach. Make sure the dummy frequency is far out of range of your amplifying chain of components. I prefer to make it a very high frequency, so there are no harmonics in the way. It's even better if you apply a bandpassfilter between your Pluto and the first amplifying stage. This will prevent the out-of-band LO-TX signal from reaching your amplifier(s) even more while receiving.

Filtering the signal

While being an extraordinary piece of (affordable) engineering, a few corners have been cut - I think to make the Pluto affordable for folks like us :-) One of them is that the Pluto has no RF shielding. It is very sensitive to overloading and external interference. This makes experimenting with amplifying stages etc. a bit messy. I have taken the route to be OK with it as I am experimenting now, but if you want to use the Pluto in a 'real' operating environment, like a HAM shack, and for real QSO's or even more serious stuff ((D)ATV seems to be a good candidate, but the 540 group still has to find that out (december 2018)) - shield your amplifiers, and filter filter filter your signal.

That leads us to the subject of filtering the signal. <to be continued>




`


73 Rene PA1RKT