2025-02-07 — New Kenwood TM-D750A, The Coming 21st Century AR Networking Revolution, Reality Check on FCC Regs for AR VHF / UHF, Updated IP400 RPi HAT, RadioMail 1.5, LiNK500 TNC, RepeaterSTART App
Zero Retries is an independent newsletter promoting technological innovation that is occurring in Amateur Radio, and Amateur Radio as (literally) a license to experiment with and learn about radio technology. Radios are computers - with antennas! Now in its fourth year of publication, with 2400+ subscribers.
The ZR > BEACON articles in this issue about RadioMail 1.5 and the mention in that announcement about the DIY599 LiNK500 TNC resulted in a delightful hour spent chasing various links and learning more about the “near death and resurrection” of the Robust Packet mode. Robust Packet is pretty amazing - designed from scratch for the vagaries of the HF bands using a 500 Hz bandwidth, use of (audio) Orthogonal Frequency Division Multiplexing (OFDM), Forward Error Correction (FEC), 200 or 600 bps, etc. It was fun getting caught up that Robust Packet is actively being developed and used.
Re-implementing Robust Packet is just one example that there is so much technological innovation going on, that we just (almost) don’t hear about. Robust Packet and the LiNK500 is yet another great example that computing power combined with new software is enabling things that in previous eras just was not possible to do. Now such things are practically routine (but, it’s still… radio… you know).
My congrats and kudos to Georges Auberger WH6AZ of Island Magic Co. for the excellent RadioMail app, and Oliver Harms DL4KA of DiY599 for the very interesting LiNK500 modem.
- - -
The Firehose (as in Attempting to Drink From) - dPMR (Digital Private Mobile Radio)
I think “Zero Retries Firehose Edition” will be the name of a periodic issue of Zero Retries of Zero Retries Interesting things I’ve found and want to share out, but just cannot fit into a story, or even a brief mention in the ZR > BEACON section. Just terse mentions, lots of them, with one sentence descriptions. Amateur Radio Daily calls its version of this idea Overdrive.
One item was dPMR - Digital Private Mobile Radio. I hadn’t heard of (that I recall) dPMR, so did a quick web search, found the Wikipedia Digital private mobile radio article, and whee… there went yet another thirty minutes of delightful reading. A few (?) interesting things that leaped out at me about dPMR:
Open, non-proprietary standard that was developed by the European Telecommunications Standards Institute (ETSI)
Access method: FDMA
Transmission rate: 4,800 bit/s
Modulation: four-level FSK
Digital voice
6.25 kHz channel, with a tight emission mask specified that you can use adjacent 6.25 kHz channels.
License-free products for use in the 446.0–446.2 MHz band within Europe.
dPMR446 equipment is capable of voice, data and voice+data modes of operation.
Provisions for simplex (peer to peer), repeater, or trunked repeater operation.
Apparently dPMR dates back to the early 2000s, so by now it’s a mature standard. Thus I’m sure there are software-only implementations of dPMR by now for Software Defined Transceivers. When I have time… 🤣 I’d like to dive in a bit deeper into dPMR to see how well the data capability is implemented. By now there’s room for improvement / evolution of dPMR potentially used in Amateur Radio - replacement of the AMBE CODEC with (potentially) Codec 2, implement Forward Error Correction, etc. But that’s mainly for curiosity - we have M17 now, designed by Amateur Radio for Amateur Radio (with callsigns!) and it already uses Codec 2 and does data.
So many interesting data modes, so little time…
- - -
First Bellingham Snowmageddon 2025
Our first snowmageddon of 2025 in Bellingham arrived as predicted by the weather oracle (the weather app on our mobile phones). The barely sub-freezing temps are allowing the snow to hang around for a week or so, but not impact mobility. N8GNJ Labs was snowed in for a day because trying to shovel out a drift in front of the door, during the Canadian wind gusts, would have been a fool’s errand. But the most fun of the snowfall was seeing our two kittencats see snow falling for the very first time. I sent a photo of one of them looking back at us from their window bed, and the caption I included when sharing that photo with family was “Dad… there’s something weird about the rain.”
- - -
Have a great weekend, all of you co-conspirators in Zero Retries Interesting Amateur Radio activities!
The Coming 21st Century Amateur Radio Networking Revolution
I posit that Amateur Radio is poised to experience the equivalent of the Packet Radio Revolution, but in the 21st century, with 21st century technology.
Portions of this article are repurposed from other writing I’ve been doing behind the scenes.
It’s understandable to be skeptical when imagining yet another new networking paradigm in Amateur Radio making a significant impact. Especially factoring in “now, we have the Internet”. But consider the impact that the relatively simple (in comparison to IP400) TAPR TNC-2 had on Amateur Radio beginning in the 1980s. It’s not overstating the impact to recall the catchphrase Join the Packet Radio Revolution! The development of the TNC-2 spawned a cottage industry of new packet radio products and entirely new hardware (and software) vendors. At a point, a very large portion of Amateur Radio Operators became involved in Packet Radio. New clubs were formed. Entire networks were deployed. BBS systems forwarded messages over VHF / UHF and HF. New systems continually evolved and new technologies such as 56k RF modems and Packet Radio satellites were developed. And all of that arose from the TNC-2.
In the 2020s, Amateur Radio can leverage so many technologies, as I’ve discussed here in Zero Retries. But no one, no project, no organization has attempted to take full advantage of all those technologies in combination… until the IP400 Network Project.
Just a few technologies and trends that will eventually be integrated into the IP400 Network Project:
Dynamic Peer to peer mesh networking Many have a dim view of Amateur Radio mesh networking because of past implementations operating at 1200 bps Audio Frequency Shift Keying (AFSK), the routers being TNC-2s or equivalent (slow 8-bit processors, 64 kB memory, radios being on the same frequency (halving the throughput with each hop), etc. In the 2020s, we can easily implement multiple radio links at each node, including user nodes, we can use much faster and more robust links, we have much more compute power at each node, we have inexpensive GPS receivers to implement a common time base and precise location of each node, etc. Best of all, we can implement, experiment, and iterate - it’s easy to load new software.
Higher speed radios Per Martin Alcock VE6VH, the minimum speed of IP400 will be 100 kbps, which will be “legal” for use in the US - fits within the 100 kHz maximum bandwidth and 56,000 symbols per second maximum on the 420-450 MHz band.
ka9q-radio all band receiver The days of having to be on the same frequency to communicate are nearly past. There’s some protocol work to be created, but it will soon be possible to put out a call, or the data equivalent, on any VHF / UHF frequency or repeater, and be instantly connected to the person / system you’re calling, because receiving on all frequencies, simultaneously, will become easy and inexpensive.
Better, more robust modulations IP400 will introduce Orthogonal Frequency Division Multiplexing (OFDM) into Amateur Radio in the radio domain - independent radio frequency subcarriers… not merely audio frequency subcarriers. OFDM will have very profound effects when fully implemented.
More usable protocols such as TCP/IP IP400 will be able to route TCP/IP packets (initially IPv4, but hopefully soon IPv6, the protocol of the present). That means most TCP/IP apps we use can be used over Amateur Radio - web servers and browsers, email servers and clients, likely even live video at some point (future, faster IP400 radios). Recall that AX.25 was created for the technologies that were usable and accessible to Amateur Radio 45 years ago. TCP/IP was in use when AX.25 was created… it just wasn’t quite feasible to use it, widely, quite then1.
Cheap, powerful computers It’s impossible to overstate how game-changing this development is. We tend not to notice the impact of powerful computers because our current applications are so limited from narrow bandwidths and low-speed data applications, so Amateur Radio applications are largely background or “used only when operating”. But a real data communications system requires a dedicated computer for routing, supporting the network, acting as a web server, email server, etc. Few of us would want to dedicate our primary “big” computer to such tasks 24x7, but a $120 Raspberry Pi 5 is fully capable and inexpensive for such use. And if a general purpose computer / processor isn’t powerful enough, we have cheap (enough) power Field Programmable Gate Arrays (FPGAs).
Cheap, powerful operating systems We take Linux for granted now, but back in the day when packet radio was invented, single-tasking DOS with up to 640 kB of RAM and floppy disk storage was pretty good. We even have Real Time Operating Systems (RTOS) available now for computing processes that must be deterministic rather than asynchronous.
Supporting technologies Interfacing is easy now - Ethernet, USB, Wi-Fi, Bluetooth, standardized I/O buses. We don’t need to invent such things to support better radios.
More powerful beaconing A powerful concept by Bryan Hoyer K7UDR called “Hailing Channel” is nearly lost to obscurity now, but fortunately his presentation at the Digital Communications Conference 2012 is preserved on YouTube. Basically, a station should periodically beacon out all of its capabilities - frequencies it can operate on, its speeds, whether it has an email server and can accept email, if it has a web server, if it hears other nodes, if it has emergency power, weather data, etc. Yes, that is a lot of information, but again, we have a fast data mode now, and multiple channels to use.
More capable repeaters Multi Mode Digital Voice Modem (MMDVM) allows repeaters to provide services to different digital voice and some data modes. That’s just an early taste of what’s possible. Involving high profile, full duplex repeaters to data modes… and linking repeaters via radio… is a truly powerful capability.
More powerful tools for collaboration We used to mail paper newsletters and floppy disks to distribute information and software. Now we have websites, email lists, Discord, and Github. We can share, collaborate, and propagate new software versions more easily than ever before.
Computer and network familiarity Information technology, hacking, software development is more widespread than ever; it’s easy conceivable that the majority of Amateur Radio Operators in a decade will be comfortable with these technologies.
A culture of experimenting and hacking Amateur Radio has always had a culture of experimenting and hacking, first on radios, and more recently on computers, and now on Software Defined Radio technology. Increasingly, Amateur Radio appeals to those who experiment and hack with computers. Amateur Radio is presented to them, the response is often “Wait… I can experiment, and hack… with radios? Cool!”.
Also no one, no project, no organization has attempted to leverage all of those technologies to involve… update… modernize Amateur Radio VHF / UHF repeaters for the 21st century by doing more than voice and incidental data communications.
Finally, no project or organization (other than AREDN) has been interesting enough to appeal to (currently non-licensed) techies to consider getting involved in Amateur Radio… until the IP400 Network Project. The intense interest and rapid expansion of Meshtastic networks is proof that there is significant interest by individuals in data networking over radio; the IP400 Network Project could entice techies into Amateur Radio as “Meshtastic on steroids”.
Thus, I posit that the IP400 Network Project can realistically be considered The 21st Century Amateur Radio Networking Revolution.
Reality Check on Updating FCC Regulations for Amateur Radio VHF / UHF
By Steve Stroh N8GNJ
I’ve been (mistaken, it turns out) thinkinghoping that the FCC would update the Amateur Radio regulations to remove symbol rate and bandwidth limits from Amateur Radio VHF / UHF bands in 2025. I now understand that’s not going to happen without a significant new effort.
I’m indebted to “Deeply Sourced Prefers to Remain Anonymous - DSPTRA” for patiently walking me through a number of incorrect assumptions about the FCC’s various processes, in several rounds of extended emails. I think I have the “big picture” correct in my mind now.
The original Petition for Rulemaking filed by the ARRL in 2016, which became Docket 16-239 requested removal of symbol rates on the Amateur Radio HF bands. In concluding Docket 16-239 in its Report And Order And Further Notice Of Proposed Rulemaking dated 2023-11-13, the FCC removed the symbol rate limits as requested and implemented a 2.8 kHz bandwidth limit for data communications in the Amateur Radio HF bands. With that, Docket 16-239 is now complete. As in closed. As in no further action.
As a pro-forma, a courtesy, perhaps just curiosity, perhaps an oblique invitation to submit a new Petition for Rulemaking, or to get some a priori discussion of the topic on record… the FCC noted that the Amateur Radio VHF / UHF bands also had symbol rate limits and bandwidth limits. The FCC invited comments as to whether those should be changed, as had been done with the Amateur Radio HF bands.
There were a small number of comments filed, almost all of which were favorable to removing symbol rates and bandwidth limits from the Amateur Radio VHF / UHF bands. I think that the ARRL’s first and second comments were insightful and provided ample justification for removing symbol rates and bandwidth limits. ARDC also offered insightful comments favorable to removing symbol rates and bandwidth. I also offered my comments favorable to removing symbol rates and bandwidth.
My mistake in having some hope for further action on changes to the VHF / UHF bands was assuming that because the FCC asked for comments on changing symbol rates and bandwidth limits on the Amateur Radio VHF / UHF bands… that if the comments were favorable for making changes, that the FCC would act upon those comments. I simply did not understand the unwritten rules and processes of how the FCC operates.
But in these recent emails, DSPTRA explained to me, more than once, that Docket 16-239 was concluded, and that no further action by the FCC would be forthcoming as part of Docket 16-239.
Now I get that.
Next Steps to Remove Symbol Rate Limits and Bandwidth Limits from US VHF / UHF Bands
There are at least some Amateur Radio organizations that surely understood the real dynamics of this situation (request for comments did not imply any further action would be undertaken), but didn’t act on that knowledge, in the more than a year since the FCC’s request for comments, and comments being submitted.
Beyond those few that chose to reply to the FCC’s request for comments… candidly, I’m a bit stunned that I seem to be the only one with a real interest in… trying to see those favorable comments through to a the requested changes. It’s abundantly clear to me that removing (archaic, now irrelevant) symbol rate limits and (excessively restrictive) bandwidth limits is truly needed for Amateur Radio in the US to continue to innovate in radio technology and realize the full potential of our ability to experiment with data communications in our VHF / UHF bands.
Thus if we in US Amateur Radio want to see symbol rate limits and bandwidth limits changed (preferably, removed completely) from the Amateur Radio VHF / UHF bands, there will need to be a new Petition for Rulemaking filed with the FCC, requesting such changes and providing strong justification for doing so.
That’s not an insurmountable task… but it will take significant time and effort… and at least some (possibly significant) funding to get such a thing accepted at the FCC for realistic consideration.
In our email discussions, DSPTRA made a number of recommendations on how to make a stronger case (than I was originally considering) for such changes, and beyond the solid points made by us “remove symbol rate and bandwidth limits” commenters. I won’t go into those additional recommendations here as discussing them in public at this early stage would probably be counterproductive.
As for next steps now that I really understand the situation… I plan to do what I do, and start writing (my best guess of) a Petition for Rulemaking to remove symbol rate limits and bandwidth limits from the US Amateur Radio VHF / UHF bands. Once I have that completed, then I’ll try to figure out how to move to next steps.
One of the primary things in my Modernizing Amateur Radio in the 21st Century (working title) Petition for Rulemaking, I’ll point out is that no other country has such limits, and having no symbol rate limits or bandwidth limits have had no calamitous effects. Especially not to our friends to the North, Amateur Radio in Canada. I think it’s instructive this latest “let’s dream big” project for advancing Amateur Radio data communications in the 21st century - IP400, originated in Canada. Canada’s Amateur Radio regulations are such that “if they can work out a new Amateur Radio technology, they can make use of that technology. Ditto the creation of New Packet Radio in Europe.
Implications for IP400 Network Project Development in the US
Soberly, as I finally came to understand all of this, I discussed my conclusions with Martin Alcock VE6VH, the creator of the IP400 Network Project. I recommended to him that for there to be any deployment of IP400 in the US in 2025, on the 420-450 MHz band, just as New Packet Radio also found necessary for NPR systems to be legal to use at all in the US, IP400 will have to include a SAFAUSR (Silly Accommodation for Arcane US Regulations) mode.
VE6VH chuckled and said:
No problem! In my early development, I’m already achieving a 100 kbps data rate with 50,000 symbols / second with (2 bits per symbol) in a 50 kHz bandwidth.
He was, of course, amused by my suggested name for that mode.
Thus those of us in the US that want to have some fun with IP400 will be able to do so.
But in the longer term, for IP400 to succeed (it’s not being developed solely for use in Canada and the US), there will have to be some significant, widespread testing undertaken of its higher performance features, such as 500 kbps data, in real world usage (transmissions over the air).
For US users of IP400 to be able to test the “advanced modes” of IP400 (beyond SAFAUSR mode) in mid 2025 or so, I expect to (attempt to) file a request for an FCC Special Temporary Authority (STA), or a request for a Part 5 Experimental License. I’ve been told by two knowledgeable sources that either of those can be submitted by individuals. The experiments conducted under an STA or Part 5 license will be in support of an eventual Petition for Rulemaking, and that will be prominently mentioned in the applications for an STA or Part 5 license.
Breaking News - New Kenwood TM-D750A Mobile Radio Shown at Hamcation 2025
YouTube channel HAMTech RADIO SCANNER M0FXB CB DRONE HOBBY Diary seems to have the scoop:
(At least, that’s the first mention of it that surfaced in my YouTube feed.)
In the last few hours before publication, I couldn’t find anything more authoritative such as someone posting the front and back of the TM-750A handout.
Update - I was searching for the incorrect name used by the YouTube creator above. The correct product name is TM-D750A, which results in a few more, and more authoritative hits:
As with this unit being shown off at Tokyo Ham Fair 2025, this is still a mockup, not an actual working unit… not even a prototype, apparently. Just purely for show and tell, and the booth representative said that the feature set is still not fixed.
The only two surprises to me were that there’s USB-C connection and an SD card slot in both the radio unit and the display unit, and Wi-Fi.
The Kenwood USA Amateur Radio page is a clown show in still “featuring” the discontinued H-D74A, TM-D710GA, and TM-V71A. All nice products, but discontinued years ago now.
HamSCI 2025, 2025-03-14 and 15 in Newark, New Jersey, USA in 6 weeks. Tina KD7WSF and I will attend this event. I hope to meet up with any Zero Retries readers that are also attending HamSCI 2025 to talk about all things Zero Retries Interesting.
LinuxFest Northwest 2025, 2025-04-25 thru 27 in Bellingham, Washington, USA in 11 weeks. The largest Linux conference in the Pacific Northwest. No direct involvement with Amateur Radio, but I’ll be attending and learning.
Four Days In May 2025 - 2025-05-15 in Fairborn, Ohio USA (in conjunction with Hamvention 2025). The biggest and best QRP (low power operation) event in the world!
Hamvention 2025 - 2025-05-16 thru 18 in Xenia, Ohio, USA in 14 weeks. I will be attending this event. I hope to meet up with any Zero Retries readers that are also attending Hamvention 2025 to talk about all things Zero Retries Interesting.
Martin Alcock VE6VH on the IP400 Network Project email list:
Unfortunately we have had a setback in the Pi development. We were planning to use a module that has a variant of the processor that is on the Nucleo board, the difference is only the packaging and number of pins available for use. During the board debug it became evident that the module was using early silicon that still had bugs. I was able to get as far as getting the menu up using minicom on the Pi, so some progress was made, but the radio did not work as well as the ROM-based boot loader, so that basically ended that exercise. We have contacted the manufacturer about it, but so far no response and have no date on shipping any revisions.
The back up plan is to abandon the module in favour of using the same silicon as is on the Nucleo board, which we know works. I have made the board modifications and have shipped them off for manufacturing, I expect them in a week or so, and expect to resume pi testing by month end. The target date for the general availability of the Pi boards is the end of Q1 of this year.
Stay tuned.
The difference in the IP400 Raspberry Pi HAT from the original version to the current version is subtle, but significant. The current (newer) design uses a radio chipset with outboard discrete components. The former design used a “pre-integrated module” for the 400 MHz band - all the discrete components were built into the module.
The outboard discrete components (and the resulting “fussiness” associated with radio frequency components on a printed circuit board) complicate the design of the IP400 Raspberry Pi HAT… but not unacceptably so.
One bit of good news from this change is that the same radio chipset (on the revised board) can also cover the 902-928 MHz band - with just a change in outboard discrete components, and possibly a (minor?) change in layout to accommodate the higher frequency range.
I’m really impressed and proud of how the IP400 Network Project is evolving in realtime. VE6VH spotted this issue, and developed a workaround, before any IP400 Raspberry Pi HATS ever shipped, even for very, very early testing.
- - -
RadioMail 1.5 - The “Robust Packet Radio” Release
Georges Auberger WH6AZ via email announcement list:
I am happy to announce the release of RadioMail 1.5 aka the “Robust Packet Radio” release. Available now in the App Store.
Introducing support for Robust Packet mode
I’m excited to announce support for Robust Packet, a proven method for sending and receiving messages over HF radio. If you’ve used traditional packet on VHF/UHF, you already know it’s reliable, widely available, and works great for local communication. However, on HF, where signals face challenges like fading, noise, and interference, packet can struggle to perform effectively.
That’s where Robust Packet, invented by SCS (the maker of PACTOR), makes a difference. Specifically designed for HF, Robust Packet uses advanced error correction to ensure your messages get through even in challenging conditions. It offers better reliability than traditional packet on HF, providing greater resistance to multi-path propagation and signal fading.
Due to the proprietary nature of the protocol and the low throughput caused by the now-lifted FCC 300-baud limitation on HF, the number of Winlink RMS stations supporting Robust Packet is currently limited. You can check the latest list of Robust Packet stations available in your region here.
While the current network footprint is modest, adding an HF mode to RadioMail that doesn’t require a computer was a key motivation for supporting this mode. Hopefully, renewed interest will drive further expansion of the network.
Fortunately, Oliver DL4KA, the creator of the PA500 amplifier, is making Robust Packet even more accessible. He has introduced the LiNK500 TNC, an evolution of the Teensy-based TNC. The LiNK500 combines the functionality of a TNC and a sound card, while also adding the convenience of Bluetooth connectivity. This compact, standalone modem can be powered via USB, making it ideal for portable or off-grid use. Paired with RadioMail, the LiNK500 offers a seamless and efficient solution for Robust Packet communication on HF.
To use Robust Packet in RadioMail, simply select the LiNK500 modem as the Robust Packet TNC, then select a Robust Packet station you want to reach from the directory and connect.
I hope you’ll enjoy this release. If you have questions or feedback, let me know or join the conversations at https://groups.io/g/radiomail
This announcement is so fresh that the RadioMail website isn’t yet updated with this development (LiNK500 isn’t in the Modems & TNCs section).
Kudos to WH6AZ for another impressive addition to a great app. If you’re a iPhone or iPad user, the RadioMail app takes full advantage of the great user interface design that’s possible on iDevices.
One of the things I intend to attempt is to put together a personal Winlink station, mostly for my use to connect into Winlink via radio, and then use RadioMail via my household Wi-Fi to begin conversing with others via Winlink email.
The Link500 is a state-of-the-art communication device that combines a wide range of functions in a compact design:
1. USB Interface: Allows easy connection to computers and other devices. 2. Internal USB Hub: connects the internal device structure and provides an additional USB port for connecting a transceiver. 3. AX.25 Packet Radio for AFSK and RPR: Supports common protocols for amateur radio data transmission. 4. Audio Interface: Enables the transmission and processing of audio signals from the transceiver. 5. CAT Interface: Offers an interface for controlling the radio. 6. DATA Interface: Facilitates data transfer between raw bidirectional analog data from/to the radio. 7. Built-in GPS with external antenna connection: Provides precise location information with an external antenna. 8. Built-in BT Module, compatible with iOS, Android, Windows, Mac OS and Linux: Allows wireless connections to a variety of devices for flexible use, like a computer. 9. Built-in APRS Tracker: Supports automatic position and status reporting in amateur radio.
The Link500 is a powerful and versatile tool for anyone needing reliable and flexible communication solutions in critical environments.
My thanks to WH6AZ for alerting me to the existence of the LiNK500 TNC; I wasn’t previously aware of it. If you’re curious about the Robust Packet mode, one of the better descriptions I found was a document from Wavecom Elektronik AG - Advanced Protocols, Robust-Packet / AX.25 Packet-Radio with OFDM (apparently, monitoring [decoder] software.
I own a “its life was all too brief” Tracker / DSP TNC by SCS which was the first time Robust Packet was available. I had bought that unit because for its “9600/19200 Bd FSK (G3RUH)” modem and it was one of the few that used a Digital Signal Processor, so I was hoping for better 9600 bps performance… but I never actually connected it as I began the process of closing down our household around the time that I bought it.
Although SCS apparently chose to discontinue its development and support of Robust Packet (the Tracker / DSP TNC was the only SCS product that offered Robust Packet), those who used it loved it enough to continue it as projects.
Post Publication Update - My thanks to Justin Overfelt AB3E for this correction:
Minor correction on the availability of Robust Packet. Many (most?) SCS modems support it. I have a PTC-IIex that supports it for example. Ref "RPR Capable Modems" at https://privat.bahnhof.se/wb758759/rpr-modems.html.
I don’t know why I had the impression that Robust Packet was only available from SCS in the Tracker / DSP TNC. Given that the other SCS units in the linked list had Robust Packet capability from firmware updates, and the Tracker / DSP TNC shipped with Robust Packet, perhaps it was the first SCS unit to feature Robust Packet.
Given that SCS is continuing to offer Robust Packet as a feature in their commercial products, its doubly impressive that SCS apparently isn’t objecting to the projects to make Robust Packet available to Amateur Radio Operators without purchasing the very high end SCS P4dragon DR-7400 or DR-7800.
…
The first mention I learned of that “Robust Packet Lives On!” was WinRPR: Saving Robust Packet from oblivion. I later read of the Teensy RPR TNC, on which the LiNK500 is based, in part. I’m glad that Robust Packet mode now has a plug and play modem to be able to use it. The Robust Packet Network (associated to the Teensy RPR TNC) seems to be entirely in Europe, but perhaps with the existence of the LiNK500, it will expand to other parts of the world. I found a mention of a regional network in the US that uses Robust Packet - Virginia Packet Network.
I originally released version 1 of the "WA8LMF TNC Test CD" in 2006, with a slight update, version 1.1, in 2009.
This was an image file that created an audio CD. The disk contains a variety of recordings of packet APRS transmissions to verify/compare the performance of packet TNCs (both hardware and software). Over the past 16 years it has become sort of a de-facto standard for testing/comparing various packet radio receiving systems.
In 2009, computer CD systems were plagued with cheap unstable software-based audio decoding (the infamous "AC97" codec) that used system interrupts for timing. The audio sample rate would actually vary, depending on CPU loading and the number of tasks currently running on the computer.
On the other hand, AUDIO CD players (even cheap boomboxes and DiscMan portables) used stable crystal-controlled time-bases. In 2009, I chose to produce the disk as an audio CD (not a CD-ROM with .WAV files) to yield more accurate and repeatable tests of TNC performance.
The ver 1.1. CD was produced in the "CD-Extra" format that combines CD audio tracks playable on a music CD player -- with a data CD-ROM area accessible with a computer CD/DVD drive. (This hybrid format is sometimes used on modern music CDs to include song lyrics, artist bios, etc on the disk along with the music.)
Some users have had problems with recording the BIN/CUE format of the TNC Test image file to physical CDs. (This now-somewhat-obscure disk-image format was required because the more-common .ISO disk image format can't handle the mixed-mode half-music-CD/half-CD-ROM format of the disk.)
Today, the "horsepower" of the average computer has increased orders of magnitude since 2009. More importantly, for the last decade or so, most computers have been equipped with the "RealTek HD" audio chips that use an accurate crystal-controlled time-base. As a result, computer-playback of audio files is now very accurate with stable sample rates.
I have now re-released the Test CD as a standard CD-ROM in the common .ISO image format. This disk contains the identical test audio tracks, but now stored as lossless FLAC files. The .ISO image file can be used to burn a physical CD. Or the .ISO file can be used as-is, "mounted" as a virtual CD-ROM drive using a used drive letter on your system. Or the FLAC-format audio files could be copied to a flash drive.
I have extensively revised the page on my web site for the Test CD . It now includes download links for both the original ver 1.1 audio CD image, and the new ver 2.0 .ISO CD-ROM image.
Among other uses, the TNC Test CD was cited as a primary resource for the development of the innovative “correct for single bit errors causing CRC failures test by testing single bit flips” technique for the Dire Wolf Software TNC. That technique significantly improved reception of packet radio transmissions, but (as I recall from a presentation) it was only possible to test that technique because of the use of the TNC Test CD to do reliable A / B testing.
That he left his phone behind meant he was at least partially off the grid, but it didn’t mean he was incommunicado. A licensed radio amateur since his 12th birthday, Mac carried portable microwave equipment along with field deployable antennas in his go-bag.
I really love RSS - ke9v.net is high on my list of Amateur Radio feeds and so I was alerted to this new blog post within a few hours of it appearing.
KE9V is a gifted storyteller. He does an excellent job of weaving Amateur Radio into a story with the Amateur Radio elements supporting, rather than dominating the story. His Cornbread Road audio series was excellent, and KE9V did another serialized short novel a year or so ago that was similarly excellent, so I’m looking forward to another great series. I didn’t snapshot KE9V’s earlier novel, and KE9V is unsentimental about his past work (he periodically restarts his website / blog from scratch), so I can’t reference (or re-read) that one. But now I’m warned that anything KE9V does isn’t forever, so this time I am snapshotting all of the installments of this story.
Conference presentation by Jann Traschewski DG8NGN:
Over the last 15 years, HAMNET (Highspeed Amateur Radio Multimedia NETwork) has developed from an experiment into a stable infrastructure, particularly in German-speaking regions.
It generally connects unmanned amateur radio stations via microwave links using the IP- and BGP-protocol and provides a platform for networking amateur radio applications.
This talk will show how HAMNET has evolved and how it could evolve (challenges in deployment, expansion in Europe, densification of the backbone, higher speeds, access technologies for non-line-of-sight propagation).
Even without seeing the video of the presentation (not yet online as I write this story), DG8NGN’s Presentation slides provide a great overview.
I found the last two slides particularly interesting and informative:
HAMNET – Future Evolvement?
HAMNET RF Access for endusers: Most users don’t have a HAMNET site nearby (if so, they often suffer from a missing “line-of-sight” issue)
Use lower radio bands:
23cm: Standard WiFi gear with 5 MHz RF bandwidth and transverters?
That last bullet point I had not previously heard of - OpenWiFi… is very intriguing! This suggests that it may be feasible to implement Wi-Fi (various 802.11 implementations) on a Software Defined Transceiver (choice of bands) and use as little as a 2 MHz bandwidth.
I received a email from Bryan Luke KJ7BKH letting me know about his projects on HearHam.live (but slightly confusing, shown on https://hearham.com) and his smartphone app(s) RepeaterSTART:
The amateur radio listener for when you're not on the radio.
…
Repeater-START, the offline repeater listing app is for Windows, Linux, Raspberry Pi, Ubuntu, Librem Phone.
Now with grid square display, topographical maps and frequency preferences.
I’ve often thought that a map view of available repeaters would be a great repeater app and possibly a linkage to a VHF / UHF radio for “auto tuning”. As in “hmmm, that repeater looks interesting and in range” and you tap the repeater and the app sends the data for that repeater to your VHF / UHF radio, setting the appropriate mode (digital voice or FM), receive / transmit frequencies, and the CTCSS code (FM) or other access codes (digital voice).
The RepeaterSTART apps are the closest I know of to my envisioned mode of discovering available repeaters while mobile, including being able to generate a CHIRP file.
Smartphone displays might be a bit small (at least for my eyes) for effective display of repeater (and calculated coverage) maps, but a tablet would be about the right size.
I haven’t downloaded or played with RepeaterSTART, but if you’re interested, search for RepeaterSTART on Google Play and the IOS App Store. I confess that I don’t understand the interplay with the HearHam web site, back end services (?), the GitHub repo for Repeater-START, and Windows and Linux apps, and the Android and IOS apps.
There are some payment tiers for the apps or the web page services that aren’t quite clear to me.
Rick Schnicker KD0OSS on his Ham Radio And Digital Audio Modes blog:
This article will document my attempts to add extra digital modes to OpenRTX for the Module17 board. The Module17 board was designed mainly to run the M17 open source digital audio mode which makes use of the open source audio codec CODEC2.
NOTE: All of the modifications made to OpenRTX make use of modified source code from the MMDVM project.
The first mode I attempted to add was DSTAR, one of the first digital modes I ever used. DSTAR is an open source protocol that uses a proprietary audio codec known as AMBE developed by DVSI. Because DSTAR uses the AMBE codec I needed to use a dongle to route the encoded audio to and from the Module17 board. To do this I adapted a piece of software called AMBEServer developed by Jonathan Naylor G4KLX. This program runs on a computer which the Module17 and AMBE dongle are connected via USB. I have the mode working fairly well. Occasionally the data transfer between the computer and the Module17 board stops. I am still looking into this problem.
Note that these modifications appear to be for the Module17 Version 1.0 Unit. Many Module17 units that were purchased assembled and tested were for an earlier version.
This is kind of the reverse of an MMDVM unit which incorporates M17 as just another digital voice mode. The Module17 implemented only M17… and KD0OSS is retrofitting it for compatibility with other digital voice modes - interesting challenge!
The primary motivation for designing and implementing Reticulum has been the current lack of reliable, functional and secure minimal-infrastructure modes of digital communication. It is my belief that it is highly desirable to create a reliable and efficient way to set up long-range digital communication networks that can securely allow exchange of information between people and machines, with no central point of authority, control, censorship or barrier to entry.
…
Goals
To be as widely usable and efficient to deploy as possible, the following goals have been used to guide the design of Reticulum:
Fully useable as open source software stack
Reticulum must be implemented with, and be able to run using only open source software. This is critical to ensuring the availability, security and transparency of the system.
Hardware layer agnosticism
Reticulum must be fully hardware agnostic, and shall be useable over a wide range of physical networking layers, such as data radios, serial lines, modems, handheld transceivers, wired Ethernet, WiFi, or anything else that can carry a digital data stream. Hardware made for dedicated Reticulum use shall be as cheap as possible and use off-the-shelf components, so it can be easily modified and replicated by anyone interested in doing so.
Very low bandwidth requirements
Reticulum should be able to function reliably over links with a transmission capacity as low as 5 bits per second.
Encryption by default
Reticulum must use strong encryption by default for all communication.
Initiator Anonymity
It must be possible to communicate over a Reticulum network without revealing any identifying information about oneself.
Unlicensed use
Reticulum shall be functional over physical communication mediums that do not require any form of license to use. Reticulum must be designed in a way, so it is usable over ISM radio frequency bands, and can provide functional long distance links in such conditions, for example by connecting a modem to a PMR or CB radio, or by using LoRa or WiFi modules.
Supplied software
In addition to the core networking stack and API, that allows a developer to build applications with Reticulum, a basic set of Reticulum-based communication tools must be implemented and released along with Reticulum itself. These shall serve both as a functional, basic communication suite, and as an example and learning resource to others wishing to build applications with Reticulum.
Ease of use
The reference implementation of Reticulum is written in Python, to make it easy to use and understand. A programmer with only basic experience should be able to use Reticulum to write networked applications.
Low cost
It shall be as cheap as possible to deploy a communication system based on Reticulum. This should be achieved by using cheap off-the-shelf hardware that potential users might already own. The cost of setting up a functioning node should be less than $100 even if all parts need to be purchased.
My thanks to my friend Steve Monsey N0FPF who follows Reticulum closely and pings me regularly about new developments. I consider Reticulum significant technological innovation in radio technology that’s immediately “adjacent” to Amateur Radio.
Reticulum is a remarkably mature and functional system that’s been evolving and improving for years. I’m constantly amazed at the excellent documentation of Reticulum, of which the above excerpt is a very small part. In fact, Reticulum’s documentation is a great example / template of the quality of documentation I hope to develop for the IP400 Network Project.
Given the current restrictions in most countries about encryption, Reticulum currently isn’t legal for use on Amateur Radio spectrum, and from my (admittedly cursory) reading, encryption is integral, not optional in Reticulum (cannot “turn it off”).
If I ever got to the point of giving up on Amateur Radio development, I’d redirect my remaining enthusiasm and energy into developing a turnkey system something like Reticulum running on LoRa on 902-928 MHz (US, Canada) or 433 MHz (Europe) license exempt bands. Or just following the efforts of someone / some group that has already done so.
- - -
Nominations Requested for Amateur Radio Technical Awards
ARRL seeks your help in honoring the outstanding work done by hams, through the ARRL Service Awards. There are a host of different awards which are divided into four categories: Education Awards, Media/Public Relations Awards, Technical Awards, and Distinguished Service Awards.
Awards include:
Hiram Percy Maxim Memorial Award
ARRL Herb S. Brier Award for Instructors and Teachers
ARRL Microwave Development Award
ARRL Technical Service Award
ARRL Technical Innovation Award
ARRL Philip J. McGan Memorial Silver Antenna Award
The Amateur Radio Software Award is seeking nominations for outstanding software developed for ham radio. Nominations should promote innovative, free, and open source projects. Submissions are being accepted until February 28th.
sBitx is, in many ways, the “zBitx 2” that I imagined
Three distinct phases of Software Defined Radio development.
I really enjoy, and appreciate all public comments in Zero Retries!
To receive new issues of Zero Retries every week via email, become a free subscriber. To support Zero Retries, paid subscriber are appreciated (but entirely optional).
See the Zero Retries Boilerplate page for significant acknowledgements and other information relevant to Zero Retries. For new readers of Zero Retries, that page, and the About Zero Retries page has useful information to check out.
My ongoing Thanks to:| Tina Stroh KD7WSF for, well, everything! Jack Stroh, Late Night Assistant Editor Emeritus Shreky Stroh, Late Night Assistant Editor In Training Annual Founding Members who generously support Zero Retries financially: Founding Member 0000 - Steven Davidson K3FZT (Renewed 2024) Founding Member 0001 - Randy Smith WU2S (Renewed 2024) Founding Member 0002 - Chris Osburn KD7DVD (Renewed 2024) Founding Member 0003 - Don Rotolo N2IRZ (Renewed 2024) Founding Member 0004 - William Arcand W1WRA (Renewed 2024) Founding Member 0006 - Todd Willey KQ4FID (Renewed 2024) Founding Member 0007 - Merik Karman VK1DF / VK2MKZ (Renewed 2024 with two Founding Member subscriptions!) Founding Member 0008 - Prefers to Remain Anonymous 14 (Renewed 2024) Founding Member 0009 - Prefers to Remain Anonymous 19 (Renewed 2025) Founding Member 0011 - Rick Prelinger W6XBE (New 2024) Founding Member 0012 - Ryan Tolboom N2BP (New 2024) Founding Member 0013 - Newton White N4EWT (New 2025)
Numerous Annual and Monthly subscribers who also generously support Zero Retries financially!
You thousands of readers of Zero Retries without which there would be little point in publishing this newsletter.
Permission for Reuse of Zero Retries Content
Blanket permission is granted for Amateur Radio use of any Steve Stroh content in Zero Retries for Amateur Radio newsletters and distribution via Amateur Radio such as (but not limited to) Packet Radio Networks, Packet Radio Bulletin Board Systems, Repeater Nets, etc. Specific blanket permission is granted to TAPR to use any Steve Stroh content in Zero Retries for the TAPR Packet Status Register (PSR) newsletter (I owe them from way back).
In such usage, please provide appropriate authorship credit for the content (especially for guest authors) and mention that it was first published in Zero Retries newsletter, preferably in this format:
This article is reprinted with permission. It was first published in Zero Retries newsletter, issue Zero Retries (number), (date) - (include full web link of the specific issue).
It’s appreciated (a courtesy, but not required) to notify Zero Retries Editor Steve Stroh N8GNJ of any reuse of Zero Retries content - stevestroh@gmail.com
If you’d like to republish an article in this issue for other uses, just ask.
All excerpts from other authors or organizations, including images, are intended to be fair use. Unless otherwise noted in the article, there are no paid promotional items in any Zero Retries articles.
Here in EU dPMR has been available for years. Besides technical problems that make me hate this technology as a ham, there is one problem, especially if you want to prepare for an emergency that hopefully will never come: dPMR handhelds are prohibitively expensive, about 10 times as expensive as simple analog PMR units.
Hi Steve, minor correction on the availability of Robust Packet. Many (most?) SCS modems support it. I have a PTC-IIex that supports it for example.
Ref "RPR Capable Modems" here:
http://robust-packet.st/
Here in EU dPMR has been available for years. Besides technical problems that make me hate this technology as a ham, there is one problem, especially if you want to prepare for an emergency that hopefully will never come: dPMR handhelds are prohibitively expensive, about 10 times as expensive as simple analog PMR units.