[continued from previous message]

This might all be daunting, but if you read the rules of a contest and
you're not sure, every contest manager I've ever spoken to is more than
happy to help you understand what's allowed and what isn't.


One tip. Contesting is as much about the rules that are written as it is
about the rules that are not. If you find a gap in the rules, and it
doesn't go against the spirit of the contest, you're absolutely encouraged
to use that to your advantage. If you do, you'll quickly discover why the
rules change so often.


Preparation is everything!


I'm Onno VKFLAB
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20220313.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
It beeps!

Posted: 05 Mar 2022 08:00 AM PST http://podcasts.itmaze.com.au/foundations/20220306.foundations-of-amateur-radio.txt

Foundations of Amateur Radio


After weeks of attempting to get some noise, any noise out of my PlutoSDR I have finally cracked it. Not sure if cracked it refers to my sanity or the outcome, but beeping was heard from the Pluto on my radio, so I'm doing
victory laps around the house, all conquering hero type affair, complete
with whooping and hand waving.


In the end it all came down to serendipity and truth be told, I know it
beeps, I've heard it beep, it does so on a predictable frequency, but why
it exactly works is still a mystery that has yet to be discovered since the documentation I have isn't sharing and the example code I have contradicts
what I'm seeing.


For context, a PlutoSDR, or Pluto, is a very capable software defined
radio, perfect for experimentation. I've talked about it before in the
context of using it as a receiver.


My most recent efforts involved coaxing my Pluto out of a corner after it
sat there sulking for weeks. Turns out that not only was my USB power lead broken, which caused the blinken lights to stay off. When I finally figured that out, I discovered that one of the two wireless dongles I'd purchased together was Dead On Arrival. After a frustrating morning with the
manufacturer who wouldn't take my word for it that swapping out the two identical units would not require installing the driver, something about Windows Device Manager on my Linux computer, I went back to the store who happily swapped out the faulty device on the spot. Mind you, the Pluto
still isn't talking to my wireless network, but at least it's not the
dongle anymore.


I plugged the Pluto into the back of my main workstation and discovered to
my surprise that in addition to showing up as a thumb-drive, which I knew about, it also turned up as a network device, which I didn't know about.


It's been a while since I powered this up to play, so I updated the
firmware which fixed some annoying issues and started to explore.


The aim of my quest was to create a proof of concept beep from the
command-line on the Pluto.


If you're not familiar with this. The Pluto is running a flavour of Linux.
You can connect to its command-line and run commands from inside the
hardware.


This is important because for most radios, of both the analogue and
software kind, you generate the information somewhere, like Morse Code, a
WSPR signal, your voice, what-ever and then you send that to the radio. On
an analogue radio it's likely to go across an audio cable of some sort and
if you have a software defined radio, it's likely to travel from your
computer across a USB or network cable to the radio to get processed.


This is different in that there is no such signal coming across the USB
link. The link is used as a network cable to ssh into the radio where you
can generate whatever you want. In my case Morse. If you're not familiar
with ssh, think of it as a keyboard connection to a remote computer.


My script, hacked together as it is, more on that shortly, takes a string,
like say "CQ DE VK6FLAB" and processes that character by character. It
converts each into the equivalent Morse code dits and dahs and then uses
those to turn on a test tone for an appropriate amount of time.


So, to send "CQ", the script changes that into -.-. --.- and then turns on
the transmitter for three units, off for one, on for one, off for one, on
for three, off for one, etc.


This is Morse code at its very simplest, the software equivalent of holding down a Morse key for the correct amount of time and then releasing it.


I disparagingly called it hacked together, because it's using the in-built busybox command shell that comes with the Pluto. If you're familiar, the
actual shell is called ash, or Almquist shell. It's strictly limited in functionality, no arrays, minimal redirection, all very basic. Perfect for
what I want to do, but not so much if you want to write software.


After working around the lack of arrays, one of the things that caused me
the most problems was to discover just how to setup the Pluto to actually
do this. I found a couple of examples online that pretended to work,
claimed to be doing what they said they were, but nothing was heard on my
local analogue radio. At one point I heard clicks, but no beeping.


After spending literally hours testing, scanning up and down the radio dial with my Yaesu FT-857d, I stumbled on a tone that stopped when my test
script stopped. I started the script again and the tone came back. When it ended, the tone stopped again. I finally had a relationship between a tone
on the PlutoSDR and the frequency on my radio.


So, with all manner of funky offsets in my code, subject to me
understanding the how and what of them, I can now beep to my hearts
content. Of course I've shared my efforts on github, cunningly called Pluto Beacon.


Have a look and tell me what I did wrong.


I'm Onno VK6FLAB
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20220306.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
What happens when you plug it in?

Posted: 26 Feb 2022 08:00 AM PST http://podcasts.itmaze.com.au/foundations/20220227.foundations-of-amateur-radio.txt

Foundations of Amateur Radio


The other day I took delivery of a shiny new circuit board populated with components and connectors. Knowing me, you'd assume that I'd been the
recipient of some kind of software defined radio gadget and you'd be right.


One of the connectors was a micro USB socket, intended to be used to plug
the hardware into a computer and to drive the circuit board.


The board came to me by way of a friend who saw it online, waxed lyrical
about it and for less than $35, who could begrudge this exploration into a
new toy?


Once it arrived, it sat on my shelf for a few weeks, enticingly packed in
an anti-static bag, transparent enough to see the device inside, taunting
me to open it up, plug it in and have some fun.


Today I opened it up and started researching my new gadget. It didn't come
with any user manual, no URL, no model number, but it did have a callsign
on it, so I started there. I'll note that I'm not going to repeat that
callsign here for a number of reasons, which I'll get to.


My exploration discovered a site where this device was being sold. It also unearthed several international amateur radio forums describing what
appeared to be this device, including circuit diagrams and specifications.


What I found harder to discover was software.


It appears that I have a clone of a device that may still be manufactured,
or not, I cannot tell. I found some example code on github for the original hardware, but it seemed to require other libraries, but didn't actually
specify those anywhere.


I opened up an online translation tool and started translating some of the wording on the circuit board in an attempt to discover just what
information was written on the board.


The wording was clearly from a different culture, a different perspective
and while it claims to come from a maker space that appears to promote
women, it also contained a militaristic phrase which caused me to pause.


In that moment I came to a sudden and abrupt realisation.


How do I know what this piece of hardware actually does?


How do I know if when I plug it into the first available USB socket on my computer, it won't install anything nefarious, start connecting to the
internet and start doing something unexpected? There's enough hardware on
the circuit board to do that and even if the labels on the components tell
me that they are a specific integrated circuit, how do I know that it
actually is that chip?


The chips on this circuit appear to have a lot more connectivity than a
simple receiver might warrant. One has 40 pins, the other 32. If the label
is accurate, the data sheet for one of the chips indicates that it includes
an 8-bit micro controller among its various functions.


I'll admit that I'm coming from an IT security background at this and you
are free to argue that I'm being paranoid, but does that make me wrong?


I know that I don't know enough about this particular board or its origins
that for now it's going to remain inside its anti-static bag, taunting me
with the possibilities of the connectors it offers, but until I know more
about the provenance of this gadget, it's going nowhere near any of my computers.


If you have suggestions on how to proceed, don't be shy. I did briefly
consider plugging it into a Pi, but how would I know if it updated the firmware, forever compromising that Pi?


Don't get me wrong, I'm not saying that this board does any of this. My
point is around discovering if it does, or not, one way or another.


No doubt some might think I'm overly suspicious and there is truth in that,
but in my profession it pays to be vigilant. The underlying issue is that
of validation. There's anti-virus software available to deal with malicious code, but how do you do such a thing for malicious hardware?


Again, I'm not saying that this circuit board is doing anything other than being a USB connected receiver, but how would you know? How would you
verify that? And how do we in the amateur community weed out the nefarious tools from the legitimate ones?


I'll leave you with one thought. When was the last time you plugged your
phone into a free charger on the bus or at the airport? How do you know
that your phone wasn't hacked?


I'm Onno VK6FLAB
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20220227.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
How to compare radios

Posted: 19 Feb 2022 08:00 AM PST http://podcasts.itmaze.com.au/foundations/20220220.foundations-of-amateur-radio.txt

Foundations of Amateur Radio


One of the topics I've been talking about lately is the idea that we might
be able to measure the performance of your radio in some meaningful way
using equipment that can be either obtained by any amateur, or by
introducing a process that allows results to be compared, even if they have been generated differently.


Recently I came up with a tool that automatically generates a spectrogram
of an audio recording. That on its own isn't particularly interesting, but
it's step one in the processing of an audio signal. In addition to the spectrogram, I also created a tool that generates a tone frequency sweep,
think of it as a tone that changes frequency over time, let's call it a
sweep.


If you combine the two, you can generate a spectrogram of the sweep to give
you a starting point or baseline for comparison. You can build on that by
using your radio to transmit that sweep and record the result using a
receiver. In my initial experiments, I used an RTLSDR dongle to receive the audio with some success and a boatload of spectacular harmonics, but I
wanted to find a better, more accessible way to do this and during the week
I realised that my Yaesu FT-857d that's sitting in my shack, is connected
to a perfectly functional antenna and with a few settings it could do the
job perfectly.


One of the biggest issues with my RTLSDR setup was squelch. That is the difference between what is a legitimate transmission and what is noise. Set
it too high and you hear nothing, set it too low and you hear everything, including background noise.


Since the VHF or 2m noise levels are quite high at my location, or QTH, I normally have the squelch completely closed. This is fine if you're
normally using a strong repeater, but if you're attempting to receive a
weak hand-held, that's never going to work.


As any self-respecting amateur I was dragged down the path of last resort
to read my user manual where I discovered that in addition to CTCSS, a way
to transmit a tone to open a repeater, there's also a setting called Tone Squelch or on my radio TSQ, which will keep my radio squelch closed, unless
it hears the CTCSS tone from another radio.


Truth be told, I had to read a different user manual to discover how to actually set the CTCSS tone on my handheld to test, but that's just adding insult to injury. It has been a while since I read any manual, even though
I try to get to it once a year or so. I blame it on the lack of field-day camping. That's my story and I'm sticking to it.


So, combining all this, the spectrogram generator, the sweep, CTCSS, and
adding a Raspberry Pi with some website magic, if you're interested, an AWS
S3 bucket, I now have a service that listens on a local frequency, opens
the squelch if it hears the correct CTCSS tone, records the incoming signal until it stops, then generates a spectrogram from that audio and uploads it
to a web site.


None of this is particularly complicated, though I did have some bugs to
work through. I've published the code as a branch to my existing frequency-response project on github and I've asked my local community to experiment with what I have on-air before I start doing more far reaching experiments.


For example.


If I were to tune my radio to a local repeater output frequency, rather
than the simplex one I'm currently on, I'd be able to record and generate spectrograms for each transmission coming from that repeater. If that
repeater was connected to the internet, using AllStar, IRLP, Echolink, DMR
or Brandmeister, or even all of them, the global community could send their audio to my recorder and it could generate a spectrogram on the spot.


If using that repeater, you played a sweep into your microphone, or used
your digital audio interface to play the sound, you could then compare your signal path against others and against the baseline response.


One of the issues with doing this is that much of the audio that travels
across the internet is pretty munched, that is, it's compressed,
frequencies are cut-off, there's all manner of interesting harmonics and
the value of the comparison appears limited at best.


Once I have my multi-band HF antenna, which I'm told is still being built,
I intend to set this contraption up on HF where we can do point-to-point recordings and we end up having a direct comparison between two stations
who transmit into my frequency-response software.


I should add some disclaimers here too. At the moment I'm only using FM.
The intent is to get this to a point where I can compare any mode, but when
I move to HF, I'll likely start with Single Side Band and go on from there.


One other annoyance is that any user needs to configure CTCSS to make this work, which is yet another hurdle to overcome, not insurmountable, but I
like to keep things simple when you're starting to learn.


Also, the harmonics still show, even on an analogue radio, so there's
plenty more to discover.


In the meantime, what kinds of things can you think of to use this for?


I'm Onno VK6FLAB
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20220220.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
Pictures can say more than words

Posted: 12 Feb 2022 08:00 AM PST http://podcasts.itmaze.com.au/foundations/20220213.foundations-of-amateur-radio.txt

Foundations of Amateur Radio


Recently I've spoken about measuring the frequency response of your radio
and what the benefits of doing so might be. Today I've got some progress to report and some initial discoveries. Again, this is preliminary, but then
all of this hobby is experimentation, so that should come as no surprise.


Let's start with the mechanics of what I'm doing and a "duh" moment I need
to confess.


The aim of this process is to transmit a known audio signal, receive it,
record it and create a spectrogram from it. This allows us to compare the original spectrogram against the received one and show just how the audio
path has been affected by getting the audio into the transmitter, the processing by the transmitter, the propagation between the transmitter and receiver, the artefacts introduced in the receiver and any recording device.


To begin this process I started off with an audio file of my voice. That
wasn't very helpful, since it's a complex signal and comparing my voice
before and after is a non-trivial process. At some point I intend to come
back to voice before and after comparison, but that's on the shelf for now.


The audio that I'm using is a frequency sweep, lasting 5 seconds. That is, there's a tone that changes frequency from DC to 5 kHz. When I looked at
the spectrogram of that, it shows as a curve with time against frequency.
It occurred to me that I could make two of those sweeps at the same time to measure distortion, so I added a reverse frequency sweep from 5 kHz down to
DC. Now I've got two crossing lines showing in my spectrogram.


To transmit this audio, I'm using the same tool I use to automatically call
CQ during a contest. Every so many seconds I transmit this audio into a
dummy load and at this point I should mention that my "duh" moment was that
I was attempting to transmit into an antenna and record from a dummy load, rather than transmit into a dummy load and record from an antenna. I still cannot believe that I did that.


Moving on.


The recording is done using an RTLSDR dongle. In the current initial
version I'm using a tool called rtl_fm to tune the dongle to the same
frequency as my transmitter. I send the audio from there to the same tool I used to generate the original audio, SoX, that's Sierra, Oscar, X-Ray, and
have it detect the silence between each transmission and record each into a
new file. If I leave it running, every time I transmit something, SoX will create a new audio file.


I'm saying that quite quickly, but getting the squelch and silence
detection working in my noisy environment took most of a day and it's
specific to my station, today. I'll have to figure out how to make this smarter, but for now I have some data.


A spectrogram is generated for each audio file and then we can compare pictures. What was sent, audio wise, and what was received, audio wise. To
be clear, I'm not sending images, I'm sending audio and comparing the spectrograms of this audio.


I will also note that I'm currently using FM as the mode. I intended to do
this with SSB, but the amount of effort to get the squelch right has left
me with a future project to achieve that.


The code itself is pretty rudimentary, but I've uploaded it to my github
page. I've also added the pictures to my project website, which you can
find at vk6flab.com.


One initial observation, one that I don't yet understand, is that what I
sent and what I received don't look the same. My pretty curves in the
original audio come back with spectacular harmonics all over the place,
very pretty to be sure, but not quite what I was expecting, let's call it
an educational challenge.


Before I forget, just because I'm using a Yaesu FT-857d, a Raspberry Pi, an RTLSDR dongle, an antenna and a dummy load, doesn't mean that you need to. Essentially, what this does is generate a special audio file, transmit it, receive it, record it and generate a spectrogram. You can play the audio
from your own computer if you have digital modes set-up, or from your
mobile phone if not.


Recording can be something sophisticated with off-air monitoring, or it can
be a recorder held in front of your receiver.


One final note. You can change settings on both the transmitter and the receiver to see what they do in relation to the audio, so experiment.


I'm Onno VK6FLAB
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20220213.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
Testing your radio's audio frequency response

Posted: 05 Feb 2022 08:00 AM PST http://podcasts.itmaze.com.au/foundations/20220206.foundations-of-amateur-radio.txt

Foundations of Amateur Radio


During the week I was reading a comment from another amateur about digital modes. Tucked inside that comment was a phrase that could easily have been overlooked, but it reminded me that there is plenty to learn and test in
the field of amateur radio.


The phrase, "requires actual understanding of audio level paths" was
uttered by Chris, VK2CJB and it prompted a brief conversation at the time,
but I've been working on it ever since.


Where I arrived at is an attempt, incomplete as yet, to design a mechanism
to show the impact of various transmitter settings on the received audio in such a way that you can test your own gear and see the result.


Before I explain how I'm doing this, let me describe why it's important.


Using a radio in concept is pretty simple, if you yell into the microphone,
the audio comes out distorted and if you whisper, it might also be
distorted, but in a different way, neither is conducive to communication.


One way to improve this is a tool called the ALC. Using Automatic Level
Control as a guide to what level your audio should be is outlined in every amateur radio manual I've seen, but how much it matters and to what extent
is left unsaid. If you apply a filter or any number of other fancy options, what happens to your audio?


To get some sense of what I'm describing, listening back to your own voice after it comes across HF SSB is surprisingly distorted in comparison to a
local recording.


You might argue, what's the harm, as long as the other station can hear my voice, we're good to go.


Sure, if voice is all you're using, but what if it's data? In that case,
the audio you're transmitting is actually encoded digital information. To decode it, the software needs to deal with frequencies, distortion and
levels to name a few.


In computer science, "garbage in, garbage out" is the concept that flawed,
or nonsense input data produces nonsense output. In our case, if you
transmit garbage, the receiver is going to start with garbage and what gets decoded is likely not what you expect.


Without going into error correction, essentially, the cleaner the path
between the transmitter and the receiver, the higher the chances of success
and to be fair, you already know this when you attempt to work a pile-up on
a noisy band. "Again, again, just the prefix, again!", sound familiar?


To achieve this I started with the idea that you could transmit a tone and
if you knew what it was, you could determine the difference between what
was sent and what was received.


My first step was to generate a single 1 kHz tone, but then I wondered what would happen if you did multiple tones, one after the other. My current
version is an audio frequency sweep, running from 0 to 5 kHz in five
seconds. It's essentially a computer generated sequence of tones with known characteristics. You transmit this audio file using your radio and then
record it off air, either from a local receiver, WebSDR, or the radio
belonging to a friend.


Using the recording, you can create a spectrogram, a picture, showing the frequencies over time present in the audio. Compare the two and you just
learnt what each setting on your radio does precisely to the audio.


Of course it's simple for me to say this, but I'm working on using a tool
I've spoken about before, csdr, to do the heavy lifting, so you can
actually do a meaningful comparison between the various audio files.


In the mean time, I've managed to use SoX, the so-called Swiss Army knife
of sound processing programs to both generate the audio sweep and draw a preliminary spectrogram.


Next up is showing some side-by-side images of various radio settings and
their effect on the spectrogram. I'll publish this on my website when I
have something to show-and-tell.


I also don't yet know if my source audio file is going to be sufficient,
but I'll subject that to some testing as well. For example, I'm
investigating multiple simultaneous audio sweeps with different frequency ranges. The more complex the spectrogram, the more we might be able to
learn from the distortion on receive, but time will tell.


If you have some ideas on how to improve this, let me know.


I'm Onno VK6FLAB
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20220206.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
What's in a Dream?

Posted: 29 Jan 2022 08:00 AM PST http://podcasts.itmaze.com.au/foundations/20220130.foundations-of-amateur-radio.txt

Foundations of Amateur Radio


On the 6th of June, 2004, two Brazilian amateurs Roland, PY4ZBZ and
Arnaldo, PY4BL made a historic contact on 40m. The distance was not particularly significant, only 70 km, but the mode was.


Using 2.1 kHz bandwidth, so it could fit within an amateur radio SSB transmission, they used software created by Swiss amateur Francesco, HB9TLK
to make the very first HamDream exchange.


This technological advancement represents the birth of what we now call
HamDRM and Digital SSTV and how it came about is an adventure that needs documenting, since what we have is written in a combination of Portuguese, German and English, cobbled together from broken websites, archives, source code, commit comments and lost links.


To provide some context, there is a broadcast radio mode called DRM, or
Digital Radio Mondiale. At this point I should mention that this has
absolutely nothing to do with Digital Rights Management with the catchy
acronym of, you guessed it, DRM. As you might expect, this acronym clash is unhelpful, to say the least, when you're trying to find information about
this radio mode.


Digital Radio Mondiale, or DRM, essentially defines a digital standard for radio broadcast transmissions. It can handle multiple audio streams as well
as file exchange and is used by broadcasters across the globe. Mondiale, in case you're curious means worldwide in French, seems my high school
language lessons have finally been put to good use, my French teacher in
the Netherlands will be thrilled.


DRM is more efficient than AM and FM and as an open standard, it's gaining popularity. The first broadcast using this mode took place on the 16th of
June 2003, during the World Radiocommunication Conference in Geneva.


An open source implementation of this mode is called Dream. The source code
is available online and is capable of being compiled for Windows, MacOS and Linux. Dream was originally written by Volker Fischer and Alexander
Kurpiers. The Dream project started in June of 2001 and today it has many contributors.


The DRM standard uses different bandwidths depending on which mode is used.
The narrowest DRM mode uses 4.5 kHz, but modes using 100 kHz exist. By comparison, a typical analogue amateur radio uses 2.7 kHz for SSB. Using
the source of Dream, Francesco built a modified version, called it HamDream
and let it loose on the world. It was used for that very first 70 km
contact between Roland and Arnaldo.


Several versions of HamDream existed. The first QSO used 2.1 kHz and the
last version of HamDream used 2.5 kHz bandwidth. To fit digital audio
inside that narrow bandwidth it used different audio compression
techniques, called a CODEC, namely LPC10 and SPEEX.


According to Francesco, HamDream is the basis for all current amateur radio
2.5 kHz HamDRM programs. He goes on to say that it's outdated and the
source and executables were removed from the net. Personally I think that's
a shame, since it represents part of the history of our community and I
think that putting the source online in a place like GitHub would be
beneficial to the hobby.


The 2.5 kHz HamDRM mode is implemented in several places. QSSTV, EasyPal
and WinDRM to name a few. No doubt it's elsewhere. Of those three, only
QSSTV survives. The source code for EasyPal, written by Erik VK4AES, now
SK, was lost, apparently when the computer on which it lived was sold by
his estate. Ironic really, since EasyPal was written because Erik lost a previous application due to a lightning strike nearby and was forced to
write a new application from scratch.


WinDRM appears even more elusive. There's a repository on the now archived Google Code site. There are derivatives that appear to use a version of
WinDRM, but details are hard to find. An archive I have shows a commit by Francesco, HB9TLK from 2008. I've yet to learn how this relates to the
overall picture.


In parallel, in 2005, a few enterprising students made a MATLAB
implementation of DRM. Called Diorama and written by Andreas Dittrich and Torsten Schorr it forms the basis of a Linux open source HamDRM receiver written by Ties, PA0MBO, chosen because it had a better performance in
marginal conditions than Dream did. It's called RXAMADRM. Ties also wrote
an open source transmitter, cunningly called TXAMADRM. It was based on the source code of Dream, specifically v1.12b.


If at this point your head is exploding, I wouldn't blame you.


Let's recap.


There's an open broadcast standard called DRM. An open source, cross
platform tool called Dream, in active development, implements that standard.


A special, now discontinued, version of Dream was created called HamDream.
It used less bandwidth than DRM and forms the basis of a standard that we
now call HamDRM, which underpins Digital SSTV.


HamDream forms the basis of the discontinued products, EasyPal and WinDRM,
and lives on in TRXAMADRM and QSSTV, both Linux open source.


In amateur radio terms HamDRM is one of the ways we can efficiently
exchange digital information across long distances.


At this point you might wonder why it matters?


For starters, this is part of our history of amateur radio. The HamDRM mode
is poorly documented, if at all. It forms the basis of several modes in use today and writing your own software is made all the more challenging
because much of the design and development of this mode has been lost.


What's more, HamDRM is an example of "modern radio". It uses the same fundamental techniques used by the 4G and 5G mobile phone network, as well
as modern Wi-Fi. Losing this is a massive step backwards for amateur radio.


This article alone represents a week of research by two people, thank you Randall VK6WR, and I won't be surprised to learn that it contains errors
and omissions. It shouldn't have to be this hard to discover how a mode
works, what is used to make it tick and how to write new software to
implement a new application.


Gotta love open source. Speaking of which. If you have source code copies
of HamDream or WinDRM, I'd love to hear from you. cq@vk6flab.com is my
address. If you have documentation on the design of the HamDRM mode, I'll
owe you a beer, or a glass of milk, your choice.


I'm Onno VK6FLAB
This posting includes a media file: http://podcasts.itmaze.com.au/foundations/20220130.foundations-of-amateur-radio.mp3

///////////////////////////////////////////
Bringing an upconverter into your life

Posted: 22 Jan 2022 08:00 AM PST http://podcasts.itmaze.com.au/foundations/20220123.foundations-of-amateur-radio.txt

Foundations of Amateur Radio


A couple of days ago, after months of anticipation, an unassuming little
box arrived on my doorstep. Inside the box was a nondescript electronic

[continued in next message]

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