[continued from previous message]

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
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20201018.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
An ionospheric monitoring service at home

Posted: 10 Oct 2020 09:00 AM PDT


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
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20201011.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
csdr will rock your world ...

Posted: 03 Oct 2020 09:00 AM PDT


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
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20201004.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
New day, new mode ... SSTV

Posted: 26 Sep 2020 09:00 AM PDT


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
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20200927.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
Simplicity among the complexity ...

Posted: 19 Sep 2020 09:00 AM PDT


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
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20200920.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
Yak Shaving ...

Posted: 12 Sep 2020 09:00 AM PDT


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
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20200913.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
What is so different about using software for signal processing?

Posted: 05 Sep 2020 09:00 AM PDT


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
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20200906.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
When you run into a pounce ...

Posted: 29 Aug 2020 09:00 AM PDT


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

[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)