HAB Telemetry – Design & Evolution

Posted on by
Reply

In a recent post I wrote about experiments with a Pine A64 running the Project Horus 4FSK binary and Wenet decoders. The next steps were to work out exactly I was going to build.

Systems Diagram

Designing systems is an iterative process, you start with an idea and then modify and adapt as pieces are found and problems are solved. From the outset I wanted to build a HAB Telemetry system that could track the majority of telemetry that the Project Horus Balloon flew, this being the primary and secondary 4FSK binary telemetry and Wenet. There are times when primary and secondary Wenet systems are also flown, so allowances for two Wenet decoders were made.

I wanted this system in a box, that I could take out of the car, place on a table, switch on and magically decode the telemetry from the Balloon. Having everything setup, configured and running, before going into the field, means that less time is lost debugging faulty cables, forgetting where and how to plug things together or worse still chasing down rogue software updates.

A picture speaks a thousand words, so below is a block diagram of what I proposed to build, that would suit my needs above. This was a culmination of the equipment I found rummaging around in my shed, rediscovering more treasures and realising I had only two Pine A64’s and needed three.

Design Evolution

The first “prototype” system was thrown together for the Horus 58 flight, which consisted of the two Pine A64’s I had, some RTL-SDR’s and some Mikrotik routers to get the data out and onto the internet. Here you can see some “design for but not with”, where I’ve left a space for a third Pine A64 that I was yet to find.

On this “first” flight I was rushed for time and didn’t have time to sort out an antenna. I usually track balloons with Peter VK5KX, so I was intending to plug my box into his beam, but due to leaving a RF adapter behind, I instead used a separate 70cm Turn Style antenna mounted to the side of Peters car. Both Peter and I were surprised just how well this simple antenna worked, so the whole idea of a Turn Style antenna, remote mounted preamp sitting a top an Aldi Bike Stand was born. You can see this antenna system I built for the SHSSP 2023 flight below, again all from my junk box and rediscovered treasures.

Knowing that I needed another Pine A64, I reached out within my local radio club to see if any of these SBC’s might be languishing on other junk boxes. I’ll give a shout out to Josh VK4JNA who gifted me the third Pine A64 in the photo below. It too was the KickStarter model sporting 2GB of RAM and came with the optional WiFi interface.

It was also during these first flights both Horus 58 and the SHSSP 2023, that after a period of time the software decoders would crash or lockup and stop responding. This wasn’t hard to find by placing ones finger on top of the processor, they were getting too hot and were thermally throttling the clock until the software maxed out the processor and crashed. This was more of a problem for Wenet systems than the 4FSK binary telemetry. Adding some stick on heat sinks didn’t improve things either, it just let them run for a further 10-15 minutes before crashing again. So it was from this that the PineA64Fan project was started, that added a separate software controllable Fan and a DC-DC converter. I’ll go into further detail about this fan controller and power supply in a later post, as it on it’s own has a great story to tell.

I was also thinking of how to power this unit in the field without purchasing a separate Lithium battery. I was watching YouTube one afternoon when I saw someone powering their 100W HF Radio from a Ryobi 19V battery using a DC-DC converter. What a great idea !!! When designing the PineA64Fan I used a DC-DC converter that matched the Mikrotik router input voltage range of 9-30V DC. This meant everything in the box would work nicely from from my 19V Makita batteries I have for my power tools that sit in the shed and are only used on weekends. With 90Wh of storage, this could easily power this entire box for the duration of a balloon flight, which is typically 4 hrs or less.

So below is the photo that finally realises the system diagram above.

Here we have three Pine A64 SBC’s each with their own RTL-SDR. There are Mikrotik routers to connect the software decoders to the outside world and let them upload the data to the internet. All three Pine A64’s are rocking custom DC-DC converters and software controllable fans, that chime in and out as the processor temp gets above 50°C. As can be seen in the lower right of the case a Bias-T DC injector is used to power the LNA up by the antenna and the SDR’s are connected by a surplus 4-way splitter. Perfect, at least for now.

Next Steps

The system above was realised just before the Horus 60 flight in August of 2023. Which was a special event to celebrate the Amateur Radio Experimenters Group 25th Anniversary. For the eagle eyed reader, you may notice in the Bias-T wiring is not quite finished and that in the Horus 60 write up my callsign does not feature prominently in the logs.

I’ll continue this story and the reasons for the above however in a latter post…

ADLAM Pluto TX Leakage

Posted on by
Reply

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.

However that will have to wait for a later post.

HAB Telemetry – Initial Experiments

Posted on by
Reply

In a recent blog post I talked about finding some Pine A64 single board computers in a box and how this was the catalyst for my High Altitude Balloon (HAB) Telemetry experiments. In this post I continue describing the initial experiment with the Pine A64’s to test if they were capable of running the Project Horus software.

Pine A64 Operating System

So the choice of Linux operating system for the Pine A64 2GB SBC had grown substantially since the first time I experimented with these boards after the initial KickStarter campaign. After some trials and tribulations I settled on the DietPi distribution. This included a relatively modern kernel and a nifty installation and package management system, with a Debian based back-end. It is also highly optimised to run on small SBC’s, it only runs the bare minimum processes required and has logging to RAM enabled rather than to SDCard.

Setting up DietPi on this board was no different to any other ARM based SBC. Burning the image to SDCard, booting the device with a USB keyboard and monitor was straight forward. One nice part of DietPi is the setup and configuration is done within a Ncurses menu, similar to the raspberry Pi. So tuning and setting up the board just requires poking around these menus and configuring the hardware you want to use. Once done I found I was using just under 1GB of the 32GB SDCard I’d inserted, which included all of the GCC build tools I needed to compile programs from source. I was impressed.

Tracking Software and SDR’s

The first HAB tracking software I wanted to try was the Horus 4FSK binary telemetry. The Project Horus software team have done a great job documenting how to build and run this software in their GitHub wiki. The Horus guide recommends the RTL-SDR if you intend to run a Headless Raspberry Pi and I had a draw full of them left over from various projects. If you’re not familiar with these you can find them here, please be aware of fakes on eBay the frequency stability of these fakes typically results in tears. I’ve used the RTL-SDR V3 as pictured above.

It didn’t take me more than an hour to get this software running which included building the RTL-SDR software from source, editing the startup scripts and testing that dual 4FSK de-modulators were running. I was lucky to have a RS41 radio sonde that had been modified to generate this data mode, more detail can be found here. I was thankful that the DietPi distribution is very similar to the current Raspberry Pi platform, so all commands simply worked, those that didn’t required nothing more than installing the missing package or dependency and trying again.

Running both Horus 4FSK binary telemetry decoders on DietPi saw the system peak load get no higher than 0.6 (~15%), considering that the Pine A64 is a quad core 1.2GHz ARM, this is very lightly loaded. There is definitely more scope to add further functionality on this SBC.

So having cloned the SDCard just prior to installing the Horus 4FSK binary telemetry software, I then started again a fresh on the second Pine A64 and installed the Wenet software. Again the installation documentation for Wenet is excellent and I chose to go the Docker path rather than build from source. This time however the system peak load, rose to 1.6 and peaked no higher than 2.5 (~63%), meaning a single Docker Wenet decoder is about as much as I was confident loading this system with using a RTL-SDR.

Next Steps

So based on the above experiments, it was clear the Pine A64’s that spent the better part of 5 or more years languishing in my shed were more than capable of tracking HAB balloons and would finally be pressed into service.

As hinted within the Project Horus documentation there is more than just software required to track High Altitude Balloons. It was time to continue digging through that shed to find more treasures for this new project.

That however will need to wait for the next post, more to follow.

SDRangel Simple PTT plugin

Posted on by
Reply

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.

That will however have to wait for a later post.

HAB Telemetry – Introduction

Posted on by
Reply

As with all of my projects, they typically start by finding a crucial piece of kit that then sparks a whole development. Back in late 2022 I was searching through my shed for something when I happened upon a box of Pine A64 single board computers, that I’d completely forgotten about.

These were purchased from a Kickstarter campaign when 64-bit ARM was in its infancy and 64-bit ARM Linux distributions were not common. These new machines were difficult to get going, which is likely why they ended up in the shed. Needless to say, that box was pulled from the shed and sat on a shelf in my office until inspiration struck… could I build them into a High Altitude Balloon (HAB) telemetry tracking system ?

I’ve been involved with the Project Horus High Altitude Ballooning (HAB) group since August of 2010, my first flight was Horus 7 where we watched it land at our feet just shy of Pinnaroo in the North Eastern region of South Australia. Fast forward some 15 or more years and I’m still out there tracking balloons, having retired from actively chasing after them a number of years ago.

Over time much of the software for tracking these balloons had been ported to various flavours of Python from the original implementations in Java. For better or worse it has meant that this custom tracking software has migrated towards running on small embedded ARM single board computers. In late 2022 I’d heard that some within the Project Horus community were tracking balloons with Raspberry Pi’s and SDR’s, so here was the catalyst for some inspiration and I started to wonder if my original Pine A64’s were up to the task ?

Over the Christmas break in 2023 I cobbled together my first ARM based system and I’ve been experimenting with my High Altitude Balloon Telemetry System ever since. This work has been done on and off, when ever I was able to catch a few hours or days. The main focus typically came a few weeks before an actual balloon launch. This series of blog posts will document what I’ve learnt and how I’ve gone about setting my system up to current time.

More to follow.

ADLAM Pluto USB Ethernet

Posted on by
Reply

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;

[USB_ETHERNET]
ipaddr_eth = 192.168.73.10
netmask_eth = 255.255.255.0

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;

[USB_ETHERNET]
ipaddr_eth = 192.168.73.10
netmask_eth = 255.255.255.0
gateway_eth = 192.168.73.1

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;

[USB_ETHERNET]
ipaddr_eth =
netmask_eth = 255.255.255.0

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;

Enjoy !

ADALM Pluto Atomic Locked !

Posted on by
Reply

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.

ADLAM Pluto output, external 40MHz clock, 50kHz span
ADALM Pluto output, Internal Oscillator, 50kHz span

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.

ADLAM Pluto output, external 40MHz clock, 10MHz span
ADALM Pluto output, external 40MHz clock, 100MHz span.

Next Steps…

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.

Onwards and Upwards !

KK103c1 Firmware Development

Posted on by
Reply

Continuing with the development of an accurate 40MHz clock source for my ADALM Pluto, I recently finished an Arduino library to control the ADF4110 Synthesizer on a KK103c1 VCTXCO module. The KK103c1 module is a daughter board that sits on the back of an Arduino Nano.

I personally use the PlatformIO IDE extension within Visual Studio Code for all of my Arduino based projects. Yes, this even works on a Linux desktop machine. The PlatformIO ecosystem takes away the pain of getting embedded tool chains working, it’s simple and effective. I also don’t have to worry about tool chains that share libraries and break when incompatible versions are installed, and it deals with the library dependency hell problem that plagues the standard Arduino IDE.

Now that I was armed with a library that gave me basic control over the ADF4110 I could concentrate on writing a sketch that would make the KK103c1 do what I wanted it to do.

The code for this project has been published in my GitHub repository, you can find it here. The code has been released under a MIT license.

Firmware Description

The firmware is very simple and provides “just enough” functionality to allow the KK103c1 to externally clock the ADALM Pluto.

When the firmware starts it will load and configure the ADF4110 Synthesizer found on the KK103c1 module and set it to generate a fixed 40MHz unmodulated carrier, that is phase locked to its own 10MHz reference. It also checks that an external 10MHz reference is present using the diode detector on the KK103c1 and will flash the built-in Arduino Nano LED if not found. The MuxOut pin on the ADF4110 is also set to provide a Lock Detect output and a Green LED on the KK103c1 will burn your retina when the Connor Winfield VCO is locked on frequency.

If the external 10MHz reference is not detected or lost during normal operation, the sketch will also place the ADF4110 into power-down allowing the onboard VCO to “free-run”. The Connor Winfield VCO fitted to the KK103c1 is very accurate and stable on its own, so having the VCO free-run will see it hold +/-0.32ppm (+/-13Hz) over temperature, over a 1% voltage range including aging within a 24 hr period. The KK103c1 has a multi-turn pot that can rubber the VCO control voltage and trim the output to exactly 40MHz before the PLL has to do anything, this is a great feature for those that take their equipment out into the field.

The control range or “frequency pull-ability” of the Connor Winfield VCOs is specified as +/-12ppm which translates to +/-480Hz, so it is normal for the ADF4110 to reject the 10MHz reference if it is not within the same accuracy window. I commonly see the lock LED on the KK103c1 begin flashing as my Rubidium 10MHz reference is warming just prior to achieving it’s own atomic lock.

A PC can be connected to the USB serial and debug messages monitored that shows if the ADF4110 is locked or in free-run.

Pluto 40MHz Reference Oscillator - R0V1
---------------------------------------
* Checking Reference Oscillator level.......... Done !
* Starting kk103c1 ADF4110 PLL...
* ref freq = 10000000 Hz (detected)
* vco freq = 40000000 Hz (locked)
* Config complete.

Further debug messages can be enabled in the ADF4110-arduino library, look closely in the library header.

Testing Pluto 40MHz External Clock

So the proof is in the pudding. Below are images of the KK103c1 running my Pluto40MzExternalClock sketch along with plots from the spectrum analyser, as you can see I’m using my 10MHz Rubidium as the reference oscillator.

In the spectrum analyser plot above you can see the 40MHz oscillator “locked” to the 10MHz Rubidium reference holding the output frequency to better than +/-1Hz accuracy. The Spectrum analyser was also being fed from the same reference source, to ensure it wasn’t causing any additional error. This was also checked with my Agilent frequency counter again being fed by the Rubidium 10MHz oscillator.

One thing I have noticed is that the output of the KK103c1 was being loaded by the 50Ω input of my Rigol Spectrum Analyser. The Connor Winfield VCO has an internal series impedance of 200Ω so this behaviour is to be expected. I’ll have to look closely at the ADALM Pluto external clock input and see if I can change component values to suit.

With a working 40MHz clock, phase locked to my 10MHz reference, it’s now time to hook this all together and see if I can improve upon the ADALM Pluto frequency accuracy.

More to come.

ADF4110 Arduino Library

Posted on by
Reply

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.

ADALM Pluto Frequency Accuracy

Posted on by
Reply

In a recent post I had my ADLAM Pluto transmitting using SDRangel on 1296.5MHz listening to it using an Icom R10 receiver. One thing that I did immediately notice was I had to tune the R10 down 15-18kHz to get both systems “on” frequency. One or both of them had to be off frequency, so which one was it ? After a few measurements with a spectrum analyser, I found the ADALM Pluto was the culprit, surprisingly the Icom R10 was within a 100Hz of where it was supposed to be.

So… the ADALM Pluto was at least 16.667kHz low using its internal 40MHz crystal reference, that is not going to cut the mustard on these higher bands.

I had always planned on phase locking the Pluto to an external 10MHz Rubidium reference. The only catch is the external reference input on the Pluto expects a 40MHz clock and the AD9361 transceiver within the Pluto, cannot be configured to use a reference clock much below 25MHz. So there was no way I was going to make this work with a 10MHz reference without adding something in between.

After some further research I decided I needed a 40MHz VCO that I could phase lock to the external 10MHz reference to solve my problem with the Pluto external clock input. A chance discussion at a conference in Tasmania at the end of 2024 lead me to laying my hands on a KK103c1 40MHz VCTXCO PCBA designed and built by David VK5KK.

David’s 40MHz VCTCXO design was published in Dubus Q3/2022. It was designed as a daughter board directly connected to an Arduino Nano, that it conveniently sits on top of. The specs for this board were perfect for what I was planning to do with the Pluto external clock input;

Ref In:     10MHz, -4dBm to +14dBm
Output:     40MHz ~1.0Vp-p (into 200R)
VCO:        Connor Winfield T604
PLL:        Analog Devices ADF4110
Micro:      Arduino Nano ATMEGA328p

Both the VCO and PLL are low phase noise varieties and the power supply decoupling is extensive. I was even given a basic Arduino sketch that I could use to test the board, that is provided I had an Arduino Nano. Oh well Nano ordered and should be here soon.

Certainly once I have this board running, I’ll be doing some phase noise measurements and experiments with my Rubidium 10MHz reference. It will be interesting to see what improvement I get in frequency accuracy, along with comparing the phase noise of the internal Pluto clock and seeing if there are any differences. However before this I’ll need to write some Arduino code to tailor this board for my purposes and perhaps a library to drive the ADF4110. That will of course land somewhere in my GitHub repository when ready.

I’ll give a shout out and my personal thanks to David VK5KK for gifting me one these boards and accelerating my ADLAM Pluto project. I certainly can’t wait to get to testing once the postman delivers a Arduino Nano. I know I’ve got some Nano’s somewhere, but for the life me of I can’t find that box.

More to come.