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

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

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

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

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

When you key your transceiver, as-in, you trigger the Push To Talk or PTT button, you close a switch that activates the transmitter and in turn allows your voice to make it through the microphone and radio, via the coax out to the antenna and the world. When you release the button, the transmission stops.

This is pretty much how we're taught that a radio transceiver works, essentially switching between transmit and receive, depending on the state of that magic switch.

If you want to create a transmitter in software using GNU Radio, you might get to a point where you start looking for a conditional block, a magic piece of code that you can add to the system that checks the state of the PTT button and sets the state of your contraption accordingly.

In programming terms, you might start looking for an IF .. THEN .. ELSE block, as in, IF PTT THEN transmit ELSE receive. Let me save you the trouble of looking for such a thing, because it doesn't exist.

With that revelation you are forgiven if you come to the conclusion that you cannot create a PTT system using GNU Radio. It's a perfect example of attempting to think in a certain way and I'd like to show you that there are alternatives if only to help you experience an insight into how we do the things we do.

I've told this story before, but it bears repeating. Over a decade ago I was helping with the erection of an antenna during a field day. It was a massive multi-element 10m yagi, heavy, unwieldy and precariously bolted to the top of a spindly mast strapped to the tray of a ute. Before lifting it to the top of the mast I was tasked with checking the SWR. I dutifully plugged in the coax, turned on my radio, keyed the microphone and confidently reported a 1:1 SWR. Over the next hour the antenna was manhandled into the air by half a dozen people and we set about making noise only to discover that the SWR was horrible. My lesson was that you need to whistle or hum into the microphone when you use SSB to test the SWR.

Said differently, using SSB, if you transmit no sound, there is no signal and no standing wave to measure.

Right now you're likely to picture a PTT switch as switching between open and closed. In one state nothing gets through, in the other, everything gets through. For example, you could construct a switch where in one position your analogue signal is connected to ground and disappears. In the other state it reappears. If you think about it, yelling into the microphone whilst not activating the PTT does exactly this.

A Software Defined Radio or SDR uses an Analogue to Digital Converter, or ADC, to receive an analogue signal from an antenna and convert it into a series of numbers. To transmit, it uses the reverse, a Digital to Analogue Converter, or DAC, that converts a series of numbers into an analogue signal.

No analogue signal means a voltage that doesn't change. In the digital world, it's the same, a series of numbers that don't change.

When you multiply a number by zero, you get zero and when you multiply a number by one, you get the number. So, if you were to take a digital signal, which is nothing more than a series of numbers, and multiply it with zero, you'd get a series of zeros. If you multiply it by one, you'd get the original numbers.

If you sent that series to a SDR transmitter, remember, it's essentially nothing more than a Digital to Analogue Converter, you'd get either no signal when you were converting only zeros, or you'd get an analogue signal when you're converting numbers.

So, if you made a button that changed a variable to one when you pressed it and changed it to zero when you released it, you could multiply your digital signal by that variable and switch between getting a series of numbers or a series of zeros.

Remind you of anything?

That button, that changes between zero and one is your software defined PTT. It represents the software version of a switch and it shows us that signal processing requires that you look at problems in subtly different ways.

This all to illustrate that using GNU Radio is going to take some time to get your head around. For some this happened years ago, for others like myself, we're in the thick of it.

While you're thinking about that, consider time. What type of time accuracy would you need to synchronise two signals from two different antennas and why would you want to?

I'm Onno VK6FLAB