Reports welcome!

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

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

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

Just in case you're like me living under the mistaken belief that the only Rapid Antigen Tests available are for COVID.

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

One of the major RF test equipment suppliers (Rohde & Schwarz) has published a FREE 129 page technical note on making common measurements using a spectrum analyzer. While focused on using R&S equipment, many measurements are also applicable for those with other brands (even lower cost home lab equipment like TinySA-Ultra, etc.). Includes background theory and how-to-measure step-by-step walk throughs. A fun read for geeks!

Credit: @n8dmt@mastodon.radio

On Christmas Eve morning, Tuesday December 24th 2024, SAQ Grimeton is scheduled* to be on the air, to send out the traditional Christmas message to the whole World, using the 200kW Alexanderson alternator from 1924, on 17.2 kHz CW.

Visitors are very welcome to the transmitter hall at Grimeton radio station to experience the SAQ transmission. Free tickets here: https://grimeton.entryevent.se/ticketshop/events/julaftonsandning

Program and transmission schedule:

• 08:00 CET (07:00 UTC): The transmitter hall at World Heritage Grimeton is opened for visitors.

Transmission & YouTube Live stream:

• 08:25 CET (07:25 UTC): Live stream on YouTube begins.
• 08:30 CET (07:30 UTC): Startup and tuning of the Alexanderson Alternator SAQ.
• 09:00 CET (08:00 UTC): Transmission of a Christmas message from SAQ.

Live Video from World Heritage Grimeton Radio Station

The transmission event can be seen live on our YouTube Channel.

Live Video Stream from World Heritage Grimeton Radio Station.

• Scheduled at 08:25 CET (07:25 UTC) on Dec 24th, 2024.

Test Transmissions

We are planning to carry our some test transmissions on Friday, December 20th, 13:00 – 16:00 CET (12:00 -15:00 UTC). SAQ will be on the air shorter periods of time during this interval, when we will be carrying out tuning, tests and measurements. Your comments are welcome to info@alexander.n.se.

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 cq@vk6flab.com.

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

Do you know of a table comparing the capabilities of SDR protocols like rtl_tcp, soapy, openhpsdr, spyserver and no doubt a dozen I'm not yet aware of?

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

This is a sobering post that revisits the notion that given a project, how many developers have to be hit by a bus before it stalls.

According to the methodology explained in the article, in 2015 it took 57 developers for the Linux kernel to fail, now it appears that it takes 8.

That's not good.

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