Foundations of Amateur Radio

Latest Episodes:

The making of a Crystal Radio Oct 18, 2020

Show notes

Foundations of Amateur Radio

Recently I made a commitment to building a crystal radio. That started a fevered discussion with several people who provided many helpful suggestions. This is the first time I'm building a crystal radio and to make things interesting I'm selecting my own components, and circuit diagram. What could possibly go wrong?

Crystal radios have been around for a while. Around 1894 Indian physicist Jagadish Chandra Bose was the first to use a crystal as a radio wave detector, using galena detectors to receive microwaves. He patented this in 1901. The advice I was given sometimes feels like it harks back to 1894, with suggestions of using cats whiskers, razor blades, and any number of other techniques that create the various components to make a so-called simple crystal radio.

At the other end of the scale there were suggestions to go to the local electronics store and buy a kit.

The first suggestions, rebuilding historic radios from parts made of unobtanium would mean many hours of yak shaving, just to get to the point of getting the components, rather than actually building the radio.

I realise that part of the experience is the journey and I'm sure that if my current project gets me hooked I'll look into it, but I really don't want to become that amateur who has a collection of home-brew crystal radios across the ages. Besides, I'm having a look at using my crystal radio as a front end to my software, so I want to keep sight of the radio part of what I'm doing, rather than the building part.

Before you get all hot and bothered, remember, amateur radio is a hobby that means different things to different people and for me I'm currently playing with software and I'm attempting to learn about the electronics principles that form the basis of our hobby.

As I said, the other end of the scale was to get a kit and build that. It has its appeal, but there's little in the way of learning and the construction part of things is pretty much putting together a kit which is something I first did when I constructed an LC meter kit a while ago. So that too doesn't really appeal to me.

Now comes the bit where I tell you what I've done to date.

On the physical side of things, nothing. On the thinking and learning and planning side, lots.

Here's where I'm at.

My current understanding of a crystal radio is that you need to detect the AM wave form of an RF frequency and pipe that into something that makes noise. Traditionally this is done with a crystal earpiece, but I saw someone use powered computer speakers with a built in amplifier, so I'm going to start with that as my first noise maker.

I should also mention that the crystal earpiece was a source of confusion. I thought that the crystal in crystal radio was referring to that one. It's not.

So, back to where I'm at. What do I need?

To start off, I cannot just connect an antenna to a speaker, since it will attempt to make sound for every known frequency, well, at least the ones that the antenna can handle that fit within the response envelope of the speaker and its amplifier. If you want to know what that sounds like, put your finger on the input plug to some powered speakers. Don't turn up the volume too loud, you'll regret it.

So step one is to make a way to only let specific frequencies through. I've previously discussed this. You might know it as a band-pass filter. You can make one using a capacitor and an inductor. If you make the capacitor variable, you can change what frequency passes. This is helpful because you don't want to be decoding more than one radio station at a time.

There are plenty of designs for crystal radios that offer hand wound inductors and home brew capacitors, but I'm not doing this to learn how to build those, I'm doing this because I want to learn how it works. I want to use readily available components from my local electronics store, so I started with building a spreadsheet that shows what the resonant frequency is for a combination of inductors and variable capacitors.

Today I learnt that I also need to pay attention to how wide this is, so I'll be revisiting this.

There are only two more components in my radio, a diode and another capacitor. The diode cuts off half of the information, since if you recall, AM uses two side-bands that are identical. At that point you have a signal that contains both the carrier and the audio signal. You need one last step, filter out the high frequency carrier. I've talked about that too, this is a low-pass filter. You can do this with a capacitor.

So, now we have the bare-bones of a crystal radio, made from four components, an inductor, a variable capacitor, a diode and another capacitor. My next challenge is to figure out what values they have so it will allow me to listen to my local AM radio station and do it using components off the shelf from my electronics store.

One thing I can tell you is that this is precisely why I signed up for this project. I don't want a ready-made radio from a kit and I don't want to have to learn how to chop down a tree in order to make a pencil.

I'll keep you posted. If you have additional reading material you'd like to suggest, feel free to get in touch.

I'm Onno VK6FLAB

An ionospheric monitoring service at home Oct 11, 2020

Show notes

Foundations of Amateur Radio

One of the more fundamental aspects of long distance radio communication is the impact of the ionosphere. Depending on how excited the Sun is, what time of day it is and what frequency you're using at the time will determine if the signal you're trying to hear from the other side of the planet makes it to you or is on its way to a radio amateur on Proxima B who is likely to hear this podcast in just over 4 years from now.

In other words, the ionosphere can act like a mirror to radio waves, or it can be all but invisible.

As luck would have it, this changes all the time. Much like waiting for the local weather bureau for the forecast for tomorrow's field-day, there are several services that provide ionospheric predictions. The Australian Space Weather Service, SWS, is one of those. You might have previously known it as the Ionospheric Prediction Service, but Space is much more buzz-word compliant, so SWS is the go.

If you're not a radio amateur, space weather can impact stuff here on Earth, like the ability to communicate, transfer energy across the electricity grid, use navigation systems and other life-essentials. The SWS offers alerts for aviation and several other non-amateur services.

If you're interested in HF communications, the SWS offers HF prediction tools that allow you to check what frequencies to use to communicate with particular locations using visualisations like the Hourly Area Prediction map.

If you're more of the Do-It-Yourself kind of person, you might be pleasantly surprised that you can have your very own ionospheric monitoring station at home. Not only that, it's probably already in place, configured and ready to go.

If you're using WSJT-X to monitor WSPR transmissions, then you'll have noticed that the screen shows all the stations you've been able to decode and you can scroll back as far as you like to the time when you launched WSJT-X.

If you want to do some analysis on that, copy and paste is an option, but it turns out that there's a handy little document being stored on your computer called ALL_WSPR.TXT that contains the very same data going back to when you installed and launched the first time.

This information represents what stations you heard, at what time and with what level of signal to noise at your shack, not some fancy station in the middle of nowhere with specialist hardware, your actual station, the one you use to talk to your friends, with your antenna, your power supply, the whole thing.

For my own entertainment I've been working on a way to visualise this. I created a map that shows the location every station I've logged, 30,000 of these reports in the past four months. It's interesting to see that I can hear most of the globe from my shack. Notably absent is South America but that is likely a combination of band selection and local noise.

In the meantime I've gone down another rabbit hole in figuring out if I can use an image file to visualise all this without needing fancy software, unless you consider a web-browser and bash fancy.

The idea being that a simple script could take the output from your station and convert that into a map you can see on your browser. In case you're wondering, I'm thinking that a style-sheet attached to a Scalable Vector Graphic or SVG might be just the ticket to showing just how many times I've heard a particular grid-square.

If you have ideas on what else you might do with this data, get in touch.

I'm Onno VK6FLAB

csdr will rock your world ... Oct 04, 2020

Show notes

Foundations of Amateur Radio

When you start playing with software defined radio, you're likely to begin your journey using something with a display that shows you a lovely waterfall, gives you a way to pick out a frequency, decode it and play it over your speakers all over the house. Likely your first effort involves a local FM radio station. These graphical tools come in many and varied forms available on pretty much anything with a display. Tools like SDR#, cuSDR, fldigi and WSJT-X.

That can be immensely satisfying as an experience.

Underneath the graphics is software that is essentially translating an antenna voltage to a sound, in much the same way as that happens in an analogue radio. There are the parts that get the signal, then they get translated and filtered, translated some more, decoded, and eventually you have sound coming from your speakers.

During the week I caught up with a fellow amateur who pointed me at the work of Andras HA7ILM who for a number of years has been quietly beavering away making various tools in the SDR landscape.

One of those tools has the innocuous name of "csdr", a command-line software defined radio digital signal processor. It started life on November 1st, 2014 and has had many updates and community changes since.

This tool has no graphics, no user interface, nothing visible that you can toggle with a mouse and yet it's one of the coolest tools I've seen in a long time and from a learning perspective, it's everything you might hope for and then some.

Before I explain how it works, I need to tell you about pipes. They're much like water pipes in your home, but in computing they're a tool that allow you to connect two programs together so you can exchange data between them.

One of the ways that you can think of a computer is a tool that transforms one type of information into another. This transformation can be trivial, like say adding up numbers, or it can be complex, like filtering out unwanted information.

The idea is that you take a stream of data and use a pipe to send it to a program that transforms it in some way, then use another pipe into another program and so on, until the original stream of numbers has become what you need them to be, creating a transformation pipeline with a string of programs that sequentially each do a little thing to the data.

That stream of data could be numbers that represent the voltage of the signal at your antenna and the final output could be sound coming from your speaker.

If you were to take that example, you could use one tool that knows how to measure voltage, pipe that to a tool that knows how to convert that into FM and pipe that to a tool that knows how to play audio on your speaker.

Converting something to FM is, in and of itself, a series of steps. It involves taking the raw numbers, extracting the part of the samples that are the station you want to hear, decoding those and converting that into something that is ready to be played on your speakers.

This process is fundamentally different from using a so-called monolithic tool that does everything behind the scenes. The person writing the software has decided what to do, how to do it, in what order and in what way. If you want to do something that the author hadn't thought of, like say listening to a new type of broadcast, you'll be waiting until they update the software.

In another way, this is the difference between making a cake from raw ingredients and buying it up the road at the shops

One final part of the puzzle.

There's nothing preventing you from piping the output of your program to another copy of the same program.

So, if you had a tool that knows how to do the maths behind filters, AM and FM decoding, translating Lower Side Band into Upper Side Band and vice-versa, band filtering, etc., you'd be able to set up individual steps that translate a signal, one step at a time, from raw antenna data into a sound you can hear. You would have all the building blocks for the fancy tools that you are used to.

csdr is such a tool.

For example, it knows how to set the gain of a signal, how to up and down sample, how to shift frequencies, how to decode them, it knows about RTTY, PSK, AM, FM and do about a hundred other things.

So far I've mentioned decoding, but there's nothing stopping you from starting with plain text, piping that into csdr and converting that to a PSK31 audio signal and transmitting that audio on your radio.

To make it even better, because it's so modular, you can look at the math behind what's going on and begin to understand what's happening behind the scenes.

Of all the tools I've found in the past decade, I have to confess, this is the one that has stopped me in my tracks.

Thank you to Randall VK6WR for introducing me to this tool and to Andras HA7ILM for writing it.

I'm Onno VK6FLAB

New day, new mode ... SSTV Sep 27, 2020

Show notes

Foundations of Amateur Radio

In 1958 The Kentucky Engineer published an award winning student article by Copthorne "Coppie" MacDonald. He described a Slow-Scan T.V. System for Image Transmission. If you get the opportunity, have a look for the link on his archived home-page which you can find from the Wikipedia SSTV page.

The purpose of this narrow band television idea was to be able to send images using cheaper equipment and less bandwidth than normal television. The idea caught on and it's still in use today.

In 1959 the idea of slow scan tv was used by the Luna 3 mission to transmit images from the far side of the moon. The NASA Apollo program also used SSTV to transmit images from Apollo 7, 8, 9 and from the Apollo 11 Lunar Module.

In 1968 SSTV became a legal mode for radio amateurs in the United States.

The International Space Station regularly uses SSTV to send images to radio amateurs across the globe.

The version of SSTV in use by radio amateurs today is different from the earlier grainy black and white images coming from the moon and if you're expecting a moving image, something that TV implies, you're going to be disappointed, since the popular SSTV modes send images one at a time, taking up to a minute or so to send. With a frame-rate of one frame per minute, watching anything other than grass grow is going to be a challenge.

That said, SSTV is a lovely and relatively simple way of sending images across the air.

In my quest for new adventures I like to play with things I know nothing about. I suspect that it's ingrained but it does keep me off the street. The other day I received an email from a local amateur, Adrian VK6XAM, who sent a message describing a new SSTV repeater he'd set-up for testing purposes. It's a local 2m repeater that waits for an activation tone, then it expects you to transmit an SSTV image and it will replay the image back to you. If you've familiar with a parrot repeater, this is a similar thing, just for SSTV rather than audio. The repeater is running on solar power and with the 100% duty cycle of SSTV, it's only available during daylight hours.

Technicalities aside, I couldn't resist.

So, I fired up QSSTV, a piece of Linux software that among other things knows how to receive and send SSTV images. After turning on my radio, tuning to the correct frequency, I received my first ever SSTV picture.

On a bright red background a yellow symbol appeared. At first I thought it was a hammer and sickle, but on closer inspection it was a micrometer and caliper, which absolutely tickled my fancy, having just taken delivery of some precision measuring tools - a Mitutoyo Test Indicator and a few other bits and pieces for another project I'm working on.

Had to learn how to drive QSSTV, make a template so you can overlay text on an image, learn what a signal report should look like, then when I figured all that out I triumphantly hit send and it made all the right noises, but nothing was happening.

More time looking at the inter-web taught me that if I want to use the rear connection on my FT-857d to send audio using FM, as opposed to SSB which is what most digital modes need, you need to set the radio to PSK mode and magically it starts to work.

My first ever SSTV image was sent an hour and a half after receiving my first image and the repeater dutifully sent it back. Then I got a picture from Keith VK6WK.

Of course the paint isn't even dry on any of this, so there's plenty more to learn, but the process is not too complex.

I will note a few things.

I had already set-up digital modes, that is, my radio was talking to my computer via CAT, that's Computer Assisted Tuning, essentially a serial connection that controls the radio and the audio was already being sent and received from the rear connector of my radio.

Getting SSTV running was really an extension on those activities, so if you're going to do this, take some time to make things work. I continue to recommend that you start with WSJT-X since it helps you get your levels and connections right.

Now I suppose I should start playing with SSTV over HF, but first I would like to figure out how to make the templates work better for me and how to actually seriously log an actual contact.

More adventures ahead!

Remember, have fun, play, get on air and make noise!

I'm Onno VK6FLAB

Simplicity among the complexity ... Sep 20, 2020

Show notes

Foundations of Amateur Radio

My radio shack consists of two radios, identical, well, in as much as that they're the same model, a Yaesu FT-857d. Their memories are different, their microphones are different, but both of them are connected via a coaxial switch to the same VHF and UHF antenna. One of them is also connected to a HF antenna.

Let's call these two radios alpha and bravo.

Alpha is used to host F-troop and play on the local repeater. Bravo is used to do HF stuff. It's also connected to a computer via a serial cable, called a CAT cable, Computer Assisted Tuning, but really, a way to control the radio remotely.

The audio output on the rear of the radio is also connected to the computer.

These two connections are combined to provide me with access to digital modes like PSK31, WSPR and SSTV, though I haven't actually yet made that work. The computer itself is running Linux and depending on what I'm doing on the radio some or other software, often it's fldigi, a cross-platform tool that knows about many different digital modes.

The computer is also connected to the Internet via Wi-Fi, and is used to see what various reporting websites have to say about my station, things like propagation, the DX cluster, an electronic way of seeing what other stations can hear, then there's solar radiation information and other neat tools.

This shack is pretty typical in my circle of friends. I'm lucky enough to have a dedicated table with my shack on it, for others they're lucky to have a shelf in a cupboard, or at the other end of the spectrum, a whole room or building dedicated to the task.

The level of complexity associated with this set-up is not extreme, let's call it in the middle of the range of things you can add to the system to add complexity.

In case you're wondering, you might consider automatic antenna switching, band switches, band filters, amplifiers, more radios, audio switching, automatic voice keyers. If you look at the world of Software Defined Radio, the hardware might include many of those things and then add a computer that's actually doing all the signal processing, making life even more complex.

At the other end of the complexity scale there's a crystal radio.

As I've been growing into this field of amateur radio it's becoming increasingly clear that we as a community, by enlarge, are heading towards maximum complexity.

There's nothing wrong with that as such, but as a QRP, or low-power operator, I often set-up my radio in a temporary setting like a car or a camp site. Complexity in the field is not to be sneezed at and I've lost count of the number of times where complexity has caused me to go off-air.

It occurred to me that it would be helpful to investigate a little bit more just what's possible at the other end of the scale, at the simple end of complexity if you like.

So, I'm intending, before the year is out, supplies permitting, to build a crystal radio from scratch. I realise that I have absolutely no idea what I'm getting myself into, no doubt there will be more complexity that I'm anticipating, but I'm getting myself ready to build something to be able to look at it and say to myself, look, this is how simple you can get with radio.

I'm currently too chicken to commit to making the simplest - legal - transmitter, but if you have suggestions, I'll look into it.

Just so you know, simplicity is an option.

I'm Onno VK6FLAB

Yak Shaving ... Sep 13, 2020

Show notes

Foundations of Amateur Radio

Yak Shaving ...

Not every adventure gives you an outcome. Today started with reading a thank-you email from a listener who shared their activities and wanted to express their gratitude for encouraging them to get on air and make noise.

That in turn prompted the question on the country of origin of that listener and did I know where all my listeners were? For the past few hours I've been attempting to answer that seemingly simple question.

Aside from using the opportunity to make an attempt at mapping the distribution of amateurs in Australia, which on the face of it is a trivial exercise, consisting of extracting the postcode from each registered amateur and then putting those on a map.

Only the postcodes are not actually single points. They're boundaries defined by Australia Post and they're copyrighted. Not only that, they change. To access them, you have to pay the Post Office. If you want to combine a postcode with a population density, so you can see where amateurs are represented and at what level, you go to the Australian Bureau of Statistics for a population density data-set. At that point you realise that the Bureau uses standardised regions. Mesh-blocks at the smallest end of the scale are essentially the size of 30 to 60 households. The Bureau uses these as the fundamental size for all its statistics.

When you attempt to map this onto postcodes you learn that there isn't a one-to-one mapping and even if there was, it would change every time Australia Post changed a postcode boundary.

I will note that this is all by way of a side-street in my investigation. I wondered how amateur radio is distributed across the country and I didn't want to end up with essentially a population density map, more people means more amateurs, I wanted to see where amateur radio had the potential to affect more people because there are more of them in a group.

Anyway, then I attempted to look at the podcast downloads and map those to countries. I use AWS CloudFront to make the podcast available, so it gets to the user, you, quicker. The logs show which data-centre a request is handled by. Then I needed to map a data-centre to an airport code, look that up in a database so I could extract the country, then count how many requests were made per country.

Then I started doing that across time, so you can see how that changes over time.

At this point I still don't actually have a map to show.

While all this was happening, my computer started running low on disk-space, not because I'd just downloaded some data from the Australian Bureau of Statistics, but because some rogue process was writing a log somewhere, so I spent an hour looking for what process that was, killing it and removing the superfluous log file.

If this sounds familiar, there's a name for it. Yak shaving. It's originally named after a Ren and Stimpy episode called "Yak Shaving Day". Essentially you do a whole lot of unrelated activities in the pursuit of the actual activity, essentially a string of dependencies that distract you from the end-goal. In my case, trying to answer which countries are represented within my audience.

Why am I not using an amateur radio example?

Two reasons.

This is amateur radio. For me. Doing charts, wrangling data, massaging stats, finding answers and presenting those are an integral part of the hobby, to me. Just like making this podcast, contributing to discussion, reading and learning. All part of the mix.

Second reason is that I wanted to illustrate this with something that wasn't immediately obviously linked to the hobby for most people. A more amateur example might be wanting to go and operate portable, attempting to locate you battery, when you find that it's not charged, so you go looking for the charger which you find has a broken connector, so you drive to the electronics store to get the connector when you run out of petrol, so you pull over, get out of the car and trip over the curb and end up in hospital emergency waiting for a doctor to see you. If you think that's far-fetched, I know an amateur who ended up in hospital from yak-shaving.

We've all had days like that.

The idea is that any day that you are on the right side of the earth, doing something you love is a good day.

Regardless of the end result, this is a hobby after all.

I'm Onno VK6FLAB

What is so different about using software for signal processing? Sep 06, 2020

Show notes

Foundations of Amateur Radio

In my ongoing software explorations I've discussed that Software Defined Radio or SDR is a fundamentally different way of dealing with radio. It's been in use across non-amateur circles for decades. Your mobile phone has an SDR on board for example.

The original term of "digital receiver" was coined in 1970, "software radio" was coined in 1984 and in 1991 Joe Mitola reinvented the term "software radio" for a planned mobile phone base station.

So, this idea has been around for half a century and in amateur radio this idea is also catching on. You can buy a few pure SDR devices today, some hybrid ones, or you can begin to experiment in a more indirect manner using your traditional radio and a computer.

One of the things that sets this idea of a software defined radio apart from anything we've done so far is that the bulk of the signal processing is done in software. That sounds obvious, but it's really not.

One of the impacts of this idea is that you can improve your radio communications by either writing better software, or by using a faster computer. Unless you write software for a living, these things aren't immediately obvious, so let me explain.

Imagine that you've written software that detects beeps in a particular slice of audio spectrum that's being fed to your application. As you write better software to detect those beeps, you get a better digital mode, one with a better chance of being decoded, or using radio terms, it has a better signal to noise ratio.

If that's not a familiar term, signal to noise ratio is the a measure that describes the difference between a wanted signal and the background noise. Higher signal to noise means that you can better distinguish between the two.

If you stand in a room full of people talking and you use your hands to cup your ears towards the person you want to hear, you've increased the signal to noise ratio and your chance of understanding them has improved.

As you write this software, it gains complexity. As you deal with more maths, more samples, more tests, you end up running out of time to make your decoder return a relevant answer. There's no point in having a real-time signal being decoded late. If it were to take say 10 seconds to decode 1 second of audio, then the next second would be 20 seconds late and the one after that would be 30 seconds late.

That's where a faster computer comes in.

If you have the ability to do more maths, or do the same maths at a higher resolution, you will essentially improve the reception of your radio without ever needing to change your antenna or anything on the circuit board.

Think of it in another way.

Imagine that your tool has access to 2.3 kHz of audio. It's the equivalent of a Single Side Band audio stream. If you break that down into 23 chunks of 100 Hz each, you can deal with the average of 100 Hz of audio for each calculation. If you have a faster computer, you might be able to break that down into 230 chunks of 10 Hz each, or 2300 chunks of 1 Hz. So instead of doing calculations across 23 chunks of audio, you're doing it across 2300 chunks.

Why is this significant you might ask?

Well, in a traditional radio you get one bite at the cookie. You get to design and build your circuit and then package it and sell it. The end result is something like my FT-857d. It does what it does well, but it will never get any better.

However, if I plug that same radio into my computer, I can extract the audio and do stuff with it. If I get a faster computer, I can do more stuff. I don't have to change my radio, or my antenna, or even my shack. Most of the time I run a different application and I get a different result.

I will point out that I'm deliberately ignoring where and how the RF gets to the computer, or where that computer actually is, or what operating system it's running, since none of those things matter to get an understanding of how changing software can change the performance of your radio.

I've said this before and I'll say it again: "The SDR earthquake will change our hobby forever"

Before I go. I'm not for a minute suggesting that your current radio is obsolete. If it were legal, a spark-gap transmitter could still exchange information today, but if you want to explore what might be just over the horizon, going down the SDR path by connecting your radio to your computer is a really nice place to start.

I'm Onno VK6FLAB

When you run into a pounce ... Aug 30, 2020

Show notes

Foundations of Amateur Radio

Contesting is a fun way to learn about amateur radio. It tests your skill, your station, your patience and your ability to change approach at a moments notice. For those reasons alone it's an activity that I recommend you have a go at.

For me it's also about self-improvement. With each contest, can you make better use of your station, can you learn more about your radio, about bands, about conditions and ultimately become a better operator. I know that there are individuals who keep telling me that giving out signal reports of 5 and 9 isn't helpful, to them I say, try it in a contest setting and see what else you learn.

When you start out contesting you'll quickly come across two terms, technically three, that need some explanation. The terms are Run, Search and Pounce, though the last two come as a matched pair.

The essential bit of information is that when you're on a Run, or Running, you're calling CQ and responding to other stations. You essentially sit on a frequency for a bit, start calling CQ and hope that others hear you and start to gather around to make contact with you.

The other side of that is Search and Pounce, or searching on a band for a station you want to talk to and pouncing into a gap when you can.

The two methods are mirror images of each other, so one station is generally running whilst the stations calling in are searching and pouncing.

Doing this in a contest setting requires slightly, some might say subtle, differences.

Let's investigate a contest RTTY contact. I'll simulate it between myself, VK6FLAB and Matt, VK6QS. I'll add that this is done in text in a RTTY contest, rather than voice, and, this exact exchange didn't actually happen, but for different reasons which I'll get into shortly.

It goes a little like this.

My station transmits: CQ TEST VK6FLAB VK6FLAB CQ Matt responds: VK6QS VK6QS VK6QS I reply: VK6QS 599 010 010 Matt replies: 599 032 032 And I finish off with: TU CQ VK6FLAB

Now this is the ideal contact, nothing extraneous, no duplication, nothing about having to repeat yourself. Mind you, if you're getting picky, you might notice that we're both sending our exchange twice, in my case 010, Matt is sending 032.

If you look closer you'll notice that all pertinent information is sent at least twice because it turns out that unlike a keyboard on a computer connected to a screen, what you type in RTTY might not actually get to the other end if you're using HF radio.

My three transmissions are the one where I call CQ, the one where I say Matt's callsign plus the exchange and the one where I say TU or Thank You, and move on. Those are the run calls.

Matt's calls consist of his callsign, and his exchange.

Note that Matt doesn't say my callsign, since I already know it and I'm running and he's searching and pouncing. He should already know who I am before he transmits. If he were to add my callsign, that would just slow things down. This is a way to keep things moving along.

In fldigi, I can program a function key that does each of those five calls. You click on a callsign, push the appropriate button and magically you're either running or pouncing. There's also a button for asking for a repeat, or "AGN?, AGN?" and one for making a log entry, which you can combine into the final thank you for running, but it's needed separately if you're pouncing.

I did say that this exchange didn't actually happen and you might well wonder why I shared it with you.

Simple. This is the bare-bones of what's required. Everything else is extra in case things break down. If there are multiple stations on the same frequency, or if your levels aren't quite right and the decoder is having a hissy fit, the human in the chain, you, need to do something manually. Very much like when you're dealing with a voice pile-up and there's this one station calling over the top of everyone else and drowning out whomever you actually want to talk to.

In a contest setting there's plenty of opportunity to do both running and pouncing and you should. If you're running on a dead band you won't know because you're getting old calling CQ, but if you're searching on that same band you'll figure out pretty quick that there's nothing happening.

Similarly, you might have a desirable callsign or location and find that running is more effective in making contacts than searching and pouncing.

Whatever mode of contesting you choose, make sure that you're flexible, since band conditions change from second to second and you will need to adapt to the winds of change. A lot like when you learn to sail and find out that you cannot just hold the helm in one spot for the entire time.

I will note that the ideal RTTY contact that I've outlined isn't universal. There's plenty of debate about the most effective way to go about things. I started with what I knew about making voice contacts, shamelessly copied the RTTY macros from another amateur and used them as a basis to learn what I needed and what I didn't, and because this was my first actual RTTY contest I watched several YouTube videos, rather than hear actual contesting stations on the air, which is something I recommend you do to get a feel for what's going on.

Contesting can be a way of life, or it can be just plain fun with learning thrown in.

I'm Onno VK6FLAB

After channelling your RTTY ... Aug 23, 2020

Show notes

Foundations of Amateur Radio

It's the morning after the day before. I've been calling CQ for 24 hours and for the first time in my life after a contest I still have my voice. That in and of itself is novel. I also don't have ringing ears, that's a blessing. I have learnt heaps and had fun doing it. I made contacts and I heard stations across the globe and I did it all from the comfort of my shack chair.

Before I dig in and expand, the contest I just completed ran for 24 hours. I didn't sit at my radio for all of it, nor was my radio on for all of it. I managed to have lunch, dinner, desert, breakfast and morning tea. I snuck in a few naps and I managed to help with bringing in the shopping. My station did not transmit unattended at any time in case you're wondering.

My setup consisted of a little 11 year old netbook computer running the current version of Debian Linux and the heart of this adventure, the software called fldigi. The computer is connected to my Yaesu FT-857d via three cables, well, two and a half. A microphone and a headphone lead that combine into the data port in the back of the radio. The other cable is a USB CAT cable, a Computer Assisted Tuning cable, that plugs into the CAT port on the back of the radio. I also used an external monitor to have my main contest screen on and used it to display the main fldigi window.

My license class allows me access to a selected number of amateur bands, 80m, 40m, 15m, 10m, 2m and 70cm. I managed at least one RTTY contact on each band.

As I described previously, my radio is set to use Single Side Band and the audio from the radio is fed via the microphone socket on the computer into fldigi that processes the information. Similarly, when I transmit, the audio is generated via fldigi and leaves the computer via the headphone socket and goes into the radio as a Single Side Band audio signal.

The information in the audio is all RTTY, a digital mode that I've described previously. The software is using Audio Frequency Shift Keying, AFSK, simulating the switching between the two RTTY frequencies.

On my screen I have a waterfall display that shows all the signals that are happening within the 2.3 kHz audio stream that's coming from the radio. Fldigi is also decoding this in real-time and showing each decode as a virtual channel in a list. Click on a channel entry and your next transmission will happen at that frequency.

If you've ever used WSJT-X this will sound very familiar.

That's the mechanics of what I've been doing.

So, what did I learn in this adventure?

Well, most of Australia goes to sleep at night, at least the ones that do RTTY. I have evidence of exactly one station on-air, and that was only because they were named in the DX Cluster, which by the way this contest allows as assistance. Since then I've found logs from at least two more stations.

Local contacts did happen during the more civil hours and in total I managed ten of them. You may think that's not much for say 12 hours of work, but that's 5 Watts QRP, or low power, RTTY contacts, in an actual contest, on a new antenna, from my shack, dodging thunderstorms and learning to use filters and levels.

You might not be impressed, but I'm absolutely stoked!

During the midnight-to-dawn run, on 40m, when there were double points to be had, which I missed out on, I did manage to hear several stations across Europe, 14,000 km away, which means that I can pretty much count on global coverage with my current setup. Sadly they didn't hear me, too many competing stations, but I'm sure that with practice I'll manage to contact them too.

The software crashed once. That's not nice. It seems to have a habit of corrupting one of the preference files, which prevents it from starting up. That's also not nice. I hasten to add that I don't yet know the source of this. It may well be a dud-hard-disk sector on my ancient laptop, rather than the software, so I'm not assigning blame here.

Getting started with fldigi is an adventure. It's not point-and-click, nor plug-and-play, more like running a mainframe whilst cranking the handle, but when you get it to fly there's lots to love about this tool.

Other things that worked well were that I'd spent some preparation time getting the keyboard macros right. These are pre-defined bits of text that you send as you're calling CQ and making a contact. They're a whole topic in and of themselves, so I'll skip past the detail and just mention that I was very happy with the choices I made, gathered from years of voice-only contacts, reading RTTY contest information and looking for exchange details.

From a technical perspective, I used both contest modes, "Running" and "Search and Pounce". Running is when you call CQ, Pouncing is when they call CQ. The running was by far the most successful for me. I'm not yet sure if that was a reflection on how much I still have to learn about levels.

One thing that I can say with confidence is that there's absolutely nothing like having a wall of RTTY signals to learn how to make sure you're actually decoding something useful. I spent a good couple of the wee hours tuning my levels.

I would like to thank the stations who came back to my call and for those who tried without me noticing them.

I had a blast.

I'm Onno VK6FLAB

Channelling RTTY Aug 16, 2020

Show notes

Foundations of Amateur Radio

When you start playing with radio your first interaction is likely to be voice. It could be SSB, AM, FM or something more recent like FreeDV or DMR. Your next challenge is likely going to be a digital mode like Morse Code, Radio Teletype or my recommendation for your first adventure, WSPR or Weak Signal Propagation Reporter.

I've previously discussed WSPR, today I would like to look at Radio Teletype or RTTY. It's a digital mode that allows you to send and receive free-form text. It's a mode with a long and illustrious history and it's a good next step after WSPR.

The way it works is that using an alphabet made up from two tones, information is transmitted, one character at a time at a specific speed. The code that describes the alphabet is called the Baudot code, invented by Jean-Maurice-Emile Baudot in 1849. In computing terms it's a 5-bit alphabet and in amateur radio it's traditionally sent at 45.45 baud or bits per second, in case you're wondering, named after the very same man.

The two tones have names, a Mark and a Space and they're a set distance apart. In amateur radio, they're separated by 170 Hz but there are plenty of other frequencies and speeds in use. In amateur radio the standard Mark and Space frequencies are 2125 Hz and 2295 Hz.

In a traditional RTTY capable radio the two tones are generated by transmitting a carrier whilst switching the transmitter frequency back and forth, called Frequency Shift Keying or FSK. Think of it as having a Morse key that sends dits on one frequency and dahs on another, having the radio change frequency whilst you're keying.

If you use this method to create and decode RTTY by switching between two frequencies, your radio can generally only deal with one RTTY signal at a time, just the one you're sending and just the one that's being received. Receiving is generally achieved by showing some indication on your radio how close you are to the Mark and Space frequencies that you're trying to receive and decode.

Another way to make a RTTY signal is to use sound. If you alternately whistle at 2125 Hz and 2295 Hz and you do it at 45.45 bits per second, you're also generating RTTY. This technique is called Audio Frequency Shift Keying or AFSK. Think of it as using audio to simulate the shifting of frequency by transmitting two alternating tones.

There is a fundamental difference between the two. Before I explain, permit a diversion. It's relevant, I promise.

If you've ever spoken on the radio using SSB you might have noticed that if two stations are transmitting at the same time you get both signals. With a little practice you can even understand both. This isn't true for every radio mode. If you use FM, the strongest signal wins and if you use AM, you get a garbled beep from two stations being on slightly different frequencies. As an aside, this is why aviation uses AM, so any station not transmitting can hear that two stations doubled up.

Back to RTTY.

If you use audio to generate the two RTTY carriers, rather than shift frequency, you can deal with as many as you can fit into an SSB audio signal, as long as the Mark and Space for each station are 170 Hz apart you can have as many stations as you want, overlapping even. As long as your software knows what to do with that, you'll be able to decode each one at the same time, since they're essentially multiple SSB signals being transmitted simultaneously.

An added bonus is that you don't have to invest in an SDR to play with this. You can use an analogue radio, like my FT-857d, and use software to generate an audio RTTY signal with all the benefits I've just mentioned. The magic is in the software you use to do the decoding.

As it happens, I'm about to do a contest using RTTY and I'll let you know how that goes using my radio, a computer and a piece of software called fldigi. I'll be following in the footsteps of the first ever RTTY contest, held in the last weekend of October in 1953 and organised by the RTTY Society of Southern California. In as much as I'm following in the footsteps of Morse code by spark-gap.

Wish me luck.

I'm Onno VK6FLAB

Our TOPPODCAST Picks

Follow Us

Stay Connected

Foundations of Amateur Radio

Related Podcasts

Links

Stay Connected