The shaving of the Yak progresses, it's now making noise! Before you get too excited, the noise is one-way, it's barely distinguishable from hash and it's fragile, so keep that in mind as we dive into the world of .. something.

If you have no idea what I'm talking about, you're in good company, half the time I'm struggling, but today I'm working on a project to bring software defined radio to the masses, well, radio amateurs who haven't dipped their toes yet and I'm calling this effort Bald Yak.

In case you're unfamiliar, the Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio. It's called Bald Yak because by the time I'm done, the Yak is likely well and truly shaved.

So, last time we congregated around the campfire I discovered that what I need to build is something that has a collection of things that talk to each other across a network. Seems pretty obvious now that I say it, but it wasn't always that way, remember, I'm inventing this from scratch, or so I tell myself. I will note that the deeper I dig, the more it looks like a lack of documentation, which really comes with no surprise, but I persist, if only to determine that it can be done, that I can do it, and that I understand how it works.

The underlying drive for all this is for me to gain a deep understanding of the whole ecosystem, since I firmly believe that we're well and truly committed to software driven radio.

So, what did I discover? First of all, thank you to all of you who sent messages with your own ideas on how to make two devices talk to each other. I explored at least a dozen of them.

I'll give you some highlights. First cab off the rank is OpenWebRX, radio in a web browser, very popular. I installed it, ran it, configured it, got noise, was able to pick a band across the network and decoded plenty of stuff. Looked like a contender until I discovered two significant issues. One is that it expects a menu entry for each slice of frequency range, with 2.4 MHz being the widest possible for an RTL-SDR dongle, so its 1.7 GHz range would need 708 entries. Someone made a good start, but if you want to tune to something that overlaps two entries, you need another menu entry. Then there's the weird flex that it doesn't decode FM Broadcast in stereo. There's a whole description on why not, but I lost interest. I also tried OpenWebRX+ which adds a bunch of functionality, but not enough to overcome those fundamental problems.

I explored several other web based tools, one looked really promising right until it demanded that I install some random binary off the Internet .. hard pass.

I didn't go down the path of AllStarLink across the room, mainly because I have no desire to start the rounds of configuration, or manage the lack of ability to change frequency, to name two issues.

I did fire up RTL-TCP and managed to connect to it from my Mac using SDR++, it even worked, but boy, the SDR++ user interface is hard work, too many buttons and not enough consistency, like why do I need to set the gain for each mode, and why doesn't it support SoapySDR on MacOS?

RTL-TCP is a tool that essentially puts an RTL-SDR dongle on the network. It's excellent, once you figure out how to make it work inside Docker, has great documentation, talks to GNU Radio, everything you'd want, except that it's only one-way and it only talks to RTL-SDR dongles.

I started comparing SoapySDR to RTL-TCP and then landed back with SoapySDR, since it does the same job, with a bonus that I discovered by accident, since the documentation is .. let's call it .. challenged.

One of the things that people who contacted me missed, probably because it was obvious to me, was the notion that I want to use automatic service discovery, something that has myriad names, ZeroConf, Bonjour, Avahi, mDNS and plenty others. I tried many of them as search terms with GNU Radio and found nothing.

Then I tried the same with SoapySDR and discovered that it supports mDNS out of the box. It's not something I'd seen before, since all the examples I found previously hard code an IP address into the flow graph, which means that it might work on my computer and network, but it won't work on yours until you change things, hardly something I want to inflict on unsuspecting users.

So, the way it works is that you run a thing called "SoapySDR Server" on the machine with the RTL-SDR dongle, and GNU Radio running Soapy Source with the remote driver can find it .. most of the time. There's still plenty of hair pulling here, a flow graph that ran yesterday stopped working today, until I rebooted the server twice, no other changes, so fun.

To be honest, it feels a little like Windows 95 Plug and Play, or as we used to call it, Plug and Pray, excellent idea, shame about the implementation.

Then I came across a flow graph by Handiko YB1SDL who created a git repository with the title "How to Stream the Audio Out from GNU Radio into VLC Media Player" .. which of course was catnip to an aspiring geek like me.

Turns out that VLC can listen on a UDP port and GNU Radio can send data to it. The quality of the audio is very poor as noted by Handiko, but I think that's due to neither of us understanding how to scale it properly, but that's par for the course.

So, right now I have three devices talking to each other, a SoapySDR Server with an RTL-SDR dongle on a single board computer, a GNU Radio flow graph running in a Docker container on my main server, and VLC running on my Mac.

What does this buy me?

Well, the Mac audio is a bonus, I'd like to be able to listen to the radio, but GNU Radio talking to an unnamed server that's just sitting on the network is precisely what I envisaged when I started this whole malarkey.

Mind you, it's not stable enough to show and tell, and I have no idea what it does if there's more than one radio on the network, but that's more opportunity to explore.

I'll also note that this is precisely why I'm doing all this in GNU Radio, so I can learn how it works.

There's one other thing. I'm documenting all this so it inspires you to start playing with this ecosystem, because ultimately I picture this environment as the radio equivalent of a massive bag of LEGO scattered all over the living room floor, something which brings me all kinds of joy.

So, what are your GNU Radio adventures like, and what have you tried and where are you stuck?

I'm Onno VK6FLAB

After spending a full day banging my head against a wall, again, this morning I hit on a phrase that hadn't occurred to me, "peer-to-peer audio" and with it came an insight into the problem I've been working on since I conceived of Bald Yak. In case you're unfamiliar, the Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio. It's called Bald Yak because by the time I'm done, the Yak is likely well and truly shaved.

While it might seem superfluous rehashing my frustrating day, I think it helps to describe more fully what I'm trying to achieve, so bear with me.

It started with me needing to have music to listen to. I normally stream something off the Internet, "SBS Chill" if you're interested, but having a shower thought, it occurred to me that I might create a spreadsheet of the things I could hear via RF in my shack. It's been a while since I was on any frequency other than the local VK6RLM repeater where I host F-troop, and I wanted to get back to doing some more hands-on radio.

After listening to "ABC Classic FM" on my amateur radio transceiver, I scanned up and down the FM broadcast band and heard plenty more stations. The audio wasn't cutting it, I mean, who wants to listen to Claude Debussy or Wolfgang Amadeus Mozart performed in glorious mono?

I thought of using an RTL-SDR dongle to do the tuning and listening, the tool "rtl_fm" is perfect for the job. One problem. How do I get the audio from the device with the dongle, to my ears? I suppose I could plug in a pair of speakers and have at it, but I'm not alone and my office is central to the house, so anything here is heard everywhere. Headphone cables are too short and my antenna is also on the opposite side, so challenging.

Mind you, I already bridged this gap once with RemoteRig, which essentially replaces the serial cable between the head and body of a radio with a network connection, for me that's across the room, but it could easily be across the Internet.

All of this is complicated by my current computing set-up. I'm typing on a keyboard connected to a MacBook in turn connected to an external monitor. That monitor is also connected to a Debian Linux computer running Proxmox where my old workstation is running in a virtual machine and in the process of being resurrected. It also runs several other virtual machines where I'm running GNU Radio in a Docker container.

One noted absence from that setup is audio.

Right now, I record my podcast audio onto a Zoom H5 handheld recording studio in my wardrobe, then transfer the audio file to my old workstation where all the scripts live to make my podcast live. I edit the audio by launching Audacity on the Mac and opening that file across the network. I hear the editing through the Zoom H5 re-connected to the Mac as a sound-card. Otherwise audio is non-existent, not excellent for listening to radio or anything else for that matter. Ideal, no, not even close, but that's just one example of still recovering from my hardware crash over two years ago now. Mind you, audio was already challenging with software running inside Docker, but that's a whole other thing.

I spent the day looking for ways to get audio across the room. I played with "ffmpeg" and RTSP streaming, only to discover that you need to install and configure more software in the form of a server, which is no longer included with ffmpeg. Also, apparently for reasons best understood by Apple, QuickTime Player no longer supports RTSP URLs, so go-figure.

I looked at "pipewire", apparently needs a GUI to configure it, needs extra software installed and doesn't appear to be readily cross-platform, though I didn't dig too deep once I discovered the GUI requirements, I might come back to it.

I explored running a Bluetooth audio server on a Raspberry Pi to stream audio to my headphones, much like I'm listening to right now, but that too seemed cumbersome, and included all manner of pairing, trusting and ad hoc piconet interactions that didn't fill me with joy. I suppose I could run a virtual USB cable across the network using "USBip Hot Plug" between two Raspberry Pi's and have a go, and I might still try that.

Ultimately I didn't find anything that came close to a real solution to fix my audio issue, but this morning it occurred to me that essentially the thing I was looking for needed to be two-way, since if I'm going to make this work, Bald Yak would need to deal with a received signal as well as a transmitted one.

For reasons I don't understand, let's call it my ah-ha moment, I imagined a picture of blocks scattered about, each doing their own thing and signal lines travelling between them. The phrase "peer-to-peer" came to mind and I started searching. I came across a tool called "SonoBus", a cross platform open source application that allows users to create a distributed network of audio users, specifically supporting both recording and playback. Looked excellent, right until I discovered that the last release was three years ago and there were 178 pending issues and 17 pull requests. Mind you, looking at it again now, there are branches that were updated less than three months ago, so it's still being developed and ultimately why I'm mentioning it.

I toyed with the notion that I/Q signals are essentially two channels per sample, much like an audio stream is a left and right channel, so there was the possibility of shoehorning a radio signal into this platform, right until I realised that I need to still do weird stuff like change frequency, mode and perhaps antenna and the like.

So, we're back to square one, but with it comes an understanding that part of Bald Yak is going to need something that does peer-to-peer signal streams.

That gives me a description of what it needs to do. Essentially pipe data across the network between devices. It should be lightweight, offer the choice of lossless or lossy streams, since a command needs to be guaranteed to get to the other end, but you might decide that audio doesn't. It should be cross-platform, needs to be network and device agnostic, should follow Unix philosophy where programs do one thing and do it well, work together and handle text streams, because that is a universal interface.

Mind you, I suspect that a text stream in this case is going to be a byte stream, but that's beside the point.

It might transpire that such a thing already exists, "netcat" comes to mind for example, which if true would progress my efforts one step closer.

All in all, it's been a good week.

I'm Onno VK6FLAB

On the 15th of May, 2011, my amateur license still wet, I started documenting my experience with my newly adopted hobby. Now, sixteen years and 800 episodes later, I'm still at it. In reading my initial words from all those years ago, it strikes me that the impetus for that adventure is still with me today.

In the intervening years much has changed and evolved. Some less so.

First some history.

I started this documentation process as a response to a new amateur who bemoaned the power limits of their license. At the time, it wasn't an isolated event, just the final straw. Regular disparaging and derogatory comment was levelled at this "toy" Foundation license, the one I'd just obtained and the one I was exploring.

As it happened, I made an observation about this whilst volunteering to help with the production of the local amateur radio news. Ever keen on more content, I was encouraged to voice my concerns into a microphone and my journey began with something I whimsically called "What use is an F-call?", F-call being the colloquialism for the Foundation call, the introductory license in Australia. Recording done, I transcribed my words and the first episode was committed to disk.

Since then I've written all episodes, then recorded and edited them. For just over four years, 206 episodes, I shared my experience and learned as I discovered more things to do and play with. Audience numbers were growing and I started receiving emails from listeners around the world. I renamed my efforts into "Foundations of Amateur Radio", still a nod to my Foundation license origins, but only if you were in the know. The content was the same, with one slight difference, I didn't assume that the listener was based in Australia, mind you, every now and then, I get an email asking about some word I used, but I think that's half the fun.

Given that all this is being done manually, over the years I've made some errors with track numbering in my audio files, so it took me some time to work out what the actual episode number for today's effort is. I'm in the process of renumbering all of them, so it's consistent, but that's fraught, since all of my contributions have been archived all over the place, including in the Digital Library of Amateur Radio and Communications, the DLARC, so I have some things to figure out. Suggestions welcome.

Over the years much of my amateur radio activity has been triggered by the need to write a new article before my self-imposed deadline. While that sounds like it's backwards for a person claiming to document their journey, it's given me a framework to keep exploring, asking, learning, trying and attempting to explain and encourage.

As a consequence, I get the opportunity to talk to nascent amateurs during their course and one thing I mention is the sheer volume of activities associated with this hobby. Sparked by something I've noticed new amateurs appear to experience regularly, around two years or so into the hobby, they get to the point of boredom, "What else is there to do?", they ask. I point out that I too hold a Foundation license and based on my experience, I've yet to find an end of things to try and experiment with.

Deadlines and Yak shaving aside, my amateur experience has not been without its testing times. Several instances of bullying behaviour occurred over the years which are not fun to experience or witness. I've seen amateurs leave the hobby because of it and if you're ever the target of such behaviour, reach out, cq@vk6flab.com is my address. I can't fix things, but I can listen.

One thing to observe about bullying behaviour is that it's often intense and confrontational. It's easy to forget that the vast majority of radio amateurs are lovely people who share your particular interest in all things RF to greater and lesser degree. In other words, don't let it define you if you're in the middle of this.

It does make me want to make mention that there are still amateurs around who think that racism and misogyny are accepted forms of communication and behaviour. Fortunately they're slowly becoming extinct, but you'll find pockets here and there.

What of the future?

My journey is well and truly on the path of Software Defined Radio. It's probably fair to say that the number of such radios across the planet today far exceeds the number of "hardware" radios ever built, even if you only count mobile phones. I think that the nature of software means that we can build any future we imagine and change it when the need arises.

I think that my experiments with 10 mW beacons point at the potential for other new forms of global communication, like JTTY, a new weak signal mode announced on 23 September 2026 with the release of WSJT-X v3.2, in much the same way as over a century earlier on the 2nd May 1925 amateurs proved they could communicate with any part of the world at any time of the day or night, when Ernest J. Simmonds G2OD and Charles Maclurcan A2CM made a daylight contact between England and Australia on what we now call the 20m band using 100 Watts.

While we build that future together, permit me a moment of thanks.

Your emails, messages and words of encouragement mean the world to me and it's a pleasure to see what you've been up to and learn from your experience. Thank you, it's very much appreciated.

So, what have you been up to in amateur radio this week?

I'm Onno VK6FLAB

I've been in this hobby since 2010 and this is the first time I've ever heard of this.

More than seven years ago I first uttered the phrase: "I/Q", and palmed it off to future me with "we should look at that [at] some other time". Since then I've referred to it several more times and all but vaguely waved my hands about.

Today I'm going to poke the bear called "I/Q" and to be clear, this is a signal term meaning "In-phase and Quadrature" not "Intelligence Quotient".

Most explanations I've seen jump into the mathematics of this concept, but none ever spoke to me at any fundamental level.

Ultimately, a simple phenomenon underlies all of the magic that hides behind the concept of an "I/Q" signal. So, let's explore.

When you digitise a signal, you essentially record a voltage each time you take a sample, which can happen many millions of times per second. The aim of this process is to create a digital representation of an analogue signal for the purpose of doing something with it, like decode it. This process happens in billions of devices across the planet.

In its simplest form a signal is a sine wave that starts at zero and oscillates between one and minus one. You might recall that a sine wave is associated with degrees in a circle and that each angle shares the same sine value with another. For example, the sine of 30 degrees and 150 degrees are the same, 0.5.

This means that the value of 0.5 could represent 30 degrees, but it could also represent 150 degrees, which means that our digital representation of a sine wave is incomplete.

A cosine wave has all the attributes of a sine wave. If you were to draw them together you'd notice that its shape is identical but shifted in time and because we're talking about angles, it's delayed, or phase shifted, by 90 degrees.

What if you sampled both waves .. at the same time?

Doing so removes all angle ambiguity. By convention, the I in "I/Q" represents the In-Phase or cosine signal and the Q in "I/Q" represents the Quadrature or sine signal. And while we're in the business of naming things, signals that are separated in phase by 90 degrees are "in quadrature".

So, what does this buy you, or why does it matter?

As it happens, you can represent any radio modulation as an I/Q signal. While until now I've talked about digital signals, all this applies to analogue signals, and it applies to transmitted signals as well.

Final piece of the puzzle. To create any modulation from an I/Q signal, all you need is to vary the amplitude of each of the I and Q signals, which means that you can do this with analogue circuits as well as in software using cheap hardware.

If you've looked at this phenomenon before, you might wonder why I haven't said anything about "complex numbers" yet and if you haven't, those words might scare you off. The concept of "complex" really refers to the idea of embracing two numbers within, for example, it can represent an arrow with a length and a direction. Our I/Q signal, which consists of two numbers for each sample, can also be represented as a complex number and it's one of several ways to represent an I/Q signal.

One final comment. You can create an I/Q stream from an RF signal by mixing it with a so-called quadrature mixer, one that outputs two signals, 90 degrees out of phase.

Now, I will add that I had porridge for breakfast and I'm operating on five and a half hours of sleep, but I'm fairly confident that I covered the foundations of an I/Q signal in less than four minutes and I even had time to tell you what I had for breakfast.

For my next trick, I'm going to tell you how to make pancakes with just a banana and an egg.

I'm Onno VK6FLAB

Today we celebrated the 800th edition of F-troop, the weekly net for new and returning amateurs.

While I've hosted most of them, I couldn't have done it without the amateur community who checked in week after week to share their stories and ask questions, sometimes even finding answers.

This week I asked a different question.

"What was the impetus for you to join the amateur radio community?"

We learnt lots and had plenty of laughs!

Thank you all for joining me for the past 15 years!

73 de Onno VK6FLAB

The radio telescope at Dwingeloo in the Netherlands recently promoted an Open Day where visitors were treated to tours and live demonstrations. One video caught my eye, a 2.4m dish on a remote controlled azimuth and elevation mount that scanned the entire sky every fifteen minutes and afterwards created a map of the captured radio signals.

Having carried a dish that size around Australia for a couple of years, I was in awe. After I figured out how you'd create the map I was grinning. Essentially your program moves the dish through all the elevation and azimuth combinations while recording RF for each. Mapping becomes the process of drawing a representative dot at each location, and in doing so you have the basics of a radio telescope.

It gets better.

Imagine two identical antennas, side-by-side, receiving the same signal head-on. The combined antenna signals are said to be "in phase" and will reinforce each other, resulting in an amplified signal.

However, if the source is off-centre, its signal arrives at the closest antenna slightly before the other and that delay, or phase, between the two will cause their combined signal to appear weaker or attenuated, because they're no longer entirely reinforcing each other. These signals are said to be "out of phase".

If you were to add a slight delay to the earliest signal, or said differently, change its phase, the two would again appear to arrive at the same time, be in phase, and again reinforce each other.

In doing so, you've essentially modified the focus of the antenna toward the off-centre signal by adding this delay or phase shift, and so by modifying the phase, you can shift the antenna focus. Just so we're clear, there's no actual moving parts here, we're electronically adding a phase shift to adjust the delay between antenna signals.

In addition to changing the phase of any of the antenna signals, you can alter how much each antenna contributes to the combined signal and when you do that, you'll change the radiation pattern of the system.

You might ask: "Does all this apply to receive or transmit antennas?", to which I'll say: "Yes".

This arrangement of antennas is called a "phased array" and was first demonstrated as a three element array in 1905 by Nobel laureate Karl Ferdinand Braun, who shared the 1909 Nobel Prize in Physics with Guglielmo Marconi "in recognition of their contributions to the development of wireless telegraphy".

While I've been talking about two antennas side-by-side, you can orient as many antennas as your budget allows in what ever shape you require. For example, the Square Kilometer Array being constructed around the corner from me, well about 550 km away, is planned to have a total 131,072 log-periodic-dipole antennas, arranged in 512 groups with 256 antennas each.

Laid out in a grid, a phased array can change focus in any direction, and with it, the radiation pattern changes. By manipulating phase for different elements, you can create multiple points of focus from the same array, and while we're at it, since all this is done electronically, you can shift focus in nano even micro seconds, rather than multiple seconds associated with physical movement.

I've been using the word "signal", because while this phased array phenomenon applies to RF, it also applies to sound, as-in sonar, and light, as in LiDAR. In addition to radio astronomy, it's used across plenty of other fields including weather radar, space communication, broadcasting and even amateur radio. You'll find phased arrays in autonomous vehicles and adaptive cruise control, even your Wi-Fi router and mobile phone.

In amateur radio, we tend to use fixed rather than variable phase modification when we combine dipoles, Yagis, and even verticals in the venerable four-square antenna.

If you want more detail in a thoroughly accessible form, I can recommend Marshall Bruner, who has a wonderful YouTube channel describing and animating many different fundamental aspects of radar technologies like this. You'll find his "Phased Arrays - Steering and the Antenna Pattern" on my YouTube channel in the "Videos for more inspiration" play list.

I'm Onno VK6FLAB

I recently expressed the notion of using a PlutoSDR as a replacement for an oscilloscope, a spectrum analyser, and perhaps even a vector network analyser. I can add signal generator to that list and you get the notion that this one device might replace a bunch of tools in your shack.

So .. I set out to come up with a minimum viable product to see what I might discover.

There are days when you get out of bed with a spring in your step, only to end the day exhausted and thoroughly defeated. Given the chance, the next day, you get out of bed and try again.

Fortunately for me, I have a full head of hair and my yak shaving barely made a dent and as a bonus, I learnt something, which is always nice.

The short version is that you should use a USB Y-adaptor or splitter to ensure that your PlutoSDR has enough juice to power a USB Ethernet dongle.

That statement alone is worth at least a combined fifteen hours of Yak Shaving.

Without this turning into a PlutoSDR specific troubleshooting saga .. for reasons I don't understand, plugging the power supply into the Pluto power socket and a USB Ethernet dongle into the accessory port doesn't work, but plugging both into a Y-adaptor and that into the accessory port makes all the blinkenlights work, even those on your network switch. As I said, fifteen hours.

So, what does this buy me, other than an appreciation for subtlety? It gives me network access to my PlutoSDR, which makes it possible to connect to it using GNU Radio running on a different computer, which then allows me to experiment.

Before starting this side-quest into connecting to my Pluto, I went on the hunt for some example code. Jon Kraft, who is a senior staff Field Applications Engineer at Analog Devices, whom I came across first on YouTube, where he's been playing with beam-forming and other nifty RF phenomena, also has a GitHub repository with some PlutoSDR examples for use with GNU Radio.

These examples are pretty straight forward, essentially connecting to a PlutoSDR, setting the centre frequency and extracting a bunch of RF and visualising it. Essentially what you'd want in some testing gear.

After playing around for a bit with Jon's examples, I'm able to see radio spectrum, across the network, on my screen, using GNU Radio.

Eagle eyed observers will note that I already achieved this with an RTL-SDR dongle and indeed I did. A few differences. I have access to a frequency range between 70 MHz and 6 GHz and I have the ability to transmit.

Of course this doesn't yet get us to the point of replacing test gear, but I think it paves the way to a collection of experiments that will.

If you're unfamiliar the Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio. It's called Bald Yak because by the time I'm done, the Yak is likely well and truly shaved.

So, my oscilloscope and other tools adventure is an example of what Bald Yak might facilitate. In radio terms there's very little to distinguish this type of tool from a transmitter running your favourite mode, and it allows me to experiment with a different radio back-end.

Full disclosure, I'm still trying to work out how to do this using SoapySDR, because if you remember, that will allow me to connect to any device, for now, this is using a PlutoSDR source and sink.

While we're on the subject of Soapy, I did start digging into SoapyAudio and the idea of making a more universal module that will allow amateur radios for both receive and transmit using Soapy, but I came unstuck when I discovered that the example plug-in code is essentially an empty file with the programming equivalent of "here be dragons". I'll likely come back to it, but not today.

Now, I do need to make some disclaimers because I know that there are plenty of caveats I've glossed over here. I think much of it is covered with the word "calibration".

A PlutoSDR is not a laboratory grade device. It isn't calibrated in any way, it's likely unstable, connectivity across the network is likely to be choppy, and plenty more issues like this.

In other words, if you come away from this thinking we're going to be building something to replace measuring gear you can buy for the price of a small car, you're going to be disappointed.

However, if you're here for "Wow, cool, you can do that, for a couple of hundred bucks?", you've come to the right place.

Also, I'm aware of the Analog Devices "IIO Oscilloscope", that it's extensible, and even has a plug-in specification, but what it doesn't have is GNU Radio, which is I want to use for a whole lot of reasons, least of which that it isn't hardware dependent.

As I've said before, when I have something to show-and-tell, you'll be the first to know.

In the meantime, you could do worse than look for Jon Kraft's GitHub or his RadioKrafter YouTube efforts and have some fun yourself, that's Jon, no "H" and Kraft with a "K".

I'm Onno VK6FLAB

Launched into your amateur radio adventure you're faced with figuring out what you need to fly. If you have a web browser, you can start listening to a massive array of online radio sources .. today.

Beyond that, a handheld radio is often the first purchase for a new amateur, more often than not followed by the acquisition of a more advanced radio and associated paraphernalia, antenna, coax, power supply and the like.

A video of forging the "Most Iconic Swedish Axe", by Torbjorn Ahman, a Swedish Blacksmith, started off with making several tools, before the axe forging itself got underway. It reminded me that in the amateur radio community we often talk about radio with rarely any mention of any toolkit.

Spend six seconds thinking about this and you'll likely come up with a soldering iron and a multimeter as your next investment, but what happens after that?

While not universal, truth be told, my soldering iron has very little use, though half a century ago it was probably essential. My multimeter gets more use, even though it really doesn't do any radio tricks. Its most used feature is continuity testing.

One proper bit of test gear is an antenna analyser that we use most times anyone plays with antennas.

Several years ago, I was given a lovely NanoVNA which gets a regular workout though calibration is a bit cumbersome. I was also given an inline power meter that provides all manner of battery health information. I take it to every portable operation.

Gadgets aside, the tools I use more than all of these put together are a quality wire cutter and an Anderson Powerpole crimper with all the connector housing colours. There's also a comprehensive set of screwdriver bits, enabling access to more equipment than I have time to investigate.

A 15 Watt dummy load, good to 150 MHz, gets regular use, and to complete the picture, underneath my desk is a HP 606A signal generator that I'm scared to restore. Last time I went near it, I managed to trip the house RCD for reasons I still don't understand.

There's other stuff in boxes and drawers, but I clearly don't use them enough to come to mind.

Unremarked is my computing infrastructure. Until a couple of years ago that consisted of a 27" iMac, vintage 2015. Expanded to 64 GB of RAM, it ran all my software using VMware, sometimes a dozen or so virtual computers simultaneously. It died in 2024 when the power cord managed to short itself on my portable desk, yes, that too tripped the RCD. Although I didn't lose any data, due to a perfect storm of incompatibility, it's been nearly two years before I found the beginnings of a replacement, a small form factor Lenovo IdeaCentre with 32 GB of RAM running Proxmox.

If I was made of money, I'd probably find space for an oscilloscope and a signal generator, perhaps even a proper network analyser, but truth be told, most of my adventures these days are in the software realm. That's not to say that there is no place for such gear, just that I suspect that they'd feel overwhelming rather than something I'd grab to solve a problem.

That said, regular posts by Ismo OH2FTG about resurrecting all manner of broken testing equipment revealed to me that a surprising number of these tools are essentially a computer with an operating system, running some custom application that presents itself to the user via a display. Apparently you haven't lived until you see a Windows boot loop on your Agilent oscilloscope.

I suppose I shouldn't be surprised, the "HP 8920A RF Communications Test Set" that I played with a while back runs what looks like a version of DOS, which comes on ROM chips, according to HP taking 2 hours to replace for a firmware upgrade, and each of its in-built tests is a program written in HP Instrument BASIC.

This morning I walked into my office and spotted my PlutoSDR on my desk. If you're unfamiliar, a PlutoSDR is a little box, blue, because of course colour matters, has two SMA coax connectors on one side and two USB sockets on the other side.

One antenna port is marked "Rx", the other "Tx" and by connecting the two together, you can create a transmission and then receive it. While that sounds completely useless, it's the exact same set-up as any number of bits of test equipment, to be clear, normally you have something you're testing connected between the ports.

Combine that with a connected computer and you have the makings of some fancy test gear, capable of 70 MHz to 6 GHz. Since it's all Open Source, you can write your code in your language of choice.

Of course I'm not the first person to come to this point. There's tools around for making this reality, implementing oscilloscope, spectrum analyser and plenty more. I am already imagining what I might achieve with GNU Radio.

While there's plenty of room for soldering irons in our community, I think it's also worth considering what software might help in your toolkit.

I'm Onno VK6FLAB

Yes, I know, it's the plural form of Sun, but the word Sun likely predates our understanding that stars and our Sun are the same thing.

I get "stars", but where did "suns" come from?