Foundations of Amateur Radio

Recently I received a lovely email from Michele IU4TBF asking some pertinent questions about the Bald Yak project. 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.

The short answer to how I'm doing getting GNU Radio to play nice with my computer is that I have bruises on my forehead from banging my head against the wall. When I get to success I'll document it. To be clear, I'm not sure what the root cause is. I suspect it lies between the GNU Radio developers, the people making packages and the manufacturer of my computer. I'm the lucky one stuck in the middle.

A more interesting question that Michele asked was, for Bald Yak, what is the A/D and D/A requirement for making GNU Radio talk to an antenna?

This is a much deeper question that meets the eye and I think it serves as a way to discuss what I think that this project looks like.

Ultimately in the digital realm, to receive, an analogue antenna signal needs to be converted to digital using an Analogue to Digital or A/D converter, and to transmit, the reverse uses a Digital to Analogue or D/A converter to make an electrical signal appear on your antenna.

The specific A/D or D/A converter determines what you can do. The sampling rate of such a converter determines what frequencies it can handle, the sample size determines the range of signals it can handle. You can compare it with a video screen. The sample rate determines how many pixels on the screen, the sample size determines how many colours in each pixel.

The sample rate of an A/D converter is measured in samples per second. If the device only has one channel, you could think of this as Hertz, but if there are multiple channels, like say a sound-card, the sample rate is likely equally divided across each channel.

You might have a sound card capable of 384 thousand samples per second, or kilo-samples, but if it supports simultaneous stereo audio input and output, only 96 of those 384 kilo-samples will be allocated to each channel and only half of those will actually help reconstruct the audio signal, leaving you with 48 kHz audio. In other words, the advertised frequency response might not have a direct and obvious relationship with the sample rate.

At the moment I have access to a few different A/D and D/A converters. The simplest one, a USB audio sound card, appears to do up to 192 kilo-samples at 16 bits. The next one, an RTL-SDR tops out at a theoretical rate of 3.2 million or mega-samples at 8 bits. The Analog Devices ADALM-PLUTO, or PlutoSDR handles 61.44 mega-samples at 12 bits.

Now, to be clear, there are other limitations and considerations which I'm skipping over. Consider for example the speed at which each of these devices can talk to a computer, in this case over USB. I'm also going to ignore things like mixers, allowing devices like the RTL-SDR and PlutoSDR to tune across frequency ranges that go beyond their sample rate.

Each of these three devices can convert an analogue antenna signal into bits that can be processed by GNU Radio. All of them can also be used to do the opposite and transmit. Yes, you heard me, several amateurs figured out that an RTL-SDR can actually transmit. Credit to Ismo OH2FTG, Tatu OH2EAT, and Oscar IK1XPV.

The point being that whatever Bald Yak looks like, it will need to handle a range of A/D and D/A converters. As I've said previously, I'm aiming for this to work incrementally for everyone.

This means that if you have a sound card in your computer or an $8 USB one, this should work and if you have an $33,000 NI Ettus USRP X410 lying around, this too should work.

Also, if you have an X410 lying around not doing anything, I'd be happy to put it to use, you know, for testing.

So, kidding aside, what about the rest of the Bald Yak experience?

GNU Radio works with things called blocks. Essentially little programs that take data, do something to it, then output it in some way. It follows the Unix philosophy, make each program do one thing well, expect the output of every program to become the input to another, design and build software to be tried early and use tools rather than unskilled labour.

Amateur radio transceivers traditionally use electronics blocks, but if we move to software, we can update and expand our capabilities as the computer we're using gets faster and the GNU Radio blocks evolve, and because it's all digital the computer doesn't actually have to be in the same box, let alone the same room, it could be in multiple boxes scattered around the Internet.

So, the idea of Bald Yak is a collection of blocks that allow you to do radio things. You might have a separate box for each amateur radio mode, AM, FM, SSB, RTTY, CW, WSPR, FT8, FT4, Q65, but also modes like Olivia, FreeDV, SSTV, Packet, PSK31 or Thor. Instead of having to figure out how to wire these modes into your radio and your computer, the infrastructure is already there and you just download another block for a mode you want to play with.

We'll need to deal with variables like which A/D and D/A converter is being used and what their limitations are. We'll also need to build a command and control layer and probably a few other things.

I'm considering a few other aspects. For example, GNU Radio is mostly run with text files. We might distribute those using something like a web store. GNU Radio is proving hard to install, perhaps a LiveCD is the way to go. We'll need to come up with a base level of functionality and the documentation to go with it. I'm still contemplating how to best licence this all, specifically to stop it from being exploited. Feel free to get in touch if you have ideas.

I'm Onno VK6FLAB

Foundations of Amateur Radio

Have you ever come across a solution to a problem that you sort of knew you had, but didn't really appreciate until that moment? I had one of those recently. To set the scene, fair warning, we're not going to solve this today, we're still very much shaving yaks, but there's plenty to take away.

So, the scene.

I'm hosting my weekly net. It's going well. All the internet links are up and running again, thanks to the hard work behind the scenes of several unsung heroes, I can name a few, Bob VK6ZGN, John VK6RX and Rob VK6LD, but there are plenty of others whom I don't know and who have yet to stick up their hand to say, I was there. Regardless, thank you.

Anyway, I'm hosting my weekly net, F-troop. A curious thing is occurring. Two of the stations are emitting a tone during their transmission. I'm pretty hot on how things sound, so I ask. We talk about it for a bit when Allen VK6XL comes in and tells us that according to his spectrum analyser it's a 1 kHz tone with harmonics and it's on all transmissions, just audible on two.

This starts a conversation about spectrum analysers when Allen mentions that he's using an audio spectrum analyser, a piece of software running on his computer. The software has a copyright from 1999 and based on the documentation I saw, has lots of excellent functionality. I might even be able to run it on a Linux machine using WINE, but that's an adventure for another day.

Randall VK6WR points out that I could use the spectrum display on Audacity. This is a much more current piece of software, but it's not intended for real-time use, it's what I use to edit the audio after recording my podcast. Not even sure if the spectrum display can show during recording, I've never tried.

In the past I've used SoX, the Swiss Army knife of sound processing to create sonograms, but that too isn't real-time.

Then it hits me. I have a real-time tool. I've been playing with it for weeks. GNU Radio. Surely it has a spectrum display, and indeed it does, several.

So, I already have a tool, purpose built for processing signals, that can do all the things I'm looking for and some I've not yet imagined.

Before I proceed, I'll remind you that we're in the middle of the Bald Yak project, so named because by the time we're done there won't be much hair left, if any. 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.

So, boldly clicking about, I set on the notion of making a block called "fosphor" work. Depending on which description you use, it's an Open Source, GPU-accelerated FFT and Waterfall display tool. What that means is that it uses a graphics processor to do the heavy lifting and has the ability to show signal levels across frequencies and on a waterfall display. Apparently it's a block for RTSA-like spectrum visualisation. I'm fairly sure that doesn't mean Railway Technical Society of Australasia or has any relationship with Reverse Total Shoulder Arthroplasty or the Road Transport and Safety Agency of Zambia.

I'll admit that I didn't see the GPU part of that description until several days later. Had I seen it at the time, I would likely have carefully backed away and shelved the idea, but that's all water under the bridge.

To cut to the chase, I have yet to make this show a single pixel. I smelled trouble for the first time when I discovered a post asking if anyone had gotten this to work on a current release of Debian.

I came across a lovely post by what appears to be the author helping some hapless user, and I'll confess that's the camp I'm currently in, to make it work. I have no doubt that I can make it work, but that's going to take some effort.

Now, at this point you might ask me why I wasted your time with this tale of woe?

Well, the answer is simple. This is what "Yak Shaving" looks like. You solve a thousand little problems, one at a time, and if you manage to keep track of what you're doing and why, you can get stuff done.

This applies here, but it also applies in your life, in radio, in antenna building, in making a contact, in participating in a contest, in activating a park.

Each activity reveals myriad issues that you'll each need to resolve. The more practice you have at this, the better you'll get. I will point out that for me it's not without stress. When I go though intractable problems I'm often as grumpy as a bear with a sore tooth whilst my brain is running like a hamster in a wheel generating kilowatts of power.

This too shall pass.

Oh, because I know it's bothering you. RTSA, Real Time Spectrum Analyser, obvious, right?

I'm Onno VK6FLAB

Foundations of Amateur Radio

Recently I built a first attempt at a noise cancelling circuit, on my couch, in GNU Radio, without holding a soldering iron and running the risk of the room smelling like burnt chicken, because if you believe the Internet, sometimes holding a hot piece of metal by the hot end is not the best way.

The idea behind the circuit, or more accurately, flowgraph, is that you take a signal from two sources, invert one, combine them, and they cancel each other out. If the signal with the noise only contains noise, then you can, at least theoretically, remove the noise from the actual signal.

Before you think that I'm inventing something new, I'm not. I'm merely attempting to recreate the same notion I came across decades ago, where you combine the signals from two microphones, preferably identical, reversing the wiring in one and talking into a microphone whilst holding the other one away from your mouth.

I did essentially the same thing using RF signals from two RTL-SDR dongles.

Randall VK6WR pointed out that, aside from misusing the word "mix", which in electronics really means multiply, but in audio means combine, Randall suggested I use "add" and "subtract". I'm still working out how best to name things, because we're talking about audio and RF, sometimes at the same time. Perhaps that's where I went wrong. I'm currently using "combine" as my technology neutral word, but I'm happy to take suggestions.

All that was the side show, because as Randall points out, doing this in RF is much harder than in audio. This is already something I knew. At the time I didn't really know how to get two different but the same sources of audio to experiment with, so I started in the deep end at the RTL-SDR dongle side.

Now, armed with the encouragement from Randall I built a horrible thing, which is easy when you just drag and drop blocks on a screen. I built two independent FM decoders that use the exact same parameters, so they're tuned to the same frequency, they're amplified and tweaked identically. The only difference is that they each decode a different dongle. I then piped each of those into my magic noise cancelling circuit and tried again.

Aside from dealing with hardware restrictions, causing things like buffer under-, and over-run, that's when the computer isn't processing all your samples, or is getting ahead of itself and is running out of samples, I can make audio come out of the speaker in my computer. I can prove that there are two signals, by setting the amplification of either to zero, and still get sound from the other source, however, noise cancelling, no matter what I tried, didn't work.

Then I decided to simplify, rather than trying to cancel out "the Heat is on", word of honour, I'm not making that up, that's the song that was playing, I went back to basics starting with a tone. I fed the same tone into the noise cancelling block twice, once as signal, once as noise. Magic, the cancelling works.

I also learned that changing the frequency of the noise and changing it back gets you into all kinds of problems and even if you send the same tone, one shifted in phase by a known amount, getting the two to cancel each other out is non-trivial.

You might think that this was all a complete waste of time and if you're just driving past it looks like a swollen electrolytic capacitor about to burst your bubble, but it's not that bad.

Here's what I learned from this little adventure.

I can make hierarchical blocks out of flowgraphs. This is important because at some point all the functionality associated with Bald Yak will likely end up being implemented like this. I also learned that such a block can contain user interface elements, which means that we can build blocks that know how to do stuff and tweak how they operate without having to build a user interface every time we use such a block.

I learned that we can implement an idea that would be hard using physical components and test it really quickly, in this case my available time was the limiting factor, not the testing. If I'd done this with components I'd still be trying to figure out where to get them from, let alone turn up the heat. Another bonus is that I didn't spend a single dime and I can dispose of it with the click of a button, rather than trying to figure out how to recycle components and circuit boards.

I also learned that the idea as I built it doesn't work quite as I expected and that things that I didn't anticipate, like changing the frequency, buffer under-, and over-runs, impacted my efforts in unexpected ways. There's a delay between making a change on the user interface and the effect becoming audible, and I learned I can make a dongle work on my computer and that installing GNU Radio is a challenge at the best of times.

In other words, even though I'm unlikely to use the noise cancelling efforts in their current form, there was plenty I learned from the experience.

From my perspective, this was a success. What have you experimented with and learned?

On a completely unrelated matter, long overdue, and music to the ears of some, can you spell SKCC, I've finally put all the Morse Code versions of my podcast on a thumb drive and plugged it into my car. During the week I've managed to listen to about two hours of Morse. While I don't know most of the letters of the alphabet, I can still detect letter and word boundaries.

I'm Onno VK6FLAB

Foundations of Amateur Radio

As you might recall, recently I stumbled on an excellent list of 52 weekly challenges put together by Fabian, DJ5CW and friends. You can find it at hamchallenge.org. As I've previously mentioned, it contains activities right across the amateur spectrum, from designing a QSL card to making a contact on 80m or 160m, with everything in between. It's an excellent tool to set a weekly goal to achieve and I recommend that you have a go.

It's not the only interesting tool around.

Amal VU3FTH and Steph Piper, whom you might know as MakerQueen AU, have put together an "Amateur Radio Skill Tree". It's a collection of hexagonal tiles, each with a skill, displayed together in an attempt to track what you know and could know about amateur radio. The idea is that you print it out and colour in each tile as you complete it. You'll find things like "Explore D-Star", "Build a cw key", "Teach a friend about Amateur Radio", and plenty more. Can you get four activities in a row and which skills could do with more effort? There are 68 tiles ready for your colouring pencil .. Bingo!

The Radio Amateur Training Planning and Activities Committee, better known as the RATPAC, put together an "Amateur Radio Challenges Checklist for 2025" and published it on mastodon.radio. It's a list of bands, modes, activities, builds and clubs that help you track what you've been up to throughout the year. While we're here, I should mention that the RATPAC in their words "comprises Amateur Radio Operators of a wide variety of backgrounds and experiences", and hosts two weekly Zoom meetings so anyone can participate in the talks published on the ratpac.us website. If you're unable to attend, you'll find the presentation on YouTube.

Over the years I've been part of this amazing hobby, I've been telling anyone who will listen that there is plenty to do and see in our community, a thousand hobbies in one. The tools I've mentioned represent around one hundred and fifty activities and pursuits, but hidden behind each one is plenty to explore. For example, hamchallenge asks you to spend week 21 creating a GNU Radio flowgraph. That topic alone could fill a decade worth of exploration if you were so inclined. Similarly, one of the Skill Tree tiles is "Study RF propagation", something which you might realise is easier said than done. The RATPAC checklist has a tick box for "Work 100 countries", not something you're likely to achieve in an afternoon.

My point is, you can do as much or as little of this as you like, to what ever degree floats your boat. As you might know, I'm deep in the weeds with GNU Radio and I expect to stay there for plenty of time to come, but you are under no obligation to follow me down the rabbit hole. In other words, it interests me, but it might not do the same for you.

One final comment. None of these activities require you to upgrade your license, well, other than the Skill Tree tile "Upgrade your radio license". You can do most if not all of the activities I've shared with any amateur license and plenty of it can be done without a license at all.

So, what are you waiting for?

I'm Onno VK6FLAB

Foundations of Amateur Radio

The other day I was sitting on the couch lounging about when I came up with an idea and there and then I picked up a circuit board, soldered down a hundred or so components and built a noise cancelling gadget, all within about an hour .. right there, on my couch.

Yeah, that didn't happen, least of all, my soldering skills are not up to scratch, never mind the couch.

I did however build a noise cancelling circuit, on my couch, in about an hour, but no soldering iron was hurt and the room didn't smell of chicken afterwards. Instead I used GNU Radio to put together a series of blocks that allow me to apply noise cancelling to a signal.

How does this work?

Well, imagine a signal mixed together with the negative version of that signal, think of it as swapping positive and negative if you like. If you mix two identical signals together, one of them inverted, you end up with nothing, because they cancel each other out, where one is high, the other is opposite and low and vice versa. Mix a high signal with a low signal, you end up half-way. If they're the same but opposite, half-way is zero.

Hearing nothing is not helpful, but what if the two signals were slightly different, let's say, one is connected to a proper 10m antenna and the other is connected to an antenna that picks up local noise. We'll call the antenna on 10m the "signal" and the local noise antenna the "noise". If you mix these together, you end up with a signal and noise combined, but if you invert the noise signal, you can, at least theoretically, filter out the noise that's common to both antennas.

Now I did say "theoretically" and that's because while it sounds simple, it's far from it. Unless you have a special radio, the two signals are not coming from the same device and won't really be identical where it matters. For example, let's call it the volume or gain of one might be higher than the other. One might arrive slightly later than the other if the coax isn't the same length or the electronics in both radios are different. There are other things too, but let's just stay with this for a moment.

You could amplify or attenuate one or both signals to make them the same or similar levels. You could change the phase, think of it as the time when a signal starts, and synchronise the two signals in time manually.

Of course whilst you're doing this, inside GNU Radio, the computer is doing some serious math, which takes time to make these changes, which introduces further delays you'll also need to account for.

Building it was simple. Testing it much less so.

After coming to grips with the USB port on my computer, which for reasons best known to the manufacturer, cough, Apple, switches off ports that are in use, I managed to get two RTL-SDR dongles connected and working. This involved removing GNU Radio, which was installed using a tool called "homebrew", then installing it instead using "radioconda", twice, since the first time the installer failed with an error, actually three times, because the failed installation left all manner of rubbish behind, so that needed to be removed; then I had to disconnect my keyboard and track pad, because for reasons only known to the manufacturer, yeah, the same one, they won't play nice if there's an RTL-SDR dongle plugged into the USB-C hub, I finally got this running, which in turn involved figuring out what the GNU Radio "Device Arguments" look like for a locally connected dongle, in case you're wondering, it's "rtl=0" for the first one and "rtl=1" for the second.

Clearly this project is living up to its name, Bald Yak.

Now I can invert a signal, I can amplify and attenuate it, change the phase, shift the frequency, swap the I and Q, do a complex conjugate, and have a user interface that can change these settings as required.

I'm going to ignore the hour of my life I'm not getting back to understand how variables, parameters and user interface items hang together and how they interact. It's logical, but it takes a bit to wrap your head around it and I'm a software developer, so I don't envy you if you're not.

Anyway, I tuned to a local FM broadcast radio station and couldn't make any noise go away. I then discovered that my noise antenna was picking up the station just fine, so that didn't help. Then I swapped radios, actually, I just swapped the zero and the one in the "Device Argument" fields and tried again.

In the process I discovered how you can create a so-called "Hierarchical Block" in GNU Radio and to my delight also discovered that there is one that can have a user interface, so I can make a stand-alone block, that has a user interface, that I can use in another project, which is how I intend Bald Yak to function.

So, changing stations, I could finally hear noise, but still no reduction.

Then I realised that I was using FM, not single side band, so I started hunting for an SSB decoder but had to abandon ship to go and do life. Overnight I realised that if everything went to plan, the two FM signals should have cancelled each other out, making silence, which they didn't, despite my efforts.

So, at this point I have a thing that can alter noise and mix it with a signal for the purposes of noise reduction. That it doesn't work is potentially because I have not enough range in my adjustments, or too much range with not enough steps, just as likely it's because I'm missing some fundamental understanding somewhere. If you have any documentation I should read, please don't be shy.

As life adventures go, I'm hooked, but it's not without shaving Yaks, Bald or otherwise.

I'm Onno VK6FLAB

Foundations of Amateur Radio

For quite some time I have operated a WSPR or Weak Signal Propagation Reporter beacon on the 10m band. If you're not familiar with it, I've dialled the power right down to 10 dBm, or 10 milliwatts. You'd think that this would be a fool's errand, but it was heard 13,945 kilometres away. Of late the reports have been far and few between, despite the 10m band being quite active.

Encouraged by a friend playing on 15m, I made the decision to change bands. At the moment this is not a trivial process, though at some point in the not too distant future, hopefully before I need a Zimmer Frame, I intend to erect a multi-band Hustler 6-BTV antenna that has been in storage for several years. Before that occurs, since it involves all kinds of shenanigans, I went for a simpler option, replace the 40m helical whip antenna with a 15m helical whip, something I can do without climbing on the roof.

In case you're wondering, using an SG-237 antenna coupler, the 40m antenna tunes fine on 10m, but not so much on 15m.

After pulling the replacement antenna from its hidey-hole I discovered that it was missing a tip. I don't recall if it ever had one, it came from the estate of a fellow amateur, Walter VK6BCP (SK). I took it on faith that it worked on the band that it was labelled with and went looking for a way to close off the tip. In the end I used heat shrink with a glue lining and sealed it off, folded over the tip and used more heat shrink to keep it folded over. We'll see how well that works.

I then unscrewed the 40m antenna from its mount and was frustrated that it would only come with the spring attached. Using a crescent and a pipe wrench I was able to unscrew the spring but discovered that the threaded stud that connects the two didn't stay in the antenna, instead it stayed in the spring, which meant that I couldn't attach my 15m antenna without breaking something.

I remembered that I had another spring lying around, so I dug that out of storage, I really need to set-up a "part-db" to keep track of where everything is, and attached the 15m antenna to the spring and screwed it back into the antenna mount and I'm back in business.

In putting away the 40m antenna I lifted it up after removing the spring and promptly got wet. Litres of brown water came pouring out of the antenna. It turns out that the adjustable tip isn't sealed and sitting on my roof for several years managed to fill it full of water, that's through a tiny opening at the tip, in a country known for hot and dry, it's expected to be 40 degrees Celsius here today. It made me wonder if that water was why the beacon wasn't heard recently.

The next step involved changing the beacon frequency. The hardware is a ZachTek 80To10 desktop transmitter, built by Harry, SM7PNV. The software to change settings runs on Windows and since my system crash in June last year I've not had any Windows machines lying around. I went to the ZachTek website and discovered in the downloads section that there is a link to a web page configuration tool written by Phil VK7JJ, of wspr.rocks fame, that allows you to open a website, plug in your beacon, and configure it from any Chrome web browser. I was both astonished and delighted that this exists.

I changed the beacon band from 10m to 15m and powered it up.

One final step. As I said, for the last little while my beacon has only sporadically been heard, so I set up a local monitoring system. It consists of a little computer connected to an RTL-SDR v3 dongle and the included telescopic dipole. Using a Docker container written by Guenael VA2GKA, I monitor my own beacon. After updating the band from 10m to 15m, reports started flowing in.

As an aside, the last time I did this I built a custom Raspberry Pi image and had to change several things to start monitoring after a reboot. This time I used an inbuilt Docker mechanism, "restart unless stopped", to launch the container. This means I don't need to alter the system and I can add and remove containers as I need to.

This is important because it's likely how some of the "Bald Yak" project will also gain functionality.

I'm feeling rather chuffed that on my first day back as a human after recovering from my first bout of COVID, I managed to move my beacon to 15m, get it on-air, configured and transmitting with confirmation in the log.

The only thing missing now is your signal report.

I'm Onno VK6FLAB

Foundations of Amateur Radio

The other day I noticed a flurry of QSL card designs come across my screen and it sparked me into action on actually creating such a card for myself. I've previously talked about what I think of the current offerings in terms of validating contacts, but having a QSL card design is step one of confirming a contact, well, technically step two, since you have to make the contact first.

I'm intending to use SVG as the design platform, since it's a text file that describes an image, so I can use my favourite command line tools, like "grep", "sed", "cut" and "awk" to replace parts of the file, so I can make a personal card for every contact, but that's a story for another day.

Accompanying the rush of new card designs was an intriguing hash tag, #hamchallenge. Looking into this further I discovered a project by Fabian DJ5CW with an accompanying website, hamchallenge.org. When you go there, and you should, you'll discover 52 challenges with varying levels of difficulty that you can use as inspiration to do something with your hobby.

The usual suspects are there, things like week 42, receive an SSTV image, or week 50, receive an APRS message or beacon. Then there are those like week 38, make a contact on Morse code, and week 19, simulate an antenna. It goes well beyond those essential skills into important stuff like, week 14, implement and describe a backup solution for your ham radio log, and week 24, make a contribution to an Open Source ham radio software package.

Not all challenges require an amateur license either. For example, week 32, listen to a broadcast station from another country, is open to anyone with a sense of wonder. The difficulty level is included in a challenge, so week 17, which VHF or UHF repeater is closest to you, is marked as easy, where week 3, work another continent on 80m or 160m, is marked as hard.

There's also helpful information about a challenge, for example week 6, take part in a contest, includes a link to the contestcalendar.com website where you'll find most if not all amateur radio contests.

Of course this is your hobby and it's not up to me to tell you what to do, but I have to say that the items in this list are exciting, they speak to me and I have to say that I'll be taking inspiration from this list and I recommend that you do too.

Not all of the challenges will be something new to everyone. I've already built an antenna, participated in a contest, worked a 10m FM repeater and several other things on this list, but if I'm going to make a Morse Code contact, I'm sure going to have to find some time to actually, you know, learn Morse. I know this will come as music to the ears of several of my amateur friends.

There will be challenges that speak to you more than others, week 21, create a GNU radio flowgraph, is right up my alley, but that might not be the case for you.

If you feel inspired, week 47 encourages you to submit an idea for the Ham Challenge next year.

So, thank you to Fabian for the efforts and many amateurs who have already contributed to this adventure. What a beauty. I'm off to finish my QSL card.

I'm Onno VK6FLAB

Foundations of Amateur Radio

Life is messy. This is not a revelation. We attempt to organise this chaos by using all kinds of magic incantations, to-do lists, new year resolutions, plans, projects and anything else you might have in your arsenal. The same chaos reigns, in how we make progress. Some days are harder than others. I'm mentioning this because I've seen a couple of amateurs share all the things they didn't achieve last year. If we used that metric, I could point out that I didn't win the lotto, likely, neither did you, or your friends. I didn't get on HF to make a contact, I didn't put up a 6BTV antenna, the list is never ending.

In other words, it's easy to say what you didn't do. What if you turned this upside down? I hosted my weekly radio net for its thirteenth year, I had my beacon heard more times than I have bandwidth available to check right now, I started a project that looks like it's going to keep me busy for some time to come. I've been working my way through a full system crash and I can see light out the end of the tunnel, six months later.

So, don't beat yourself up about all the things you didn't do.

Speaking of that, making plans is fine, but don't use the to-do list as a way to describe all the things you didn't do, instead, think of it as an inspiration for what to do when you're bored.

Chaotic aspects of life aside, the same disorder reigns supreme in the software world. GNU Radio on which I'm basing the "Bald Yak" project is just as chaotic. New versions are released regularly. Right now it's at version 3.10.something. On my Mac, it's 3.10.11.0, on my Debian machine it's 3.10.5.1. Depending on which operating system you use it's different, there's a wiki table, but that's out of date, before you ask, yes, I've requested an account on the GNU Radio wiki so I can fix it.

This only scratches the surface of things that are, for want of a better word, disharmonious. This might be perceived as chaos, but the reality is that this exists throughout the computing world. If you're not a software developer you might have only scratched the surface of this, trying to open a document written for a different version of your word processor, installing a new operating system and finding software that was working perfectly before, suddenly doesn't.

GNU Radio is a complex beast. The latest release has 5,570 files, making nearly 80,000 lines of source and related code. The git repository shows 579 authors and I will point out that it's likely there are more, since the project was first released in 2001, but the git repository only goes back to 2006.

Said differently this is a big project that nobody is likely to hold entirely inside their brain. It means that things change without everyone involved knowing about it. I'm raising this because we're diving into a complex environment that we're using to build ourselves a new thing.

At this point you might want to run for the hills. I understand.

One of the great things about society is our ability to abstract. It's why I'm typing on a keyboard with letters of the alphabet and not punching holes into cardboard. It's why I'm looking at a screen with graphics and controlling images with my finger, rather than looking at dozens of blinkenlights that provide a lifetime of memories.

GNU Radio is the abstraction of radio. That's the whole point. It allows us to pick up a signal block, tell it to make a kilohertz tone, connect it to my loudspeaker so sound comes out. It looks simple on the outside, but underlying that is a level of complexity that you will only encounter when it comes to raise its chaotic head.

This all to say that I did make some progress. When you play an audio tape at half speed, or play a single at 33 RPM instead of 45 RPM, the result is that the audio is slower, but it also means that the audio is lower in frequency. It led me to wonder if I can use that phenomenon to help me hear better. What if I could play audio slower and have my ears be able to hear better. Right now, anything above 2 kHz is hard to hear. I keep asking my partner, "Say again?", "Sorry, what?", "Sorry, I didn't hear that."

Hearing aids seem to attempt to deal with the problem by amplifying the sounds you cannot hear. This results in squealing and all manner of other unpleasantness. It also doesn't seem to help me. Instead I wondered if I could halve a 4 kHz tone to 2 kHz, I could hear it. So, if I play audio at half speed, I can hear more. Unfortunately it would also mean that I would be running behind all the time. So, what if I could play at half speed and remove half the audio samples? I can confirm that with simple tones this works and I did this inside GNU Radio with pretty much one block, "Keep M in N samples", in this case, keep one in two. I halved the sample rate and all was well.

Why is this significant?

Well, aside from that it might help me hear better, it represents the first time I had an idea that I could try out in realtime and see what it did. For a bunch of reasons I haven't yet moved on to actually hearing it, by setting the source as the microphone and the sink as my headphones, but that's on the cards soon.

Making progress is a series of chaotic steps that take you on a journey. If you're lucky, the journey will get you where you want to go.

I'm Onno VK6FLAB

Foundations of Amateur Radio

As you might know, a little while ago I started a new project.

"The Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio."

In embarking on this adventure I've been absorbing information as I go whilst explaining what I've learnt to anyone who will sit still long enough. Credit to Glynn VK6PAW and Charles NK8O for their patience.

For most people, me included, the introduction to GNU Radio happens via a graphical user interface where you build so-called flowgraphs. These are made up of little blocks that you wire together to get from a Source, where a signal originates, to a Sink, where it terminates.

Each of these blocks does something to the signal, it might be a filter, an amplifier, it might encode or decode a signal like FM, AM, Wideband FM, or some other modulation like Phase Modulation or OFDM, Orthogonal Frequency Division Multiplexing, a way of transmitting digital information using multiple channels. It's used in places like WiFi, ADSL and DSL, Digital Television as well as modern cellular systems.

Those blocks generally expect a specific type of input and generate some particular output.

After you save your design you can run the flowgraph and behind the scenes some magic happens. Your visual representation of signal flow is translated into either Python or C++ and the resulting application is what is actually run, which is why the user interface that you design your flowgraph in is cunningly named, GNU Radio Companion.

So, what if you want to do something that doesn't yet exist? As it happens, that's where I came across a YouTube video by John VE6EY called "GNURadio Embedded Python Block" which neatly describes a fundamental aspect of how the GNU Radio framework actually operates.

One of the blocks available to you is one called "Python Block", which you can add to your flowgraph just like any other block. What sets it apart from the others is that you can open it up and write some Python code to process the signal.

When you first insert such a block, it's already populated with some skeleton code, so it already does something from the get-go and that's helpful because if you break the code, you get to keep both parts.

Seriously, it allows you to figure out what you broke, rather than having to worry immediately about how specifically the code is wired to the outside world, which let's face it, is not trivial. If you're a programmer, think of it as the "Hello World" of GNU Radio.

If not much of that means anything, think of it as a variable electronic component. If you need it to be a capacitor, it can be that, or a transistor, a whole circuit, or just a filter, all in software, right there at your fingertips and no soldering required.

Now I'm under no illusion that everybody is going to want to get down and dirty with Python at this point, and truth be told, I have a, let's call it "special" relationship with the language, but that is something I'm just going to have to get over if this project is going to go anywhere.

For my sins this week I attempted to recreate the intent of John's video on my own keyboard and discovered that debugging code in this environment might be tricky. It turns out that you can actually print out Python variables within your code and in the GNU Radio environment they'll show up in the console inside the companion window, which is handy if you committed one of many Python sins, like say attempting to compare an integer against a list. Don't ask me how I know.

One thing I'm planning to attempt is to get the same thing going for C++ output. By default GNU Radio Companion uses Python, but you can change it so instead of generating Python, it can generate C++. Whilst I have no immediate need for that, I do know that at some point it's likely that I will, like say when I want to run something on an embedded processor, or some other contraption. So, whilst I have nothing to lose, I want to try out the boundaries of my new toy, besides, I have form, in testing boundaries that is.

I'm Onno VK6FLAB

Foundations of Amateur Radio

In the analogue world you throw up an antenna, turn on your radio, tune to a station and sound comes out. Aside from propagation restrictions, you don't particularly care when you do this. In contrast, if you fire up a WSPR or Weak Signal Propagation Reporter, each transmission lasts 110.6 seconds, every 120 seconds, starting on the even minute. An FT8 signal takes 12.6 seconds within a 15 second window. In other words, to use WSPR or FT8 you need to both transmit and receive at the right time for this to work.

You don't need to go to modern modes to get the idea that time matters.

Listening to any CW signal will give you an idea that time and timing is important. To give you a sense of what I mean, if you turn on your radio in the middle of a dah, in the middle of a letter, you're likely to hear the wrong symbol, perhaps decoding the partial dah as a dit and missing the first part, hearing a partial letter Q, dah dah dit dah as a dit dit dah, the letter U, and that is completely ignoring inter letter and inter word spacing.

The point being that time matters for radio signals.

So, if we're going to build a system that can handle radio signals inside a computer, we'll need to deal with time.

Decoding is one thing, but what if you want to compare two radio signals from two different antennas? You can build a direction finding tool consisting of multiple antennas that can determine the direction of a signal by calculating the difference in time between when a signal arrived at one antenna and when it arrived at another. Of course, the distance between each antenna matters, so we'd need to deal with time in such a way that we can actually measure this. RF travels about 30 centimetres in a nanosecond.

If that's not enough, what happens if you're digitising an analogue signal and sending it across the network to be processed? Not only do you need to track if information arrived at its destination or was lost in transit, if you're combining multiple signals, you'll also need to know when the information was captured.

Which brings us to something entirely different and perhaps surprising. If I say "now", that moment is not the same for everybody on the planet. You might be listening to this on the train to work, your local repeater, on YouTube, or reading it on social media or in your email. Even me writing the word and reading it out loud are two different times.

In other words, agreeing on time is not obvious.

We could all look at the clock and share the information, but is that accurate enough? Do we tell each other how many seconds past midnight UTC, or do we need to know half or tenths of seconds? To use WSPR and FT8 it's generally enough to use the NTP or Network Time Protocol. It can be as accurate as 1 millisecond, but is that enough?

To give you a sense of how precise we might need to be, a HF signal takes about 66 milliseconds to travel halfway around the globe. A mobile phone tower signal travels 6 kilometres in about 0.02 milliseconds, so NTP isn't really precise enough for what we might need.

If you've played with a GPS, you might know that you can use it to determine when "now" is. It's theoretically capable of a 14 nanosecond accuracy, but by the time you actually use it, it's more like 100 nanoseconds.

There's a million nanoseconds in a millisecond and a billion nanoseconds in a second. If you were to store nanoseconds as a 64-bit unsigned number, you could count between now and just over 584 years from now.

Something else to consider. If you had two analogue to digital converters and you wanted to synchronise them, 1 nanosecond would allow you to get two 1 GHz signals to start at the same time, providing that you knew what time it was to that level of accuracy. If you're keen, look up maser.

Before you point out that this means we'd be limited to anything below the 23cm band at 1.2 GHz, I'd like to mention that this is about representing all of it, 0 Hz to 1 GHz as one chunk of spectrum at the same time. In reality, you're much more likely to only want part of that, not to mention that we'd need to transport and process all that data as well.

Which brings us to bandwidth considerations, but that's a conversation for another time.

Credit to Nick VA3NNW, Kent AC1HJ, Dave VK6KV and Randall VK6WR for their thoughts and explanations. Any mistakes are all mine, feel free to point them out.

I'm Onno VK6FLAB