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

Bald Yak, week 2

During the week an interesting question was put to me. Am I going to make this into a GNU Radio tutorial? In short, no and yes. At this point I know enough about what I'm attempting, to recognise that I'll be deep diving into the bowels of GNU Radio and the inevitable idiosyncrasies that a large project like that has and as a result I'll likely have to explain the context in which something broke, which will no doubt result in me having to walk you through the details.

So, this means that there will be trips into how this thing works, but I'm not currently planning a GNU Radio course, not only because that's not what Bald Yak is about, but because I like to know what I'm talking about, even if the peanut gallery might at this point call out: "Why start now?" -- yes, from time to time, what I'm talking about here is based on something I'm still in the process of learning and obviously I make mistakes.

Now, if you haven't been playing along, let me state the purpose of why I'm here.

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

In the pursuit of happiness, I've been resisting making a table with the various communication protocols in use to extract data and control the data stream within the software defined radio world. I've been avoiding this because I don't feel like I know the landscape well enough. Of course, making the table will create a better understanding, chicken and egg.

I do have a handle on what functionality is required. So, in the spirit of writing it down or it didn't happen, here's what I know.

This thing needs to be bi-directional because it needs to be able to receive and transmit. I don't yet know if this functionality needs to be symmetric. What I mean by that is that I don't know if both directions need the same functionality.

Consider for example a distributed receiver decoder.

Imagine a device that spits out bytes at a particular rate. These bytes represent received radio signal. How and what they are specifically I'll leave alone for the moment. This information needs to be read and processed. The processing could happen on the same computer, or it could be a separate computer connected to the local network, or a remote network across the internet. There could be more than one computer doing the work.

We could choose to send the whole stream of bytes, our radio signal, to every computer. This is how YouTube works when multiple people watch the same video - and yes, I'm ignoring caching for the moment. It requires a boatload of network bandwidth and hardware.

You could send part of the signal to a receiver, this is how WebSDR works. This requires a mechanism to select and control each part of the data stream.

A third option is to use a networking technique called multicast. It provides a way to send a data intensive stream, like our radio signal, to multiple computers simultaneously. NASA uses this to distribute radio signals all over the place. I used it in the early 1990's to broadcast a live radio show I hosted, Online Computing Radio, across the globe with listeners in Sweden, Switzerland and Greenland whilst I was in a radio studio in Perth, Western Australia. This only to say that multicast has been around for a long time. Another way to look at this is that a radio transmission is a multicast signal. As long as you're within range, anyone can receive the same signal.

To keep track of what we were talking about, this is discussing how a digitised received radio signal is distributed to various computers for processing.

Each of those three methods can be combined in interesting ways depending on requirements. For example, a spectrum logging tool might expect the entire stream, but an FM decoder might only want one little slice, a RTTY decoder might want a different slice and an FT8 decoder yet another.

Before I go on, let me come up with some terms. No doubt these will get refined, but for now, I'm going to define a receiver as a computer that acts as a destination, or sink, for a stream of radio bytes across the network. Similarly, I'll define a computer that generates a source of radio bytes as a transmitter. I'm not yet sure what to call the computer that's physically connected to the antenna, but I'll start with using the term "antenna node". This isn't strictly accurate, since there's more than an antenna there, but I have to start somewhere.

I note that GNU Radio calls a transmitter a source and calls a receiver a sink. With that nomenclature, our "antenna node" would be considered both a sink and a source, which doesn't really help us here.

Back to the receiver. All of this needs some form of control intelligence, as-in, a receiver needs to be able to control where the signal comes from, or said differently, you need to be able select an antenna node. Not only that, you need to be able to tell the antenna node specifically what data you want and perhaps in what form.

Now, on the reverse side of this, the transmit chain, do we need the same functionality? Does an antenna node need to be able to accommodate multiple transmitters? Does such a thing exist? Do we want it to exist? How would we get one data stream from the transmitter to the antenna node? How would we do this with multiple streams? Is the same control system required?

At this point you're likely to realise that this isn't trivial. We can pick something and just start, but I'd like to spend at least a little amount of time considering the options.

With over 40 years in the computing field I'm leaning towards making the transmit and receive identical because we don't yet know what we don't know and besides I can sort of see how multiple transmitters might use the same antenna node and what the real world applications of this might be.

Something else to wrap your head around, what if the transmit logic was the reverse of the receive logic, as-in, the same thing, just swapping sink and source around. It has a certain elegance about it, even if I don't yet know how this might be achieved.

I'd also like to take a moment to thank Kevin VE7ZD, Nick VA3NNW and Mark W1MM for their thoughts and suggestions. Keep them coming.

I'm Onno VK6FLAB

In the process of developing something from scratch there are a great number of things that need doing. When you start it's unclear what's the most important thing, but experience has told me that starting, anywhere, is the best way to get runs on the board.

Here's a smattering of what I'm talking about. What do we call this thing? How will we license it? What does it do? How will we determine what is required and what is nice to have? How will we avoid reinventing the wheel and how will we make sure that it's something that people want, rather than yet another solution looking for a problem?

I started by looking at what else is going on. Specifically, the Software Defined Radio or SDR world isn't something that arrived yesterday. There's lots of stuff around and plenty of it is open source, so we can look inside and learn.

I asked around to see if there was a table that compares how the various SDR tools talk to the world, or rather what protocol they use. Think about how you'd get the data from a radio to a computer and how you'd control the radio and the data flow. Now imagine that neither are in the same room, or even in the same country. I started writing down what I think is needed, and then realised that this replicates stuff that has already been done. Tools like rtl_sdr, soapy, OpenHPSDR and spyserver already do some or all of this, there are others. Thus the request for the table.

This resulted in no table, but plenty of questions, including a discussion about protocols versus drivers, which lead me to the realisation that I'm going to be doing a lot of yak shaving before this project has anything to show for itself.

This neatly prompted the idea that by the time I was done, the yak was going to be well and truly shaved and now the project has a name, "Bald Yak".

At some point it appears that there was a coffee shop in 2012 with that name and there was an engineering student using it in 2004, so no major conflicts I can see, but feel free to point out any I missed. "Bald Yak" works as a name, two words, no hyphen, because it says nothing about what the project is about, which is what you do when you cannot think of a suitable relevant name, and you'd have to admit it rolls off the tongue better than "Amateur Radio GNU Radio Project" or "ARGRP".

Another consideration is how to license this thing, whatever it is. As you might know, I'm a firm believer, advocate, user and contributor to something called Open Source Software. It essentially says that if you distribute the software, you are required to share the source code. Lofty goal, but the outcome is not particularly equitable.

Bruce Perens K6BP is the creator of the Open Source Definition, derived from the Debian Free Software Guidelines where he was the primary author in 1997. In other words, Bruce has embodied these concepts for almost half my life.

Bruce says this about Open Source today:

"Open Source is the infrastructure of business, but the economic structure of Open Source is one of resource extraction like logging or mining: many businesses extract wealth from Open Source, but do not return significant value to the developers."

Bruce is in the process of developing something called "Post Open" that attempts to address this inequity. Full disclaimer, I've been commenting on some of what Bruce is doing and he has graciously accepted most of my suggestions.

I'm not yet a convert, but I think that what Bruce is attempting is crucial for the future of sustainability of the Open Source community.

Which brings me back to licensing. How do we license "Bald Yak" and how do we strike a balance between eating food and allowing others to play with our toys? If you have suggestions, please let me know.

For now I'm storing my stuff locally but fully plan to show and tell once I've figured out how.

So, what is "Bald Yak"?

Here is what I have so far.

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

I hasten to add that this is a work in progress. I'd like the definition to be small and specific. If it can be improved, please feel free to make your pitch. My email address is [email protected].

I'll also point out that this is slow, deliberately so. I want this to be fun, but I also want this to be real. I also need to manage my own life, family, health, finances and humour, so be gentle.

I'm Onno VK6FLAB

Thirteen years ago I opened my mouth to express my thoughts on what to do with an amateur license after hearing an operator complain they needed more power to talk to a station across 600 kilometres, whilst I used the same 10 Watts to communicate with a station nearly 15,000 kilometres away.

In all, I've shared my thoughts some 700 times, documenting my journey though this majestic hobby, describing what I've been up to, reporting my successes and failures, sharing my observations and making recommendations. I've built projects and attempted to start new processes, I've encouraged, cajoled, on occasion berated or applauded as I found it. Throughout the experience I've attempted to build this wonderful community, to inspire and to grow it. Sometimes I might even have succeeded.

I could not have done this without you. So, thank you. If I haven't mentioned your name or responded to your email, it's not because I didn't see your contribution. You have delighted me and lifted me up and I thank you for sharing your thoughts.

At this point you might wonder if I'm hanging up my microphone and to that I say: No, not even close. Instead I'm continuing with this experiment, rough and ready though it is.

It occurs to me that over the years I've started a great many projects and documented them as they happened, either here, or on my vk6flab.com website, or on GitHub. These projects take time and effort that go beyond what you encounter here. Sometimes it's hours, sometimes it's weeks. Recently a lot of my musings have been about things I've wanted to do, rather than describing things that I've done. Mind you, not for lack of desire.

I want to try something different.

I'm going to, at least for the next little while, bring you along with a project as I'm building it. No doubt I'll get distracted by squirrels along the way, but I'm going to attempt to build something for us as a community, for amateur radio, because I want to actually do something, rather than talk about it and I need to manage my limited resources and this way I get to build something and you get to have me sharing my thoughts. From my perspective, win-win.

So, let's dive in.

Amateur radio is a hobby that takes all kinds. A lot of activity is curtailed by money, or rather, lack of money. That doesn't have to be the case and I think I can show you how. That's not to say that this is going to cost nothing, but you can likely start with what you already have and work your way up as your budget allows, rather than require a significant outlay just to get your toes wet.

Over the past few weeks I've been talking about a toolkit called GNU Radio. It can be used to build systems that can process data, like say radio signals which come in all shapes and sizes. You can start by connecting an antenna to a sound card and use that as a radio tuner. You can also use a sound card as a way to listen to signals coming in via the Internet, or a radio you might already own. Sound cards exist in most computers but can be purchased for around $10. If you want to handle more data, you can spend $50 and use an RTL-SDR dongle. This incremental path continues. You can build a digital radio, or buy a learning kit, or something else, all the while still being part of the same ecosystem.

I want to build a system where you can experiment with radio without needing to buy new hardware every time you want to try something new. I want it to work with a sound card as well as with the latest $7,000 radio you can get shipped to your door. I want to do this in such a way that we can start to embrace all that is possible within the realm of software.

Ultimately I want to be able to use any signal source anywhere and GNU Radio seems ideally suited as the tool for the job. I envisage that we'll build a distributed system, where signal processing and the signal itself don't have to be in the same spot, which is useful for a whole host of reasons, even though it increases the level of complexity by at least an order of magnitude.

This isn't going to be easy. It's not going to be working tomorrow, perhaps not even a year from now and as long as new radios are invented, it will never stop, but we'll see how it goes. For example, I spent a week attempting to install GNU Radio on my Macintosh, asked two expert groups and got nowhere. In stark contrast, I installed it on my Linux Debian workstation and the example I tried worked out of the box. In other words, plenty of obstacles to overcome.

Before I go, I'll make this explicit. I want this to be open source, so anyone can play. I haven't yet decided on which specific license to use, but I'm cognisant that there are many large companies making obscene amounts of money from the volunteer efforts of the open source community and as one of the volunteers, I'd like to be able to pay for food and a roof over my head.

I expect and appreciate your feedback, so don't be shy.

I'm Onno VK6FLAB

Have you ever attempted to download an email attachment, or watch a streaming service whilst your microwave was cooking lunch or dinner and noticed that something odd was happening, or is my asking that question the first time that you joined the dots?

This phenomenon is not by accident, though it isn't on purpose. In 1947 the International Telecommunications Union, the ITU, was meeting in Atlantic City where the "delegate of the United States, referring to his request that the frequency 2450 Mc/s be allocated for I.S.M., indicated that there was in existence in the United States, and working on this frequency a diathermy machine and an electronic cooker, and that the latter might eventually be installed in transatlantic ships and airplanes. There was therefore some point in attempting to reach world agreement on this subject."

Several things to unpack there. It's 1947 and experimentation is happening at 2,450 Mega-Cycles per second, what we call megahertz today; you might recognise the frequency as 2.45 GHz.

At that time, experiments using radio frequencies for medical purposes has been in full swing for decades. Nikola Tesla wrote a paper on the subject that was presented in absentia to the American Electro Therapeutics Association in 1898.

In 1947, a diathermy machine exists; today its used to aid with blood flow, muscle and joint pain as well as inflammatory and degenerative bone disease.

There is a working electronic cooker, a microwave oven to you and I, and whilst the one you could buy in 1947, a Raytheon "Radarange", if you forked over $5,000, or $70,000 in today's money, had space for a 2 meter tall, 340 kilogram, 3 kilowatt behemoth, you have to admire the imagination that one day this would fit on an aeroplane to travel the world, let alone be available for $100 at your local supermarket.

One other thing, I.S.M. or Industrial, Scientific and Medical is a concept we still use today. The idea being that there are uses for radio waves that are nothing to do with communication, like microwave ovens, steel smelting through induction heating, surgical uses like cauterising wounds, some cancer treatments and plenty more.

One of the ideas behind ISM is that equipment operating in those frequencies must tolerate any interference generated by ISM applications. The other part of the ISM idea is that it's unlicensed, which is very attractive to people who experiment and why it became popular for other uses beyond heating your lunch.

Consider that baby monitors, garage door openers, car security systems, video senders, cordless phones, wireless speakers and microphones, cordless keyboards and mice, radio controlled models, and smart power meters all share the same radio frequencies.

Then there's Wi-Fi, Bluetooth, and Zigbee, also using the same 2.4 GHz ISM band.

Yeah, even the two most popular network technologies on your phone and computer, Wi-Fi and Bluetooth are competing with each other and the microwave oven in the kitchen.

There are six global ISM bands and six additional ones with specific local requirements. Things like industrial microwave ovens, Near Field Communications or NFC and LoRaWan use frequencies like that. You'll also find satellite communications, radio location, CB radio, radio astronomers and radio amateurs on those bands.

So, why are these technologies sharing the same frequencies?

Essentially because they're unlicensed spectrum. Just so we're clear, this doesn't mean that it's unregulated spectrum. All it means is that unlike licensed spectrum, you don't need to buy access to the spectrum to use it, but you do need to have compliant equipment when you do. Compliance depends on local laws, location, band and power levels.

So, next time you need to watch a movie whilst cooking lunch, eat an apple or go outside and get some daylight onto your skin instead.

A quick word on power. Whilst all these uses share the same frequency band, their human impact varies considerably. A Wi-Fi network uses a tenth of a Watt. A diathermy machine uses 250 Watts and produces a "gentle heat" at the surface of the skin, suitable for treatment. Contained inside a metal box, a microwave oven uses 1,000 Watts or more. Even that doesn't cook food from the inside out, instead it vibrates water molecules in the food, which heat up, which in turn cooks the food. It doesn't penetrate very far and doesn't work on frozen water, which is why you need to defrost your food before you can cook it. It's also why when you stand between your Wi-Fi router and the computer things slow down, or why your hand position on your phone or tablet can make a difference, since your body, made from 60% water, is blocking the signal.

Finally, here's something to consider. A licensed radio amateur has access to some ISM bands, but does it require an amateur license to actually use any of those bands? In other words, if my amateur license doesn't permit my access to 2.4 or 5.8 GHz bands, can I legally use a transmitter in the unlicensed spectrum that is the ISM band on those frequencies?

If you answered yes, and you're considering experimenting on the ISM bands, you'll find the Low Frequency Experimental Radio or LowFER, MedFER and HiFER community has already beaten you to it. Within the ISM regulations are provisions for all kinds of other experiments, generally using low power, sometimes a Watt, sometimes less, but you already know that my 10 mW beacon on the 10m band has been heard 13,945 km away, so there's plenty of opportunities to play.

I'm Onno VK6FLAB

The hobby of amateur radio is one of experimentation and change. For decades this came in the form of circuit diagrams, components and scrounged hardware from anything that wasn't bolted down. New functionality came with the aid of a soldering iron.

More recently, functionality comes from participation in the global electronics market where you can buy any radio you like and have it shipped to your door within hours at an unbeatable price.

Mind you, buying all those unbelievably cheap radios does start adding up and if you want to use more sophisticated hardware, that too is possible, at a price, somewhere between $50 and a new Porsche. Whilst that's an option for some, for the rest of us, there are better and cheaper ways.

Of course it doesn't stop there. If you connect any radio to a computer, you can use whatever software you like to encode and decode any signal you can imagine. With a traditional radio connected to a computer you can make it participate in hundreds of different so-called digital modes.

Before I continue, let's look at radio in a slightly different way.

Consider an antenna as a continuous source of voltages that are amplified, filtered and demodulated in some way by a radio. You can think of the combination of antenna, radio and computer as a stream decoder. To decode a signal in a new way requires a new decoder, which you could build from components or as I've said, buy online.

During the week I've continued experimenting with GNU Radio. If you're unfamiliar, it's a toolkit that allows you to build so-called flow graphs that can process a signal stream. Think of it as a box of Lego that you can put together to build any type of decoder.

Let me say that again.

Imagine that you want to decode or transmit a mode like FreeDV, M17, APRS, Olivia, Contestia, or Hellschreiber. With the GNU Radio toolkit, all of this is possible and you won't need to buy new hardware or bust out the soldering iron every time you want to experiment with a new mode.

If you have been playing with digital modes already, you'll likely point out that you can already do this today by using software running on a computer, and that's true.

What that doesn't tell you is that this comes with a very specific limitation, namely that all those modes require that they fit inside a single audio channel because all those digital modes you might be familiar with are essentially using an SSB or FM signal with the audio generated or decoded by a computer.

Even if you have a modern radio like for example an ICOM IC-7300, you'll still be limited in what modes of transmission you can make. ICOM limits the transmit bandwidth to 2.9 kHz. Flex Radio appears to double that to 7.9 kHz, but numbers are sketchy. The point remains, most current amateur radio technology is based around the notion that a mode essentially fits within a single audio channel and a very narrow one at that.

So, why does this matter?

If you run out of FT8 space on a band, right now you need to change to an alternate frequency to play, but you'll only be able to see the stations that are using the same alternate frequency, as long as they fit within the bandwidth of an audio signal. If you wanted to check out the main frequency, you'd have to change frequencies and keep switching back and forth. Using this idea, monitoring all of FT4, FT8, WSPR and all CW beacons, all at the same time becomes unimaginable, not to mention costly if you needed a radio for each band and each mode.

What if you wanted to use another mode that took more than about 4 kHz, like say a 5 MHz wide DVB-T signal which you could be experimenting with on 70cm?

Or, what if you'd like to compare a repeater input with its output at the same time? Or compare two repeaters together? Or find the best band to operate on right now?

The point being, that there are things that simply don't fit within a single audio channel that you won't be able to play with using a traditional radio.

As it happens, that too is a solved problem.

Remember that I mentioned that you can think of an antenna, radio, and computer combination as a stream decoder?

What if I told you that an SDR, a Software Defined Radio, is essentially a device that translates antenna voltages into numbers which you can process with GNU Radio?

Whilst that does imply replacing your radio, you don't have to jump in at the deep end to start playing and even if you do decide to buy new hardware, you can get your toes wet with all manner of self build or commercial kits. Even better, you can start with the gear you already have today and become familiar with GNU Radio and when you're ready to expand your station, you can add in an SDR and continue to use the same tools to experiment.

Not only that, you can do interesting things by combining what you already have. Consider for example the idea of using an RTL-SDR as the receiver with a traditional radio as the transmitter. You could decode all of the FT8 signals on a band and transmit where there was space to do so.

The point being that you can do this one step at a time. Every time you download or build another GNU Radio flow graph, you can have a new decoder and as time goes on, you'll be able to decide what hardware you might want to pair it with.

To be clear, I'm talking about the gradual change from component based radio using audio interfaces into software based radio. It's not like we haven't done this before. Anyone recall spark gaps, or valves?

The future of experimentation is bright and it's filled with bits.

I'm Onno VK6FLAB

Over the past weeks, actually, probably more accurately years, I've been carrying around an idea. It's been bubbling away and I've been trying very hard to make it solidify into something that I could explain and then hopefully attack.

Today I woke up with a hunger to do some radio and ultimately tell you about it. To get to a point where my Aha! moment emerged, I need to provide some history.

Traditional radio activities involve variations on a radio plugged into an antenna with the operator talking into a microphone or torturing a Morse key. If you want to operate digital modes, you essentially have two choices. You can use a rare radio with in-built digital modes or, more commonly, connect a computer to the radio via an audio interface, which essentially replaces the operator with a computer.

This implies that the radio is physically connected to the computer and in the same room.

What if you don't want either?

There's another aspect to this.

Modern SDRs or software defined radios, tend to use the network to get information from the antenna to the user. The network can transport the radio signal, but also control signals, to change things like frequency and mode, and if the radio supports it, bands, antennas and other fun stuff like filters.

There are ways to control a traditional radio across the network with so-called CAT commands, or Computer Assisted Tuning. This same technology can be used to connect a logging tool, so it knows what frequency and mode to log when you make a contact.

What CAT control lacks is audio. Said differently, although some solutions exist to send Morse code, you cannot use CAT to listen to the radio, or speak into a microphone. This isn't an issue if the radio and you are in the same room, but if they're not, then things get tricky.

And as a final piece of background information, a traditional radio is based around audio, that is, the information going between you and the radio, or a computer and the radio, is limited to audio. This represents about 4 kHz of signal. In other words, if you're tuned to 28.500 MHz, then a traditional radio can "hear" the radio signal between 28.500 and 28.504 MHz, sufficient for a single audio signal, but even a simple digital radio, a $50 RTL-SDR using a USB cable, can handle 2.4 MHz, plenty to cover all of the 10m band between 28.0 and 29.7 MHz with room to spare.

I've been looking for something, anything, that brings these two vastly different worlds together for a number of reasons. I've spoken previously about some of these. For example, I do not want to physically connect my traditional radio, a Yaesu FT-857d, to my computer because I do not want to have the potential of stray RF coming into my computer.

I'd also love to be able to run the same decoding and control tools for various radios, the Pluto SDR, several RTL-SDR dongles, my 857 and other radios as they come into my shack from time-to-time.

Then there's the signal processing side of things. I'd love to be able to learn how to decode Morse and eventually other modes using a computer. I also want to be able to use a voice-keyer during a contest so the whole house doesn't ring from the sound of me calling CQ Contest, or CQ DX for hours on end.

I've been making inroads into this. I managed to get rigctld to work across the network using Docker containers at both ends. I attempted to get audio working, but that has so far been a dismal failure, despite assistance on several fronts.

This morning I stumbled on the idea of using "GNU Radio" for both. I even came across some examples where two so-called "flow-graphs" can talk to each other across the network. Now at this point you're either going to be nodding your head, or you're going to be asking yourself what gibberish I just spouted.

If you're already nodding your head, stand-by, if not, GNU Radio is a software toolkit that provides signal processing blocks that you can link together to create simple or sophisticated systems to manipulate signals, like those that come from radios, or radio telescopes, or mobile phone base stations, radar, ADS-B, or whatever else you can imagine. It's widely used in academia, government, industry, research, and of course by us, hobbyists.

A collection of blocks and links is called a flow-graph and in essence it's a program or if you like, an App, that you can run. It comes with a tonne of examples and tutorials, including one where one flow-graph can manipulate another, either on the same computer, or somewhere on the Internet.

What this means is that you could build a flow-graph that can talk to a Yaesu FT-857d and one that can talk to a Pluto SDR, or an RTL-SDR, or any other radio, and use that to talk to a flow-graph that understands how to deal with audio, CAT and anything else you might want to.

It means that for the first time in years I can at least imagine a unified world where my 857 isn't a boat anchor when compared to my Pluto SDR. Of course they don't have the same functionality, but at least I can handle their signals in the same way.

Unlike the path I was previously on, where I was attempting to cobble together several tools whilst attempting to avoid a headache from banging my head against the wall, today I can use one toolkit to build Apps that run on pretty much anything with a CPU and see the fruits of my labour.

I'm working on a proof of concept and when I've got it to show-and-tell, I'll put it up on my GitHub page, cunningly named after me, VK6FLAB.

A final observation. Amateur radio means different things to different people at different times. For me, today, it's about software and GNU Radio. Tomorrow it is just as likely to be about something else. What is possible depends entirely on your imagination, so get playing, either on-air, or on-line, whatever gets you smiling and remember, the impossible happens immediately, miracles take a little longer.

I'm Onno VK6FLAB

One of the oldest global aspects of our hobby, other than actually using the radio, is the QSL bureau. It uses a postcard-like system to confirm that two stations made contact, sent via the postal service as a so-called QSL card. Of course, that only works if you have each other's address which after World War II was somewhat difficult. As a result the QSL bureau was born.

Intended as a single point of contact for a country, a local QSL bureau consists of one or more volunteers, paid staff or contractors, who act as the distribution point for incoming and outgoing QSL cards. If you and I agreed to confirm our contact via the bureau, my QSL card to you would be sent to the VK outgoing QSL bureau, which would hold my card until there were sufficient outgoing cards from all over Australia to your country to package them all up and send them to the incoming QSL bureau in your country.

Your QSL bureau would then wait until there were enough QSL cards for your region to send it on, where it would eventually get into your hands in a variety of ways, via the postal service, through your local club, or at a local hamfest where the QSL bureau might have a stall. Your QSL card to me would make a similar, reverse, journey.

This process could take weeks or sometimes years.

Although not fast, this worked for many decades, but once electronic communications and computers started appearing, combined with increased costs associated with privatised international postal services, the wheels started coming off.

Getting access to historic documents has proven challenging. I can tell you that over the years the IARU, the International Amateur Radio Union, has coordinated and controlled how the QSL bureaus should work. For example, a resolution adopted in 1985 and updated in 2009 "strongly encouraged" its member societies to accept incoming QSL cards for all amateurs in their country, regardless of affiliation. It also instructed QSL bureaus to only send cards to the official QSL bureau if there was more than one.

Several years ago, the IARU administrative council recognised several trends, among them the environmental impact of unwanted cards generated in bulk by computer logging software, lower levels of adoption and ultimately the closing of some smaller QSL bureaus after being overwhelmed by undeliverable cards from increasingly popular holiday DXpeditions.

In September 2018, the IARU adopted resolution 18-1 that stated that it "resolves that member societies are encouraged to continue to offer QSL bureau service in their countries, exchanging cards with the bureaus of other member-societies, for as long as doing so is economically justifiable, and further resolves that amateurs are encouraged to adopt confirmation practices, including but not limited to using electronic confirmation systems, that reduce the volume of unwanted and undeliverable QSL cards being introduced into the bureau system."

This resolution took effect on New Year's Day, 2019. I'll also note that the IARU has its own year 2000 issue, having been in existence for nearly a century, its resolutions are named after the last two digits of the year followed by a sequential number, so resolution 25-1 could refer to 1925 or 2025, but I digress.

The internet has introduced several confirmation processes. The most vocal of these is "Logbook of The World", or LoTW. I'm not a fan and haven't been for some time. I'll get into why in a moment. Other contenders are eQSL.cc, qsl.net, qrz.com, clublog.org and others that have yet to steal the limelight. If I've forgotten the one you run, let me know.

Saying that I'm not a fan of LoTW is understating it. Recent ARRL ransomware payments aside, why do I need to legally prove beyond a reasonable doubt that I made contact with some random amateur? Why does this need to be authenticated, signed with a time-limited certificate and verified with 100 points of identity and why do we continue to roll out new and interesting procedures for what is essentially a postcard saying that on this day, time and frequency we made contact using this mode for the purposes of .. wait for it .. our hobby?

The eQSL website has an interesting statement: "One of the problems with an e-mail based system is that there is no security inherent in that mechanism. Anyone can purport to be P5ABC, and you'll have a difficult time verifying it."

So what .. and what made you think that the postcard ending up in your letterbox was guaranteed to be from P5ABC?

If you're going to the effort of pretending to be P5ABC, what harm does that do in the scheme of things? For that matter, how do you know that the station you talked to on-air was actually P5ABC? I ask because I've spoken to an amateur who recently did some HF direction finding during several popular DXpedition pile-ups. They discovered that there were several stations purporting to be the DXpedition that were not.

So. Right now we're in a situation where many if not all amateurs are connected to the internet. Most will have an email address. You already know mine, [email protected]. If we made contact on-air, send me an email. If what you wrote matches my logs, I'll send you a reply to confirm it.

How do you get the address? One possible approach is to create an online email database where you could submit the email address associated with your callsign and you could look-up a station to contact them.

Another is for member societies to offer email addresses, the ARRL and the WIA already offer this service to current members.

I'll also point out that one of the reasons that the QSL bureau was instigated in the first place was because some addresses for amateurs were not available. If you make contact today and you want to send them an email confirmation the question to ask is simple: "Hey, what's your email address?"

Will that cover everyone?

Nope. Neither does the current system. What it achieves is that my personal private identifying information isn't stored at the ARRL if I'm not a member. Besides, in my opinion a list of email addresses combined with callsigns is hardly something worth getting excited about, unless of course it's used by manufacturers to send out product announcements and discount codes. We should be so lucky.

If you have a better idea, you know how to get in touch. What I can say is that this is the ultimate decentralised QSL system, not unlike the contact you made on HF.

I'm Onno VK6FLAB

One of the unexpected benefits of this hobby is how it provides you with the ability to connect to others in ways that are not directly related to radio.

Take for example Steve. Steve appears at unpredictable times and locations, been hunted by citizens and scientists and unlike Steve's potential invisible cousin, the proton arc, has been photographed by aurora hunters many times. It looks like observations go back as far as 1705.

In 2017, physics professor Eric Donovan saw some of these photos and got curious. Assisted with GPS coordinates from an aurora hunter in Alberta, Song Despins, Eric correlated the time and location and it turns out that Steve was observed as a ribbon of gas 25 kilometres wide, 300 kilometres above Earth with a temperature of 3,000 degrees Celsius by the European Space Agency's Swarm, a constellation of magnetic field measuring satellites in orbit since 2013 and planned as a four year mission, so-far it has almost managed eleven years.

Steve? Yeah, it's not named after Steven Hawking or Steve Martin, rather, if you're seeing something unexplained, you might name it something less scary, like the hedge in the movie "Over the Hedge". Steve was given a backronym, finding words after the fact, Strong Thermal Emission Velocity Enhancement, but I prefer Steve. The NASA team at Goddard Space Flight Center have adopted Steve, so it looks like a keeper.

I would never have even stopped to read the recent article in the local news, let alone dig into the various publications, if it weren't for the notion that Steve is one of many phenomena affecting the ionosphere and with it our hobby.

Here's another example.

Vance KV4P published a plan on kv4p.com, outlining a $35 project that requires minimal soldering that makes any Android phone into a handheld radio for 2m. Using a radio module, a micro-controller, a short USB cable, antenna connector, antenna and some sticky gel pads, Vance has come up with an open source project and circuit-board design that will get you on your way. He's even designed a 3D printable enclosure so you don't have to scare your friends with a bare circuit board.

Whilst the Android app is in beta, that is, not quite fit for human consumption, you'll need to drop an email to Vance to get in on the action. Source code is on GitHub.

I came across this project after breakfast, reading the "Y Combinator - Hacker News" which features all manner of weird and wonderful projects, links and questions from all over the technology sphere. The post has expansive discussion on Vance's project, including thoughts on other ideas on how to do interesting things related to our hobby.

Again, if it weren't for the fact that I'm already an amateur, I would never have taken more than a glance at this and I would never consider that this was a doable project, let alone discover other amateur radio projects like HamWAN and AREDN, or the Amateur Radio Emergency Data Network.

The point being that we as amateurs are often pigeonholed by society into the idea of obsolete, disconnected and quaint. I'm here to tell you that our hobby has made me more alive than ever, more connected to others around me, more observant to electrical and physical phenomena and if that makes me quaint, I'm Okay with that.

Also, while we're on the topic of being Okay. Charles NK8O reached out and told me that after listening to me talk about FT8 and his Morse code achievements, he cracked up and then raised the stakes by pointing out that you can get on HF with CW, that's continuous wave, or more commonly, Morse Code, for about $100, where a kit capable of SSB, Single Side Band, or more generally audio, will likely set you back significantly more. His advice, which I cannot fault, "Get on the air!", presumably to make some noise.

I'm Onno VK6FLAB

Every now and then you come across an idea that throws you for a loop. It comes seemingly out of nowhere and once you've seen it, you cannot unsee it. It's a lot like a 1929 painting I like called "The Treachery of Images", also known as "Ceci n'est pas une pipe", or in English, "This is Not a Pipe" by Belgian surrealist painter René Magritte. If you're not familiar with it, it's a painting of a pipe, and by being a painting, it's not a pipe. Obviously.

Before I go into the idea that rocked my world, I need to set the stage a little.

There are several modes I've discussed before, WSPR, or Weak Signal Propagation Reporter, FT8 or Franke-Taylor design, 8-FSK modulation and plenty others.

Each of these modes has one thing in common. They require that all participants are using the same time. That is, both sender and receiver need to agree on when "now" is for this to work.

A WSPR signal takes 110.6 seconds, every 120 seconds, starting on the even minute. It requires that the transmitter and receiver agree on the time within about 2 seconds.

An FT8 signal takes 12.6 seconds within a 15 second window. It requires an accuracy of about 20 milliseconds.

These timekeeping requirements are pretty easy to achieve in a modern network connected computer. You turn on a thing called NTP, or Network Time Protocol, point it at an appropriate clock and off you go.

If you're not connected to the Internet, then things get squirrelly pretty quickly. You could buy yourself a GPS, set up a link between the GPS and your computer, run some software and use the GPS clock to synchronise time on your computer.

Of course, this requires a GPS, a serial cable, software, configuration, battery power to keep the GPS running and probably a couple of other things. I've never done this, but given what I'm about to share, I don't think I ever will.

What if you used a WSPR, or an FT8 signal, from someone else to synchronise your clock? If you've ever launched WSJT-X, you'll have seen a column marked DT, that's Delta Time, or the difference in time between the clock on your computer and that of the transmitter.

If you could read the difference and use it to adjust your clock, you'd be in business.

Charles NK8O pointed me to a GitHub Gist with a single little Python script, written by Peter K6PLI. It updates the clock on your computer using the Delta Time from WSJT-X.

I'd point you at the script from here, but 3a730575, and 24 more characters, and that's just one element of the URL, doesn't run quite off the tongue, so I've cloned it into my VK6FLAB GitHub repository where it's called wsjt-time-sync. I added Peter's description to the ReadMe file, but I can take no credit for the effort, or the idea, that's all Peter.

So, synchronise your clock using the signal that you're trying to decode. Seems pretty obvious now, but that was a brand new notion for me.

Of course now I'm excited and wondering where else I might use this.

Let me know if there's more to this that tickles your fancy.

Also, just because I know Charles will poke my eye out with a Morse key if I don't mention this, you could use this script on your next POTA, Parks On The Air, or WWFF, World Wide Flora and Fauna activation, or anywhere else you go portable to make some noise.

I know, right, Charles, using FT8 instead of Morse Code, what's next, the end of the hobby? I'll tell you a secret. From time to time, he even uses his voice!

I'm Onno VK6FLAB