2025-08-15 — ZRDC 2025 Update, What’s New at DLARC - August 2025, LinHT - Tech Innovation In AR, A Modest Proposal, Amateur Radio Future Systems Skunkworks, Mesh Networking, AMSAT-CA, AREDN at DEFCON
Just been reading your views on LinHT. I'm very interested in this project. This is really disruptive technology, and that's a good thing for Amateur Radio - innovation and experimentation. The fact that SDR can basically do anything that can fit within the system bandwidth is what has always excited me about the technology, even though up until now SDR hasn't often been used that way.
My only concern is GNU Radio has proven to be relatively inaccessible to me, due to the state of its documentation (and no referring me to videos, I can't process instructional videos efficiently), and at the time I last tried to learn GNU Radio, it was undergoing significant (and often breaking) changes between versions. I'd like a better way to learn GNU Radio, whether I implement designs on a LinHT or my existing PlutoSDR.
Tony - I share your preference for having reference to understanding something in text rather than videos. (That said, videos are good for "familiarization" but not when I'm ready to start "diving in". I'm not yet an active GNU Radio user, but I've seen several references to GNU Radio's weak documentation, and jarring breaks of compatibility between versions.
One of the responses I've received when asking about the documentation issue is that GNU Radio Companion is a Graphical User Interface to using GNU Radio, and that's the approach I will be taking when I start using it. This seems like a good tutorial - https://cs.wmich.edu/alfuqaha/Fall11/cs6570/lectures/grc_tutorial1.pdf.
You might also want to check out this new book (published just a few months ago): Practical SDR - Getting Started with Software-Defined Radio by David Clark and Paul Clark. ISBN 978-1-7185-0254-3. I have it and it really seems like an approachable treatment of GNU Radio. I'm told that at least one of the authors will be a GRCon 2025, and I'll have my copy with me to get autographed. And I'll be at least skim through it to be more familiar with GNU Radio before attending GRCon 2025 for a week.
I agree. Video is a good medium for an overview of something - “this is what it looks like and what it can do”, but I much prefer written/pictorial instructions, or interactive tutorials where I can work through each step in my own time.
I’ll have to check out those references you gave. I did find a basic GNU Radio tutorial, which was easy to follow, but it was still too big a contextual jump moving from that (which used sound device ls) to building real radios using SDR hardware - the extra variables and multiple driver sets are a big issue on their own!
Oh, and the issues I’ve had trying to learn GNU Radio in the past were while using GRC, not trying to write code directly.
Steve this was a BEEFY edition of ZR! I typically read it over a few sittings and this was no exception. I've been meaning to set up ka9q-radio, might finally do it now.
I must say my knee jerk was in favor of the current repeater coordination system a while back when I first saw you argue against it but as time has gone on I think I agree with you now. Where I am, other than scheduled nets, there's only two or three repeaters that you can sometimes hear spontaneous conversations on during peak morning/evening times. And there are no "available" 2m pairs. The current system no longer serves us.
I respect K6BP and he identifies real problems with the status quo, but as a software dev I don't see "Post Open" going anywhere. I think the goals are noble, but choosing strong copyleft licenses like AGPL and funding enforcement would be an 80% solution at 20% of the effort. Creators looking to make money could offer a commercial license that removed AGPL's redistribution requirements for a fee.
His points about compliance issues are well-taken, and crass as it is, I've always advocated for protesting against burdensome, ill-considered regulations by geoblocking users from those jurisdictions. Anyway the EU actually did water down the regulation he talked about after complains from open source organizations.
Justin - Thanks! Sometimes there's more to say, and I just gave up trying to keep Zero Retries to a "typical newsletter" length.
Thanks for your thoughts on the repeater situation. Such a situation would perhaps be tolerable if it weren't for the incredibly overprotective attitude that most repeater owners have over the use of THEIR repeater and THEIR channel.
I'm not equipped to evaluate Post Open, but I keep in mind that K6BP was way ahead of the times in understanding the importance, especially the commercial importance and use of Open Source.
Hey no complaints here on the newsletter length! There are plenty of places to find short summaries of things, but very few good deep dives so I appreciate the ones here!
Forgot to mention - I perused CentyLab's site. Hadn't heard of them and the products seem very cool and useful
Steve, I was in Palo Alto in 1986 for a series of meetings with a researcher from SRI (Stanford Research Institute) funded by DARPA at the time, for my day job with Intel (artificial intelligence program manager… ha! Sure wish I still had one of those business cards to flash around today). I can’t recall his name or his call, but we had a lively dinner where he explained packet radio and how his team of 3 had used their amateur equipment to fulfill the quantitative metrics for their report on their grant from DARPA for peer to peer messaging in a doomsday scenario… damn, wish I could remember his name. It was inspiring, and I’ve told that story many times to nerds who say something about our digital modes today… (yes, they scored a lot of money on that contract, and then demonstrated feasibility with affordable equipment).
Love the blog, the concept, and I’m one of those folks who learned about you and your shared cause from HRWB.
Regarding the idea of a data communication system monitoring multiple frequency channels simultaneously: isn’t that exactly what FT8 does (although at low data rates using narrow bandwidth channels)?
Craig - I'm not an FT8 user, but in my limited understanding of FT8, I thought that there were "water holes" where FT8 activity occurs within a limited portion of each band. If that's not correct, please elaborate.
Steve, you are correct that there's a default or "standard" FT8 frequency for each band. The FT8 software works with a standard ham tranceiver with 2.5 KHz audio bandwidth. One way to think of what happens next is to look at how ka9q-radio can take in a several MHz wide slice of spectrum and demodulate chunks of that as separate signals, each several kHz wide. FT8 takes in a 2.5 kHz wide slice of spectrum and demodulates independent chunks, maybe 50 Hz wide or so. The user manual has a nice example. Look at the waterfall display and the "Band Activity" pane in the figure here. Unlike ODFM modulation (where multiple carriers transport a single bit stream that has been split up), my understanding is that in FT8, the various narrow band signals are independent (other than needing to comply with the overall frame timing). I'm no FT8 expert, so I hope I got this stuff right. Maybe someone with more knowledge can chime in.
I should have mentioned that the "Freq" column in the Band Activity list is the offset in Hz of the stations reported, within the received audio. It looks like the radio used has an RX bandwidth around 3 kHz.
In about the same bandwidth as a SSB signal, there can be around 50 different signals in that space. The WSJT-X software can decode all those signals including ones that are virtually right on top of each other. The biggest limitation is the 13 character limitation on the message. A few things like 'CQ', grid zones, etc are compressed as a special character. The entire message needs to fit in about 12 seconds of transmission, but sometimes, especially with good signals, a shorter segment of the transmission can be decoded. The timing of the transmission has to be within 2 seconds of UTC... Decoding may be done with signals that are 24 dB below the noise level though another strong signal overlapping may block it at your location.
Jim - Thanks for that additional detail on FT8. I have not seen that type of explanation. Techniques / technologies like FT8 that are tested and proved out in Amateur Radio (because, we CAN) constantly amaze me. Something like FT8 never would have occurred to me.
Just been reading your views on LinHT. I'm very interested in this project. This is really disruptive technology, and that's a good thing for Amateur Radio - innovation and experimentation. The fact that SDR can basically do anything that can fit within the system bandwidth is what has always excited me about the technology, even though up until now SDR hasn't often been used that way.
My only concern is GNU Radio has proven to be relatively inaccessible to me, due to the state of its documentation (and no referring me to videos, I can't process instructional videos efficiently), and at the time I last tried to learn GNU Radio, it was undergoing significant (and often breaking) changes between versions. I'd like a better way to learn GNU Radio, whether I implement designs on a LinHT or my existing PlutoSDR.
Tony - I share your preference for having reference to understanding something in text rather than videos. (That said, videos are good for "familiarization" but not when I'm ready to start "diving in". I'm not yet an active GNU Radio user, but I've seen several references to GNU Radio's weak documentation, and jarring breaks of compatibility between versions.
One of the responses I've received when asking about the documentation issue is that GNU Radio Companion is a Graphical User Interface to using GNU Radio, and that's the approach I will be taking when I start using it. This seems like a good tutorial - https://cs.wmich.edu/alfuqaha/Fall11/cs6570/lectures/grc_tutorial1.pdf.
You might also want to check out this new book (published just a few months ago): Practical SDR - Getting Started with Software-Defined Radio by David Clark and Paul Clark. ISBN 978-1-7185-0254-3. I have it and it really seems like an approachable treatment of GNU Radio. I'm told that at least one of the authors will be a GRCon 2025, and I'll have my copy with me to get autographed. And I'll be at least skim through it to be more familiar with GNU Radio before attending GRCon 2025 for a week.
I agree. Video is a good medium for an overview of something - “this is what it looks like and what it can do”, but I much prefer written/pictorial instructions, or interactive tutorials where I can work through each step in my own time.
I’ll have to check out those references you gave. I did find a basic GNU Radio tutorial, which was easy to follow, but it was still too big a contextual jump moving from that (which used sound device ls) to building real radios using SDR hardware - the extra variables and multiple driver sets are a big issue on their own!
Oh, and the issues I’ve had trying to learn GNU Radio in the past were while using GRC, not trying to write code directly.
Steve this was a BEEFY edition of ZR! I typically read it over a few sittings and this was no exception. I've been meaning to set up ka9q-radio, might finally do it now.
I must say my knee jerk was in favor of the current repeater coordination system a while back when I first saw you argue against it but as time has gone on I think I agree with you now. Where I am, other than scheduled nets, there's only two or three repeaters that you can sometimes hear spontaneous conversations on during peak morning/evening times. And there are no "available" 2m pairs. The current system no longer serves us.
I respect K6BP and he identifies real problems with the status quo, but as a software dev I don't see "Post Open" going anywhere. I think the goals are noble, but choosing strong copyleft licenses like AGPL and funding enforcement would be an 80% solution at 20% of the effort. Creators looking to make money could offer a commercial license that removed AGPL's redistribution requirements for a fee.
His points about compliance issues are well-taken, and crass as it is, I've always advocated for protesting against burdensome, ill-considered regulations by geoblocking users from those jurisdictions. Anyway the EU actually did water down the regulation he talked about after complains from open source organizations.
Justin - Thanks! Sometimes there's more to say, and I just gave up trying to keep Zero Retries to a "typical newsletter" length.
Thanks for your thoughts on the repeater situation. Such a situation would perhaps be tolerable if it weren't for the incredibly overprotective attitude that most repeater owners have over the use of THEIR repeater and THEIR channel.
I'm not equipped to evaluate Post Open, but I keep in mind that K6BP was way ahead of the times in understanding the importance, especially the commercial importance and use of Open Source.
Hey no complaints here on the newsletter length! There are plenty of places to find short summaries of things, but very few good deep dives so I appreciate the ones here!
Forgot to mention - I perused CentyLab's site. Hadn't heard of them and the products seem very cool and useful
Steve, I was in Palo Alto in 1986 for a series of meetings with a researcher from SRI (Stanford Research Institute) funded by DARPA at the time, for my day job with Intel (artificial intelligence program manager… ha! Sure wish I still had one of those business cards to flash around today). I can’t recall his name or his call, but we had a lively dinner where he explained packet radio and how his team of 3 had used their amateur equipment to fulfill the quantitative metrics for their report on their grant from DARPA for peer to peer messaging in a doomsday scenario… damn, wish I could remember his name. It was inspiring, and I’ve told that story many times to nerds who say something about our digital modes today… (yes, they scored a lot of money on that contract, and then demonstrated feasibility with affordable equipment).
Love the blog, the concept, and I’m one of those folks who learned about you and your shared cause from HRWB.
David - Thanks for the cool story!
Regarding the idea of a data communication system monitoring multiple frequency channels simultaneously: isn’t that exactly what FT8 does (although at low data rates using narrow bandwidth channels)?
Craig - I'm not an FT8 user, but in my limited understanding of FT8, I thought that there were "water holes" where FT8 activity occurs within a limited portion of each band. If that's not correct, please elaborate.
Steve, you are correct that there's a default or "standard" FT8 frequency for each band. The FT8 software works with a standard ham tranceiver with 2.5 KHz audio bandwidth. One way to think of what happens next is to look at how ka9q-radio can take in a several MHz wide slice of spectrum and demodulate chunks of that as separate signals, each several kHz wide. FT8 takes in a 2.5 kHz wide slice of spectrum and demodulates independent chunks, maybe 50 Hz wide or so. The user manual has a nice example. Look at the waterfall display and the "Band Activity" pane in the figure here. Unlike ODFM modulation (where multiple carriers transport a single bit stream that has been split up), my understanding is that in FT8, the various narrow band signals are independent (other than needing to comply with the overall frame timing). I'm no FT8 expert, so I hope I got this stuff right. Maybe someone with more knowledge can chime in.
https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.7.0.html#TUT_EX3
I should have mentioned that the "Freq" column in the Band Activity list is the offset in Hz of the stations reported, within the received audio. It looks like the radio used has an RX bandwidth around 3 kHz.
Craig - Thanks for the explanation. So, FT8 is similar in concept to ka9q-radio (kind of subchannels).
In about the same bandwidth as a SSB signal, there can be around 50 different signals in that space. The WSJT-X software can decode all those signals including ones that are virtually right on top of each other. The biggest limitation is the 13 character limitation on the message. A few things like 'CQ', grid zones, etc are compressed as a special character. The entire message needs to fit in about 12 seconds of transmission, but sometimes, especially with good signals, a shorter segment of the transmission can be decoded. The timing of the transmission has to be within 2 seconds of UTC... Decoding may be done with signals that are 24 dB below the noise level though another strong signal overlapping may block it at your location.
Jim - Thanks for that additional detail on FT8. I have not seen that type of explanation. Techniques / technologies like FT8 that are tested and proved out in Amateur Radio (because, we CAN) constantly amaze me. Something like FT8 never would have occurred to me.