2025-01-10 — What’s New at DLARC 2025-01, 2400+ Email Subscribers, HF Signals zBitx, SignalSDR Pro, DRATS2 Project, GLnet, New APRSdroid, ka9q-radio Video Series, Bald Yak Series (on GNU Radio)
The SuperPeater concept looks interesting, and certainly doable today, including analog SSB. Almost 20 years ago, I ran a SSB Echolink node that worked very well, as far as voice goes (DTMF was a different story). In fact so well, FM and PC Echolink users couldn't even tell that the SSB users were actually on SSB!
As for the hardware and software involved, there were a few key components. The system ran SSB simplex in the general "ragchewing" part of the 2m band, around 144.300 MHz on a Yaesu FT-480R (10W PEP).
In the receive audio path, I used a DSP noise reduction unit made by Michels Engineering from Germany. This unit had a couple of desirable characteristics. Firstly, it was capable of excellent voice clarity down to the point where the unprocessed signal was barely audible. Secondly, for the cost of slightly reduced sensitivity, a high degree of noise reduction could be achieved, even for very weak signals. This DSP was the reason that the received audio was hard to distinguish from FM, provided the SSB station was on frequency.
The high S/N achieved for all intelligible signals allowed the use of a customised VOX to detect the SSB signal, as the DSP had already done the heavy lifting. The VOX was a stateful system that behaved differently, depending on the state of the VOX.
In the closed state, the VOX had a 0.5 second delay before opening. This prevented noise bursts from causing false signal detection. If the signal disappeared before thye 0.5 seconds was reached, the timer would be reset. If the signal persisted for at least 0.5 seconds, the VOX would enter the open state with different characteristics.
In the open state, there was no 0.5 second detection delay. Any signal that exceeded the detection threshold would be counted. Instead, there was a hold timer of 1.5 seconds that would keep the VOX open, unless a signal (however brief) was detected within that 1.5 seconds. When the hold timer expired, the VOX would return to the closed state.
The VOX was implemented with a hardware peak detector and comparator driving a logic input on a PIC 16F84 microcontroller. The actual VOX logic was implemented in the PIC in assembly language. As there were enough hardware pins available for 5 channels, 5 channels were implemented. These channels could be configured as SSB (with the VOX characteristics above), "simplex" (no delay or hold time, suitable for interfacing to a FM transceiver, and "duplex", where both input and output control signals were active at the same time, for interfacing to a repeater or other duplex device. The PIC code bridged these 5 ports together and managed the PTT/"COS" interactions between them. I still have the PIC source code lying around somewhere.
As implemented, my system worked well on VHF, with flawless operation. However, on HF it was prone to false triggering by signals greater than 1 kHz off frequency but within the passband. The next stage would have been to implement a low pass filter between the output of the DSP NR unit and the input of the peak detector, to prevent grossly off frequency signals from tripping the VOX. I never got around to testing this enhancement, so it remains theoretical
Today, all this could be done in DSP on a SDR platform, and the SuperPeater sounds like a superset of even that capability, implemented in a SDR.
Tony - Agreed on all points, and I think it's a failure of imagination now that we have Software Defined Transceivers that we're not doing more SSB on VHF / UHF if for no other reason that the power spectral density is so much higher, and we can thus get by with lower powered transmitters. "All mode" radios used to be expensive compared to FM radios, but now with SDTs, SSB operation is just a different menu item.
That, and DSP techniques can keep SSB reception perfectly aligned with the transmission for best possible signal reception. In the next installment of the SuperPeater concept, I'm going to suggest a linear translator, and using SSB would be perfect for that.
Yes, the Raspberry Pi is built forLinux, their version of Linux. I spent the better part of three days getting ASL3 on Debian 12.5 up on an RPi4B and it was crashing every 7-8 hours. I pulled out an older junkbox atom computer with 8Gb RAM and some storage and have had ASL3 on Debian 12.5 running solid for 3+ months now supporting one of David Gleason's new Allscan UC120 Comms interfaces for a duplex radioless node. Now folks from my club are coming to me asking about it as they are telling me it's the best audio they hear on the repeater. Once I can find the time to get DVSwitch on it . . . I'll be on my ClearNode less
You're doing great stuff Steve, keep at it. I may see you in Xenia.
Stay well; 'cause life is beautiful. /73 de K3FZT / Steve
Steven - I acknowledge that there are many stories like yours about instability with Raspberry Pis, but counterbalancing that are stories about the opposite, about apps running on Raspberry Pis where the uptime is measured in years. I'm not sure what to think when I've read that one of the most popular commercial applications of Raspberry Pi units is in updated elevator controls.
Like all Linux distributions, Raspberry Pi OS is in continuous evolution... as is the firmware.
Over the time I've been a fan of Raspberry Pis, some things I've learned that affect stability:
* RPis are acutely sensitive to marginal power supply. Folks who've used, for example, Apple's USB power supplies (the larger ones for iPads, and now the USB C power supply for laptops) make a huge difference in reliability.
* Raspberry Pi periodically issues firmware updates, but those aren't applied automatically just by using a newer Raspberry Pi OS. Firmware updates have to be manually applied.
* The use of Micro SD cards for "disk" storage can be a reliability issue if less expensive (cheap, generic) SD cards are used. They just lose data, transfer speeds are slower, circuitry is marginal, et.
* Some demanding applications really need more RAM than what was readily available until the Raspberry Pi 4s became available with > 1 GB RAM.
But yeah... I've heard a lot of success stories like yours of "just get a cheap PC".
When talking about TNCs in the late 70's, you said... "At that time, microcomputers existed (the MITS Altair debuted in January 1975), but cost thousands of dollars (for a realistically usable unit). Dumb (video) terminals were available surplus for a few hundred dollars."
I don't believe that the availability of late 70's "microcomputers" is relevant to the discussion of TNCs in that era. Keep in mind you needed a dumb terminal (or a Teletype machine) for console I/O to use those computers.
With BBS / Mailbox functionality built into the early TNCs, if you had a dumb terminal ("glass TTY") console device, a "microcomputer" didn't really bring anything to the party.
Mark - The point I was trying to make was about the name originally chosen for the packet controllers being called TERMINAL node controllers to reflect the then dominant use of TERMINALS as user interface devices.
By 1980 there were a number of household personal computers available that among other things, filled the role of (hardware) dumb terminals with less hassle than using a dumb terminal. I remember reading 73 and that terminal emulator software for packet radio was one of the first uses of personal computers in Amateur Radio.
The role of the TNC began to morph once household personal computers became widely available such as "packet radio adapters" being designed to plug into a Commodore 64. Another example of personal computers displacing TNCs and dumb terminals was the BayPac modems and software running on a DOS PC (see https://tigertronics.com/baysuprt.htm).
This was a great issue. So much good stuff over the past few weeks.
HFSignals BitX40 was my first real introduction to HF (well, I had a Heath SB104 that breaks every other QSO so I don't count that). The first time I got it on the air I heard a QSO with an antarctic station during solar minimum. I own two Bitx40s, one with the analog VFO and the second with the DDS VFO using an Arduino. I also built a very early revision uBitx as a portable radio (including DIY Li-Ion battery packs) to take up to the Boundary Waters. That rig has been through several cases and many upgrades to resolve the hardware issues on the older variants. It was a great learning experience. I never bought an sBitx, mainly due to the cost and redundant functionality. The xBitx looks awesome though. With the easily changeable standard batteries it looks like it's designed exactly for what I was trying to achieve with the uBitx.
I liked your mention of hardware TNCs being good for APRS digipeaters too. I'm a fan of software TNCs for ax.25, Direwolf in particular, but there's nothing like being able to extend a network (APRS, Packet, etc...) with no more complication than pressing the power button on the TNC and radio. My local club supports a large bike race in some rough terrain and fill-in APRS digipeaters are critical for tracking. Hardware TNCs meet the KISS principal here and are the perfect solution.
You are probably aware, but you don't need to write code to use GNURadio. Most of my GNURadio experimentation has been ore of a professional (infosec) interest, but I found this blog post extremely helpful in getting started with it: https://www.blackhillsinfosec.com/how-to-replay-rf-signals-using-sdr/ There was also a more basic post earlier that covered just listening and combining multiple audio streams, but I can't seem to find it anymore. They have some other interesting GNURadio posts here: https://www.blackhillsinfosec.com/tag/gnuradio/
Thanks for mentioning wsjtx_improved. I had not seen this before and I have some small-display use cases for this. I will be trying it out!
You mentioned StarLink being the first consumer product using phased array antennas. Wifi has used this for beam forming since 802.11n.
I'm excited for the 16gb version of the RPi. You really can't beat an ARM-based SBC for power efficiency in "appliance" applications, and the GPIO ports give hardware interfacing flexibility that higher-power, similarly priced x86 machines can't match.
Ben - It was poor writing on my part if I gave the impression that one can only use GNU Radio for "development". I liken it to folks using Pascal or Basic or Python to prototype an idea and then think that they have to write "the real thing" in a "real programming language" like C. Nope - with a fast enough compute, Pascal or Basic or Python code runs just great! If I can find enough modules that implement the various elements of my fantasy Amateur Radio data communications mode, then yep - just run those on a Software Defined Transceiver.
Agreed that beam forming has been in use for quite a while now in Wi-Fi access points, but that's only using a few elements and (at least in my experience) it's not exactly realtime (at least, I can watch my Wi-Fi signal strength improve when I open my laptop or phone only after several seconds).
But phased ARRAY... that's a whole 'nother layer of computational complexity and radio technology wizardry. I remember reading about the first (that I ever heard of) phased array antenna system on the US Navy's Aegis combat RADAR systems, first deployed in 1983. It took a while for that tech to "filter down" to us.
When Starlink first introduced "Dishy McFlatface", the technopunditocracy sneered that Starlink was subsidizing it by 50% or so, but thanks to great design chops and volume production, reportedly Starlink makes a small profit on each antenna now and of course it makes their LEO broadband system not just practical... but highly usable.
The SuperPeater concept looks interesting, and certainly doable today, including analog SSB. Almost 20 years ago, I ran a SSB Echolink node that worked very well, as far as voice goes (DTMF was a different story). In fact so well, FM and PC Echolink users couldn't even tell that the SSB users were actually on SSB!
As for the hardware and software involved, there were a few key components. The system ran SSB simplex in the general "ragchewing" part of the 2m band, around 144.300 MHz on a Yaesu FT-480R (10W PEP).
In the receive audio path, I used a DSP noise reduction unit made by Michels Engineering from Germany. This unit had a couple of desirable characteristics. Firstly, it was capable of excellent voice clarity down to the point where the unprocessed signal was barely audible. Secondly, for the cost of slightly reduced sensitivity, a high degree of noise reduction could be achieved, even for very weak signals. This DSP was the reason that the received audio was hard to distinguish from FM, provided the SSB station was on frequency.
The high S/N achieved for all intelligible signals allowed the use of a customised VOX to detect the SSB signal, as the DSP had already done the heavy lifting. The VOX was a stateful system that behaved differently, depending on the state of the VOX.
In the closed state, the VOX had a 0.5 second delay before opening. This prevented noise bursts from causing false signal detection. If the signal disappeared before thye 0.5 seconds was reached, the timer would be reset. If the signal persisted for at least 0.5 seconds, the VOX would enter the open state with different characteristics.
In the open state, there was no 0.5 second detection delay. Any signal that exceeded the detection threshold would be counted. Instead, there was a hold timer of 1.5 seconds that would keep the VOX open, unless a signal (however brief) was detected within that 1.5 seconds. When the hold timer expired, the VOX would return to the closed state.
The VOX was implemented with a hardware peak detector and comparator driving a logic input on a PIC 16F84 microcontroller. The actual VOX logic was implemented in the PIC in assembly language. As there were enough hardware pins available for 5 channels, 5 channels were implemented. These channels could be configured as SSB (with the VOX characteristics above), "simplex" (no delay or hold time, suitable for interfacing to a FM transceiver, and "duplex", where both input and output control signals were active at the same time, for interfacing to a repeater or other duplex device. The PIC code bridged these 5 ports together and managed the PTT/"COS" interactions between them. I still have the PIC source code lying around somewhere.
As implemented, my system worked well on VHF, with flawless operation. However, on HF it was prone to false triggering by signals greater than 1 kHz off frequency but within the passband. The next stage would have been to implement a low pass filter between the output of the DSP NR unit and the input of the peak detector, to prevent grossly off frequency signals from tripping the VOX. I never got around to testing this enhancement, so it remains theoretical
Today, all this could be done in DSP on a SDR platform, and the SuperPeater sounds like a superset of even that capability, implemented in a SDR.
Tony - Agreed on all points, and I think it's a failure of imagination now that we have Software Defined Transceivers that we're not doing more SSB on VHF / UHF if for no other reason that the power spectral density is so much higher, and we can thus get by with lower powered transmitters. "All mode" radios used to be expensive compared to FM radios, but now with SDTs, SSB operation is just a different menu item.
That, and DSP techniques can keep SSB reception perfectly aligned with the transmission for best possible signal reception. In the next installment of the SuperPeater concept, I'm going to suggest a linear translator, and using SSB would be perfect for that.
Yes, the Raspberry Pi is built forLinux, their version of Linux. I spent the better part of three days getting ASL3 on Debian 12.5 up on an RPi4B and it was crashing every 7-8 hours. I pulled out an older junkbox atom computer with 8Gb RAM and some storage and have had ASL3 on Debian 12.5 running solid for 3+ months now supporting one of David Gleason's new Allscan UC120 Comms interfaces for a duplex radioless node. Now folks from my club are coming to me asking about it as they are telling me it's the best audio they hear on the repeater. Once I can find the time to get DVSwitch on it . . . I'll be on my ClearNode less
You're doing great stuff Steve, keep at it. I may see you in Xenia.
Stay well; 'cause life is beautiful. /73 de K3FZT / Steve
Steven - I acknowledge that there are many stories like yours about instability with Raspberry Pis, but counterbalancing that are stories about the opposite, about apps running on Raspberry Pis where the uptime is measured in years. I'm not sure what to think when I've read that one of the most popular commercial applications of Raspberry Pi units is in updated elevator controls.
Like all Linux distributions, Raspberry Pi OS is in continuous evolution... as is the firmware.
Over the time I've been a fan of Raspberry Pis, some things I've learned that affect stability:
* RPis are acutely sensitive to marginal power supply. Folks who've used, for example, Apple's USB power supplies (the larger ones for iPads, and now the USB C power supply for laptops) make a huge difference in reliability.
* Raspberry Pi periodically issues firmware updates, but those aren't applied automatically just by using a newer Raspberry Pi OS. Firmware updates have to be manually applied.
* The use of Micro SD cards for "disk" storage can be a reliability issue if less expensive (cheap, generic) SD cards are used. They just lose data, transfer speeds are slower, circuitry is marginal, et.
* Some demanding applications really need more RAM than what was readily available until the Raspberry Pi 4s became available with > 1 GB RAM.
But yeah... I've heard a lot of success stories like yours of "just get a cheap PC".
When talking about TNCs in the late 70's, you said... "At that time, microcomputers existed (the MITS Altair debuted in January 1975), but cost thousands of dollars (for a realistically usable unit). Dumb (video) terminals were available surplus for a few hundred dollars."
I don't believe that the availability of late 70's "microcomputers" is relevant to the discussion of TNCs in that era. Keep in mind you needed a dumb terminal (or a Teletype machine) for console I/O to use those computers.
With BBS / Mailbox functionality built into the early TNCs, if you had a dumb terminal ("glass TTY") console device, a "microcomputer" didn't really bring anything to the party.
Mark Davis - AD7EF
Mark - The point I was trying to make was about the name originally chosen for the packet controllers being called TERMINAL node controllers to reflect the then dominant use of TERMINALS as user interface devices.
By 1980 there were a number of household personal computers available that among other things, filled the role of (hardware) dumb terminals with less hassle than using a dumb terminal. I remember reading 73 and that terminal emulator software for packet radio was one of the first uses of personal computers in Amateur Radio.
The role of the TNC began to morph once household personal computers became widely available such as "packet radio adapters" being designed to plug into a Commodore 64. Another example of personal computers displacing TNCs and dumb terminals was the BayPac modems and software running on a DOS PC (see https://tigertronics.com/baysuprt.htm).
This was a great issue. So much good stuff over the past few weeks.
HFSignals BitX40 was my first real introduction to HF (well, I had a Heath SB104 that breaks every other QSO so I don't count that). The first time I got it on the air I heard a QSO with an antarctic station during solar minimum. I own two Bitx40s, one with the analog VFO and the second with the DDS VFO using an Arduino. I also built a very early revision uBitx as a portable radio (including DIY Li-Ion battery packs) to take up to the Boundary Waters. That rig has been through several cases and many upgrades to resolve the hardware issues on the older variants. It was a great learning experience. I never bought an sBitx, mainly due to the cost and redundant functionality. The xBitx looks awesome though. With the easily changeable standard batteries it looks like it's designed exactly for what I was trying to achieve with the uBitx.
I liked your mention of hardware TNCs being good for APRS digipeaters too. I'm a fan of software TNCs for ax.25, Direwolf in particular, but there's nothing like being able to extend a network (APRS, Packet, etc...) with no more complication than pressing the power button on the TNC and radio. My local club supports a large bike race in some rough terrain and fill-in APRS digipeaters are critical for tracking. Hardware TNCs meet the KISS principal here and are the perfect solution.
You are probably aware, but you don't need to write code to use GNURadio. Most of my GNURadio experimentation has been ore of a professional (infosec) interest, but I found this blog post extremely helpful in getting started with it: https://www.blackhillsinfosec.com/how-to-replay-rf-signals-using-sdr/ There was also a more basic post earlier that covered just listening and combining multiple audio streams, but I can't seem to find it anymore. They have some other interesting GNURadio posts here: https://www.blackhillsinfosec.com/tag/gnuradio/
Thanks for mentioning wsjtx_improved. I had not seen this before and I have some small-display use cases for this. I will be trying it out!
You mentioned StarLink being the first consumer product using phased array antennas. Wifi has used this for beam forming since 802.11n.
I'm excited for the 16gb version of the RPi. You really can't beat an ARM-based SBC for power efficiency in "appliance" applications, and the GPIO ports give hardware interfacing flexibility that higher-power, similarly priced x86 machines can't match.
Ben - It was poor writing on my part if I gave the impression that one can only use GNU Radio for "development". I liken it to folks using Pascal or Basic or Python to prototype an idea and then think that they have to write "the real thing" in a "real programming language" like C. Nope - with a fast enough compute, Pascal or Basic or Python code runs just great! If I can find enough modules that implement the various elements of my fantasy Amateur Radio data communications mode, then yep - just run those on a Software Defined Transceiver.
Agreed that beam forming has been in use for quite a while now in Wi-Fi access points, but that's only using a few elements and (at least in my experience) it's not exactly realtime (at least, I can watch my Wi-Fi signal strength improve when I open my laptop or phone only after several seconds).
But phased ARRAY... that's a whole 'nother layer of computational complexity and radio technology wizardry. I remember reading about the first (that I ever heard of) phased array antenna system on the US Navy's Aegis combat RADAR systems, first deployed in 1983. It took a while for that tech to "filter down" to us.
When Starlink first introduced "Dishy McFlatface", the technopunditocracy sneered that Starlink was subsidizing it by 50% or so, but thanks to great design chops and volume production, reportedly Starlink makes a small profit on each antenna now and of course it makes their LEO broadband system not just practical... but highly usable.
Nice to subtly discover another Battlestar Galactica fan... One of the few TV shows where the remake was better than the original in my opinion. :-)