In a recent post I configured the SDRangel “Simple PTT” plugin. While testing I’ve noticed that there is some TX leakage from the ADLAM Pluto, which I measure to be -50dB-ish below its nominal output.
In the gallery below the ADLAM Pluto was set to transmit 0dBm (1mW) and on the right is the leakage when in receive.
I may have to investigate if the “samplesink/plutosdroutput” plugin within SDRangel can be configured to turn the TX chain completely OFF and what impact this may have.
The output level seems to jump when the transmit frequency is adjusted 100kHz away from the receive, and here I suspect that the DC correction within the receiver is doing double time removing the TX leakage. I will just have to keep an eye on this when integrating with the Charon.
In recent post I configured SDRangel to work with a ADLAM Pluto as part of my 23cm transceiver project. Having configured the receiver and transmitter I had a proof in concept working under Linux, but there was one feature missing, how could I imlement a Push to Talk (PTT) function/button ?
So it was back to the search engines and it didn’t take long to find that SDRangel has a “Simple PTT” plugin that can be configured to provide this functionality.
Simply clicking on the “add feature” button, selecting “Simple PTT” from the drop down box, I was greeted with a new widget to configure.
Configuration of this plug-in is straight forward. Select the RX Dev from the drop down box, in my case R0; then select the TX Dev from its drop down box, in my case T1. For the time being the RX to TX and TX to RX delays are OK, as I’m not using any external amplifiers or pre-amps. Then you must hit the “play” button in the top left of the Simple PTT screen to activate the plug-in, at which point pressing the PTT button will make the ADLAM Pluto do it’s thing.
Here’s where I’ve placed the Simple PTT plugin in my SDRangel screen for the time being (lower left). You can clearly see the PTT button sitting there waiting to be used.
At this time SDRangel cannot control the ADLAM Pluto GPIO from within this plug-in, but it may be possible to use the Analog Devices “iio” utilities and script this externally. There are two buttons “Rx-Tx-Cmd” and “Tx-Rx-Cmd” that can be linked to individual scripts, this is something I’ll need to investigate further; especially when I want to integrate this with the Pluto-Charon kit I’m intending to use.
The ADLAM Pluto typically connects to your PC using a USB micro connector. When connected it establishes a virtual Ethernet network to allow your computer to connect to the device over TCP/IP. It also presents a USB storage device to allow you to edit config files. I’ve only come across one other device that does this, which was a Beaglebone Black Single Board Computer (SBC). This makes it very easy to connect, configure and use the ADLAM Pluto.
However USB cables are not typically long enough to reach the top of the tower or the back of ones dish. One trick the ADLAM Pluto has up it’s sleeve is the USB OTG support, meaning it can be both a USB peripheral and host device. This means we can connect a USB Ethernet adapter to the ADLAM Pluto and gain a real Ethernet interface, perfect for long cable runs !
Adding Ethernet
From the ADLAM Pluto University the OTG page lists a small number of USB Ethernet chipsets the stock firmware is compatible with. I wanted to use Gigabit Ethernet so went looking for an adapter that used the Realtek RTL8153 chipset. The device I ended up purchasing was a Waveshare USB 3.2 Gen1 Gigabit Ethernet Converter, from Amazon.
From various forums it was noted that the onboard ADLAM Pluto power supplies did not like feeding both the USB OTG Ethernet devices and the board at the same time. Instead a short “in-line” loom should be used, which I also purchased. You can see in the photo below how the USB “in-line” loom, Waveshare USB Ethernet and Pluto USB OTG port have been connected together. In this picture power was supplied from the PC (top right) but the data pins from the PC are not connected to either the Waveshare USB Ethernet or ADLAM Pluto. This works quite well.
Ethernet Configuration
To edit the configuration files we need to plug the ADLAM Pluto into the PC and edit the “config.txt” file on the USB storage device it presents. The ADLAM Pluto stock firmware can configure the Ethernet with a static or dynamic IP. I prefer to use a static IP in preference to running some form of DHCP/Zeroconf networking, YMMV.
Static IP Address
To configure a Static IP address edit the the following lines like so;
You will need to change your Ethernet address and Subnet mask to suit your own network, in which your PC will need to also be connected. If you intend to operate your ADLAM remotely via a VPN or similar, then you’ll need to add the default gateway as well like so;
Make sure when you have finished editing the config.txt file that you save the contents and then “eject” the ADLAM Pluto to ensure it commits it to internal flash.
Dynamic IP Address
To configure a Dynamic IP, simply leave the “config.txt” configuration files like this;
The ADLAM Pluto will then use DHCP to obtain an IP address when ipaddr_eth is left black, using this configuration is OK provided you have both DHCP and Zeroconf configured on your network like Avahi.
SDR Software
Don’t forget to reconfigure your SDR software with the new Ethernet Configuration, this can result in a short period of head scratching. For SDRangel I simply edited the device user arguments like so;
Now that the KK103c1 firmware is finished and capable of generating a 40MHz carrier that is phase locked to my 10MHz Rubidium reference, it’s now time to test everything is indeed working.
ADALM Pluto External Clock Input
So up until now I’ve talked a lot about the ADLAM Pluto Clock input, but as yet have not shown where it is or what it does. From the Analog Devices Pluto University the following image below shows all of the inputs and outputs on the ADLAM Pluto. I’ll be feeding the KK103c1 into the “CLK IN” port, which is one of those lovely UFL connectors that are difficult to plug in without glasses or hellish with fat fingers, sigh.
So to make sure the “CLK IN” will work, we can look closely at the schematic for the Rev-C/D hardware and see what is there.
As per my previous post, the Connor Winfield VCO was not happy driving into a 50Ω load. It would also appear that the ADLAM Pluto has the same input impedance provided by resistor R96. Looking at the output of the KK103c1 driving into a 50 load, I see the output drop to +/-0.46Vp-p which is only just above the minimum input of the LTC6957 buffer being used to re-clock this input. So while this works, I will need to revisit this level and look at if I increase R96 to 200R to improve the signal levels provided by the KK103c1. Good enough for government work at this point in time. There is also a capacitor value that I can change to balance the KK103c1 output signal with the ADF4110 REFIN pin, to be investigated further.
Test Setup
Once the External Clock Input was checked, the KK103c1 was connected by a short UFL-UFL lead to ADALM Pluto. I typically use a pair of tweezers and a microscope to get these things connected. The test setup is shown in the image below.
The 10MHz Rubidium reference was feeding both the Rigol external reference input and the KK103c1 module in the foreground. Again the Icom R10 was being used to listen to the carrier for any signs of instability, usually heard as clicks or warbling. I again used SDRangel to set the ADALM Pluto into transmit on 1296.5MHz wanting to keep this up towards the upper range of the Rigol scope so that any minor changes in the 40MHz clock would show up as error in the output frequency. I also deliberately de-tuned the VCO with the 10MHz reference not present to test that the PLL was in fact going into power down.
Internal vs External Clock Input
Below are the results from configuring the ADLAM Pluto to use it’s own internal oscillator vs the external 40MHz KK103c1 output. The following article from AMSAT DK goes through the process of switching the Pluto from it’s internal clock to external. The span has been reduced to 50kHz and the vertical scale changed to allow the spectrum analyser to find the peak. The results speak for themselves, that’s a lot of zeros.
As can be seen in the image above. With the ADLAM Pluto configured to use the internal oscillator, there is 15kHz of error in the output signal, that simply disappears when clocked using the external 40MHz source. This was confirmed having to re-tune the Icom R10 to follow this change in output.
I’m certainly pleased with this result.
Carrier Spurs from external clock
It is typical to see Spurs appear if the reference oscillator does not have a clean or jitter free output. Widening the span to 10MHz and 100MHz respectfully, the output of the ADLAM Pluto remained spur free. Well at least within the limits of the Rigol DANL. There is some close in phase noise that needs to be checked with better equipment and perhaps when boxed.
I still have to investigate the phase noise from the KK103c1 module when the opportunity presents. I will also be investigating the harmonic output of the Pluto Charon at the same time that phase measurements are made, the poor old Rigol is limited to an upper frequency limit of 1500MHz. Unfortunately the Rigol Spectrum Analyser is not quite metrology grade lab equipment, so this will all have to wait for a bit longer.
Now that I have the output of the ADLAM Pluto locked to my Rubidium source, it’s time to begin boxing this up into an enclosure with the Pluto Charon kit and finishing my 23cm all mode digital SDR radio.
In a recent post I was fortunate to obtain a 40MHz VCTXCO module from David VK5KK that I am using to lock an ADALM Pluto to an external 10MHz reference.
David’s design uses the Analog Devices ADF4110 RF Frequency Synthesizer, which offers low phase noise and operation up to 540MHz, more than enough for this application. It was also conveniently packaged as a daughter board for an Arduino Nano.
However upon entering the keywords “Arduino ADF4110 library” into Google & Duck-Duck-Go I was not greeted with any results. Oh dear, I have to write a library myself how strange ! Time to dust off my Arduino development environment.
I am not intending to describe how a Frequency Synthesizer or Phase Locked Loop (PLL) works, there are many YouTube videos and articles on the internet that can describe this better than I. If you are interested in the KK103c1 40MHz VCTCXO module I’m using, you can find it published in Dubus Q3/2022, there David also goes into some detail of how it works.
For this Arduino library the ADF4110 contains three internal 24-bit latches, where we can program the necessary values into counters and configure the hardware to generate the desired frequency output. This is achieved with a series of bit-shifting and bit-manipulations macros within the code, I have followed the names and bit-naming structures as per the Analog Devices ADF4110 datasheet.
The ADF4110-Arduino library essentially consists of five functions, that are described in the README.md. There is the ubiquitous Arduino “begin” function used to configure the SPI communication between the ADF4110 latches and Arduino Nano, there is an “initialise” function to load & initially configure the hardware of the synthesizer, an “update” function to simply change frequency and two utility functions to “print” the frequency to the serial console and another to “powerdown” the synthesizer when necessary. This was all I needed to get my synthesizer going, it should all hopefully be self-explanatory.
Now that I have the ADF4110-Arduino library essentially working, I can now focus on using this to drive the KK103c1 module but that is for another post.
