• [FOAR] The power supply connector dance contest... (4/21)

    From FOAR via rec.radio.info Admin@21:1/5 to All on Mon Jul 18 13:48:30 2022
    [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

    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

    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)