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: @[email protected]

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 [email protected].

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

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