Zero Retries 0144
Zero Retries 0144
2024-03-22 — Thoughts on Using LoRa Systems, Why the Proposed 44Net VPN Service is Significant
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. Now in its third year of publication, with 1400+ subscribers.
About Zero Retries
Steve Stroh N8GNJ, Editor
Jack Stroh, Late Night Assistant Editor Emeritus
In this issue:
Web version of this issue - https://www.zeroretries.org/p/zero-retries-0144
Request To Send
Commentary by Editor Steve Stroh N8GNJ
Paid Subscribers Update
My thanks to John Kiernan KE2UN for becoming a Paid Subscriber to Zero Retries this past week!
Financial support is a real vote of confidence for continuing to publish Zero Retries.
Welcome Back to Zero Retries - Don Rotolo N2IRZ
One of my favorite Zero Retries Interesting authors, Don Rotolo N2IRZ, has provided us with another great Zero Retries Interesting article in this issue. I’m glad that N2IRZ’s excellent writing is now publicly accessible here in Zero Retries. In his article, N2IRZ answered a nagging question I’ve had about LoRa… just how comparable is it to packet radio? N2IRZ’s article does a good job of answering that question.
Sometimes, Standing By is the Only Option
There are a number of things I’m trying to keep track of that, frustratingly, seem to be in limbo at the moment:
The ultimate status of CQ Magazine / CQ Communications. All we know is that the website is offline, emails are not being answered, and no one is saying anything about the ultimate fate of CQ. You’d think there would be some “official” word by now, even if it’s just “we’re done; put in your bid for the assets at auctions-r-us.com/cq”.
Whether we’ll see the new MMDVM-TNC data mode become a reality. Through the end of 2023 there was steady progress being made on MMDVM-TNC. Then things went quiet. I still have high hopes for MMDVM-TNC; if it does become a reality would enable conventional FM repeaters to add not just digital voice modes, but a 9600 (and perhaps 19200) bps data mode with integral Forward Error Correction (FEC).
The FCC has yet to announce their decision whether they will delete or otherwise modify the current bandwidth limits on the US Amateur Radio VHF / UHF bands, as recommended by a majority of the commenters and the ARRL.
ARDC has yet to formally announce their 44Net VPN service to allow the easy use of 44Net IPv4 addresses for Amateur Radio and (carefully controlled other) uses.
Knowing more about the “big picture” of what APRS Foundation intends to adopt as their mission and goals for the evolution of APRS. It seems odd that there have been several emails on various APRS lists, but the APRS Foundation website continues to be bare-bones, with none of the context from the emails. I hope that APRS Foundation is able to realize its potential, but not having any significant content on their official website is worrying.
Hoping for some “big reveals” of new Amateur Radio products at Hamvention 2024. If there are going to be new products for Amateur Radio in 2024, it’s likeliest that they’ll be unveiled at Hamvention 2024 to get the biggest public relations “splash” possible.
Waiting for the next installments of KE9V’s excellent serial The Zombie Apocalypse. KE9V has published eight episodes so far and as soon as I see a new one on my RSS feed, it’s a “read it right now” priority.
I know… patience… patience…
In The Meantime…
I’ll be enjoying the snippets that are popping up about the presentations from this weekend’s HamSCI Workshop 2024. HamSCI and this conference is a fantastic example of science and technological innovation occurring in, and adjacent to Amateur Radio.
I’ll be enjoying the quiet and fresh air of rural Whatcom County, Washington after a week in Downtown Portland, Oregon. Hopefully I’ll be able to enjoy some sunny, warm days this coming week where I can open the big shop doors of N8GNJ Labs and let some fresh air in. I’m solar powered, and it’s finally shorts-only season again now that the temps are consistently in the 50s and above,
I’ll be staring at and contemplating next steps about what to do about the permanently bent middle ten foot section of my thirty foot antenna mast attached to N8GNJ Labs that apparently wasn’t up to dealing with the “Whatcom Winds”. It’s now bent at a comical angle, to the point the neighbors comment on it.
I’ll be sorting out a few new treasures recently acquired at the recent big electronics flea market in the Seattle area, including a pair of Coastal ChipWorks TNC-X units that I had always wanted, but never quite got around to buying before Coastal ChipWorks went out of business.
I’ll be boxing up a donation of vintage Color Computer ephemera for shipment to the The 32nd Annual “Last” Chicago CoCoFEST!,
I’ll be boxing up my next batch of Amateur Radio / wireless industry / communications material to be donated to the Digital Library of Amateur Radio & Communications, and…
Most urgently, I’ll be working on my upcoming book The Zero Retries Guide to Amateur Radio in the 21st Century. If weather permits, I’ll be working on it with the laptop in the fresh air and the stimulation of all the cool stuff waiting for me to tackle in N8GNJ Labs.
Have a great week folks, and thanks for being Zero Retries readers and subscribers!
73,
Steve N8GNJ
Thoughts on Using LoRa Systems
By Don Rotolo N2IRZ
LoRa radios were tested on an AX.25 packet link by timing a text file transfer. The fastest settings delivered about half the speed of a 1200 baud AX.25 wired link, with a relatively high error rate. LoRa radios are marginally useful for AX.25 networks, and then only in exceptional circumstances.
Over several weeks, I evaluated the “LoRa Radio Bonnet with OLED – RFM95W” at 915 MHz (33 cm band) ($32.50 from Adafruit) for performance and range for possible use in an AX.25 Packet network. These were paired with Raspberry Pi Pico W boards for ease of implementation, and operated under Part 15 (unlicensed spectrum).
In choosing this experiment, the big attractions were low cost, simple implementation and the use of a frequency band that is relatively unused, an advantage at sites where 2 meters and 70 cm are already heavily used and prone to self-interference. A big disadvantage of the 33 cm band is that feedline losses are huge, meaning the radio needs to be very close to the antenna.
A TARPN network (tarpn.net) set up on the bench was used for all testing. The particular LoRa/Pi implementation used relies on 802.11 Wi-Fi for connectivity between the TARPN Node and the Raspberry Pi Pico W, attached to and controlling the LoRa radio. In theory, a USB link between the Pi and TARPN node could be made to work, and this was attempted, but it was abandoned after a few attempts. Assuming sufficient Wi-Fi range, it is possible to place the LoRa radio at the antenna, with some weather protection.
The OLED included with the LoRa radio board was implemented to display operational status and some basic information. Logging to a text file on the Pi Pico was used extensively to determine timing and signal status (RSSI, S/N ratio, Frequency error, and payload size). For each LoRa radio, a simple ground plane antenna was constructed, using 0.141” hardline and a 4-wire groundplane at a 45 degree angle from the radiator. These were placed around 40 feet apart during testing, passing through three residential sheetrock walls. It was assumed that feedline losses were zero. An inexpensive adapter (from Adafruit) was used between the LoRa board and the antenna’s SMA connector.
During testing, signals varied but were generally displayed in the range of -60 to -80 dBm, with a displayed S/N ratio from +9 to 12 dB. Frequency errors of several kHz were commonly seen, which was reduced somewhat by setting one transceiver frequency 3 kHz above the other.
The Adafruit specs claim up to 100 mW (+20 dBm) output power, but in the implementation used any setting above 15 dBm (31.6 mW) seemed to reduce the power to +5 dBm, likely a default. The specs also claim a range of up to 20 km with good antennas and line of sight. Data and error rates for this range are not mentioned.
Testing was performed at +15 dBm output to the antenna, except as noted. Although loop yagis were constructed for eventual large-distance testing, these were never used, since performance was poor even at close range.
Data rate (speed) and error rate (robustness) are said to be inversely proportional. The widest bandwidth (500 kHz) is fastest but least robust, and the slowest (and most robust) practical bandwidth is 62.5 kHz – any narrower and frequency drift becomes significant enough to disrupt communications. The Spreading Factor (SF) also affects speed and robustness. Supposedly this can vary between 5 (fastest, least robust) and 12 (slowest, most robust), but in the implementation used, 7 was the lowest factor that functioned. Another factor is the Coding Rate, which can be set between 5 (fastest) and 8 (most robust), meaning that between 5/4 and 8/4 of the data is sent redundantly. The Coding Rate remained constant at 5 during testing.
The TARPN Stresstest (and not “Linktest”) is a semi-automated function that causes a node to connect to a neighbor node, then connect back to itself, creating a loop path. Once the path is established, a standard text file of about 10 kB (100 lines of 100 characters each) is sent through the loop, and the time for completion is recorded. This test exercises real-world concerns such as collisions, wait time and packet loss. A shorter time indicates better overall link performance. For each of the three bandwidths, the test was repeated “n” times, and both ends were used to initiate the stresstest more or less an equal number of times. For the 250 kHz and 500 kHz BW tests, the error rate (as reported by the G8BPQ “R R” command after resetting the link statistics) was also recorded.
Testing at 62.5 kHz bandwidth with SF=7 yielded an average data rate of about 25.1 Bytes/sec (B/s). (n=7) (power was +5 dBm).
Testing at 125 kHz with SF=7 yielded an average rate of 25.8 B/s (n=5).
Testing at 250 kHz with SF=7 yielded an average rate of 17.8 B/s (n=9) Error rate=12%.
Testing at 250 kHz with SF=12 yielded an average rate of 13.25 B/s (n=3) Error rate=4%.
Testing at 500 kHz with SF=7 (fastest rate possible) transferred just under 26 B/s (n=5) Error rate=7%. Note that this is not much different from the 62.5 kHz result.
For comparison, a 1200 baud AX.25 link over wire delivers around 51 B/s, and a 9k6 link on 70 cm (Tait 8105) averages 124 B/s. Indeed, even at 125 kHz and SF=7, the LoRa data rate was just over 25 B/s, remarkable steady despite different bandwidths. In one single test, the very fastest data rate of 29.27 B/s was at 62.5 kHz, SF=7, and a mere +5 dBm.
The spreading factor definitely influenced robustness, at the expense of speed. Power did not seem to be a factor in the test conditions, but likely has an influence upon more challenging RF paths. Errors were significant in that the lowest error rate of 4% was never improved upon.
While it should be considered that the experimental techniques and setup could be flawed, leading to poorer performance than should be expected, several variations of physical test setup were tried (but not exhaustively) that appeared to disprove this idea. It should be noted that at distances of several inches, performance was noticeably worse than at distances of a few feet, perhaps due to near field effects.
For a link measured in thousands of feet, even with substantial antennas and maximum power, the data rate is expected to need to be slowed considerably to realize an acceptable error rate. The effect of amplification was not explored, since even at good signal strengths and S/N ratios, performance remained mediocre. If data rates well below 600 Baud are acceptable, at distances often referred to as “shouting distance”, these radios may have some value, particularly because LoRa uses spread-spectrum that is lightly populated, moderately interference-resistant and signals can be encoded or encrypted on the non-Amateur segment of the 33 cm band. But in a practical sense, there is very little need for such links.
Contact me if the software package that was for this test implementation is desired, as it was customized and is unavailable elsewhere. This software is an adaptation of work done by Vance Vagell KV4P, which itself is a fork of a project by Alfredo Vania IZ7BOJ on Github.
Why the Proposed 44Net VPN Service is Significant
By Steve Stroh N8GNJ
ARDC has hinted… teased… that they are close to offering a “44Net Virtual Private Network (VPN) service” for use by Amateur Radio Operators in the near future. Frustratingly, the closest thing to a mention of the 44Net VPN on ARDC’s website is a photo of a portable (cellular) router in ARDC’s February 2024 newsletter in the section TAC Update. I hope that ARDC does a better job of explaining the 44Net VPN service in the near future.
From https://www.ardc.net/44net/:
44Net is shorthand for Internet network 44 (44.0.0.0/9, 44.128.0.0/10), also known as AMPRNet. Since its allocation to amateur radio in the mid-1980s, the network has been used by amateur radio operators to conduct scientific research and to experiment with digital communications over radio. The goals are to of advance the state of the art of Amateur Radio networking, and to educate amateur radio operators in these techniques.
Currently, the only “easy” way to get connected to other 44Net users is for someone in your area to have established (and maintain) a 44Net gateway that will route your 44Net traffic from your 44Net IP address, to and from other 44Net users and / or the Internet.
If such a gateway doesn’t exist in your area, your only option is to create your own gateway. From my understanding, this requires setting up a Linux “instance” (virtual Linux computer) at a hosting company and invoking a long, meticulous, exacting series of incantations to establish your 44Net routing. You’ve go to do everything right, or it doesn’t work at all, or worse, it screws things up, not just for you, but perhaps your hosting company, and maybe even your fellow 44Net users. Plus you have all the overhead and hassle factor of keeping a Linux system up to date, secured, patched, and monitored to ward off the ceaseless attacks on any system “exposed on the Internet”.
Fortunately for us networking mortals who generally just use the Internet, but want to experiment at least a little bit with 44Net IPv4, there’s now a possibility that we don’t have to master the necessary incantations (and expenses) of a Linux “instance” and maybe we’ll just be able to buy a small box, download a script from 44Net, and be able to route our IPv4 44Net packets directly from our existing personal Internet connectivity with a minimum of hassle and no expense.
Why is this (future) capability significant? Basically, because experimenting with Internet for a casual experimenter like me is a “there be dragons” experience if you try to open up your personal Internet system to experiment. You’ll be descended upon by extremely hostile and aggressive and guaranteed harmful bots constantly on the lookout for a chink in your Internet armor. Doing so is the equivalent of leaving your front door ajar or your car unlocked in a bad neighborhood - just not a good idea.
My example use case for making a block of my (assigned) 44Net IPv4 addresses accessible to fellow 44Net (Amateur Radio) users is that I’m planning to set up a test lab consisting of Amateur Radio radios, modems, and computers to test interoperability between various radios and modems. My hope is that I can grant access to others to access these systems so they can run their own tests such as new modem software, new protocols, etc. in an existing lab setup without having to undergo the expense of buying their own radios and modems to do such testing. Theoretically, they can just “shell into” the Raspberry Pi system that is connected to a Kenwood TM-V71A connected to a AEA PK-96 9600 bps TNC, to test compatibility with another 9600 bps system in my test lab.
Yes, I could do this with regular Internet, but where’s the fun in that? If I was interested strictly in utilitarian communications, I wouldn’t be experimenting with Amateur Radio.
Another use case is that Starlink users like me are severely challenged about anything using IPv4 “incoming” via our Starlink systems. When I had my Comcast cable modem, I was granted temporary use of a (Comcast-owned) IPv4 address that was reasonably stable (for a consumer Internet system). But Starlink uses a much more complicated system for assigning IPv4 addresses to its customers called Carrier Grade Network Address Translation (CGNAT), which makes it all but impossible for an incoming IPv4 connection to my Starlink system.
But if the 44Net VPN becomes a reality, I will have a small router on my internal network that will route my 44Net address block out to a 44Net VPN server. Once I’m connected to the 44Net VPN server, I can exchange 44Net IPv4 packets there with other 44Net users / addresses easily.
Another use case for a 44Net VPN service is that currently AREDN nodes can use a “tunnel server” via Internet if they don’t have connectivity via radio - basically a simpler version of a VPN. But an AREDN tunnel server can only use a static IPv4 address… with incoming ports enabled… cue scary music. But if the 44Net VPN service does become available, AREDN tunnel servers could be operated “inside” the 44Net VPN service, with much less hassle and more security.
Another use case could be that repeaters and remote radio stations that are linked via Internet can get (static, routable) 44Net IPv4 addresses instead of needing to rent a static IPv4 address from their Internet provider.
I hope that the 44Net VPN service becomes a reality in 2024.
ZR > BEACON
By Steve Stroh N8GNJ
Short mentions of Zero Retries Interesting items.
Modern Introduction to Packet Radio - APRS BBS TCP/IP AX25 and NPR
This is the first video in a playlist intended to address the wide disbursement of packet radio knowledge.
This video covers the concept of packet radio it's history, APRS, BBS (bulletin board systems), TNC's like direwolf, and TCP/IP over packet radio. After this you will have a good foundation on the current state of packet radio in the ham or amateur radio community. Next we will talk about the most popular software TNC, direwolf, and set it up for future videos.
You can see a short write up of this video, as well as download the presentation form my website at: https://themodernham.com/modern-introduction-to-packet-radio-ax25-aprs-and-tcp-ip/.
I’m a fan of the Modern Ham YouTube channel by Billy Penney KN4MKB, to the point that it’s mentioned in the “boilerplate” near the end of every issue of Zero Retries.
This video is the first of a planned series of videos on this subject. Kudos that KN4MKB is going to tackle “advanced” aspects of Amateur Radio Packet Radio such as TCP/IP over Packet Radio, and use of New Packet Radio.
KN4MKB makes a valid point that most of the information available on the web about packet radio is archival, and not easily digestible. I’ll also observe that such descriptions don’t incorporate modern implementations of Amateur Radio Packet Radio technology for easy comparison, such as (to cite two random examples) the RPC Electronics SMT TARPN NinoTNC and the Mobilinkd TNC4. If you watch the first few minutes of the video, KN4MKB makes a pretty convincing case for “we need something better”. I agree wholeheartedly - my answer to that issue is my future book The Zero Retries Guide to Amateur Radio in the 21st Century.
I know that I may sound “old” and condescending in saying this… but it’s fascinating and instructive to me to see KN4MKB tackle this subject with the fresh perspective of someone of his generation, developing a presentation of the subject for his generation. I’m very much looking forward to a careful viewing of this and future videos in this series.
TAPR Packet Status Register (PSR) Newsletter #157
Spring 2024 - now available for viewing / download (PDF).
Fifty Things You Can Do with a Software Defined Radio
It’s like an invisible world that always surrounds us, and allows us to do many amazing things: It’s how radio and TV are transmitted, it’s how we communicate using Wi-Fi or our phones. And there are many more things to discover there, from all over the world.
In this post, I’ll show you fifty things you can find there – all you need is this simple USB dongle and an antenna kit!
A couple of years ago, I heard about the “Make 50 of Something” technique in Vi Hart’s Fifty Fizzbuzzes. Since then, I’ve already made fifty programs for the fantasy console TIC-80 in one weekend in 2021.
I found that a very exciting experience – trying to make so many new things really pushed me to leave my comfort zone, to be creative, and not to get sucked into rabbit holes too deep.
I knew I definitely wanted to try the technique again. So, when I took a week of vacation, I decided to try to find 50 things to do with a Software Defined Radio!
…
The software I liked best, and which I used for many things, was SDR++. It allows you to explore the frequency spectrum very smoothly, and has a modern user interface!
This article was a great treatment of some of the myriad things that are possible to explore about radio technology with an inexpensive Software Defined Receiver (thus, no Amateur Radio license required), some open source software, and some curiosity and ingenuity. I particularly enjoyed
46: Receive navigational aids for airplanes
CATS Gets Reviewed by Hackaday
CATS (Communication And Telemetry System) got a nice writeup on Hackaday - CATS: A New Communication And Telemetry System.
CATS is a new communication and telemetry standard intended to surpass the current Automatic Packet Reporting System (APRS) standard by leveraging modern, super-cheap Frequency Shift Keying (FSK) transceivers rather than standard FM units. The project is in the early stages, but as of this writing, there is a full open source software stack and reference hardware for both Raspberry Pi-based gateway devices and an STM32-based mobile device.
From a radio perspective, CATS uses raw FSK rather than the inefficient AFSK used by APRS. A real killer for channel utilization is the PTT time; this is the dead time around a packet APRS requires for ‘keying up’ and ‘keying down.’ The CATS standard is aggressive with PTT timing, enabling the channel to get going on sending the data sooner.
I’m impressed by CATS, which I discussed in Zero Retries 0129 - Communication And Telemetry System (CATS) - Rethinking APRS Paradigms.
I’m glad Hackaday is continuing to mention new Amateur Radio systems / ideas such as CATS to their Maker / Hacker / Techie audience… we (progressive / technical / data-centric Amateur Radio) need to offer more technical and interesting projects like that.
Digirig Mobile Lite
From my perspective, the Digirig Mobile (see below) is about as basic, functional, and physically compact… elegant… as one could want from an audio interface intended for use with portable, “backpack”, and mobile radio units. It’s really an elegant implementation of an audio interface for Amateur Radio applications that use audio interfaces, and I look forward to having one or two Digirig Mobile units for my use eventually (but that’s considerably behind my backlog of projects for N8GNJ Labs).
But apparently there’s a market for an even more basic and physically compact version of Digirig - the Digirig Mobile Lite.
On his KM4ACK YouTube channel, Jason Oleham KM4ACK offered a preview of the prototype of the Digirig Mobile Lite:
As I understand it, other than the form factor, the primary difference is that the Lite does not incorporate a serial port for CAT control - the single jack is for audio.
Seeing how small this could be, it would be really cool if one of these could get incorporated into a basic, generic portable FM radio, with only a USB-C jack needed to connect with the host computer. It would be very cool to have just a combination of a portable radio cabled to a smartphone, being able to run the entire range of Amateur Radio software that uses audio interfaces.
Kudos to Denis Grisak K0TX for creating Digirig mobile, and now Digirig Mobile Lite.
Beginnings of Multicast Service Discovery for ka9q-radio
Phil Karn KA9Q on the ka9q-radio mailing list:
It has long been my plan to use the "zeroconf" (Zero Configuration) protocols to simplify ka9q-radio configuration as much as possible. These are the same protocols you use when, for example, you choose a printer on your LAN.
The idea is to alleviate having to remember DNS names (e.g., hf-receiver.local, hf-pcm.local) when starting the interactive programs like 'control' and 'monitor'. Several components of ka9q-radio have advertised their services for some time, but until now nothing has actually used them.
As a first step, if you don't specify the command/status for an instance of radiod, the 'control' program will now browse the network and give you a list to choose from. E.g., on my home network:
Scanning for radiod instances...
0: 70cm vertical @ KA9Q (70cm.local)
1: discone @ KA9Q (125cm.local)
2: g5rv @ KA9Q (hf.local)
3: 2m vertical @ KA9Q (2m.local)
Select index: 2If there's only one instance of radiod out there (an important special case), it'll automatically pick it without asking.
The URL will only work if you’re a subscribed member of this list.
Feedback Loop
In the comments of Zero Retries 0143, Franco Venturi K4VZ and I exchanged our respective views about whether publicly documented systems versus systems that are not publicly documented systems were appropriate for use in Amateur Radio. It was a stimulating back and forth; exactly the kind of dialog I was hoping for with Zero Retries. Thank you K4VZ!
Join the Fun on Amateur Radio
If you’re not yet licensed as an Amateur Radio Operator, and would like to join the fun by literally having a license to experiment with radio technology, check out
Join the Fun on Amateur Radio for some pointers.
Zero Retries Frequently Asked Questions (FAQs) — In development 2023-02.
Closing the Channel
In its mission to highlight technological innovation in Amateur Radio, promote Amateur Radio to techies as a literal license to experiment with radio technology, and make Amateur Radio more relevant to society in the 2020s and beyond, Zero Retries is published via email and web, and is available to everyone at no cost. Zero Retries is proud not to participate in the Amateur Radio Publishing Industrial Complex, which hides Amateur Radio content behind paywalls.
My ongoing Thanks to:
Tina Stroh KD7WSF for, well, everything!
Founding Members who generously support Zero Retries financially:
Founding Member 0000 - Steven Davidson K3FZT
Founding Member 0001 - Prefers to Remain Anonymous 01Founding Member 0002 - Chris Osburn KD7DVD
Founding Member 0003 - Don Rotolo N2IRZ
Founding Member 0004 - William Arcand W1WRA
Founding Member 0005 - Ben Kuhn KU0HN
Founding Member 0006 - Todd Willey KQ4FID
Founding Member 0007 - Merik Karman VK2MKZ
Founding Member 0008 - Prefers to Remain Anonymous 14
Founding Member 0009 - Prefers to Remain Anonymous 19Numerous Annual and Monthly subscribers who also generously support Zero Retries financially!
Want to Support Zero Retries?
The most effective way to support Zero Retries is to simply mention Zero Retries to your co-conspirators that are also interested in knowing more about technological innovation that is occurring in Amateur Radio and encourage them to become a fellow subscriber.
One particularly effective method of promoting Zero Retries is to add a mention of Zero Retries to your QRZ page (or other web presence) and include a link:
If you’d like to financially support Zero Retries, becoming a paid subscriber is greatly appreciated and helps offset expenses incurred in publishing Zero Retries. Paid subscriptions for Zero Retries are entirely optional, as explained in this special issue of ZR:
Zero Retries Administrivia - Activating Payment Options.
These blogs and newsletters regularly feature Zero Retries Interesting content:
Dan Romanchik KB6NU mentions “Zero Retries Interesting” topics so regularly on his blog (that I otherwise wouldn’t know about) that I’ve bestowed on him the honorific of Pseudostaffer.
Jeff Davis KE9V also mentions “Zero Retries Interesting” topics so regularly on his blog (that I otherwise wouldn’t know about) that I’ve bestowed on him the honorific of Pseudostaffer.
Amateur Radio Weekly by Cale Mooth K4HCK is a weekly anthology of links to interesting Amateur Radio stories.
Experimental Radio News by Bennet Z. Kobb AK4AV discusses (in detail) Experimental (Part 5) licenses issued by the US FCC. It’s a must-read-now for me!
RTL-SDR Blog - Excellent coverage of Software Defined Radio units.
TAPR Packet Status Register has been published continuously since 1982.
Other Substack Amateur Radio newsletters recommended by Zero Retries.
These YouTube channels regularly feature Zero Retries Interesting content:
HB9BLA Wireless by Andreas Spiess HB9BLA
KM6LYW Radio by Craig Lamparter KM6LYW (home of the DigiPi project)
Modern Ham by Billy Penley KN4MKB
Tech Minds by Matthew Miller M0DQW
Zero Retries is currently using the Substack email publishing platform to publish Zero Retries. It’s particularly suitable for small newsletters as you can get started for no cost.
If you’re reading this issue on the web and you’d like to see Zero Retries in your email Inbox every Friday afternoon, just click below to join 1400+ other subscribers:
Please tell your co-conspirators about Zero Retries — just click:
Offering feedback or comments for Zero Retries is equally easy — just click:
If you’re a fellow smart person that uses RSS, there is an RSS feed for Zero Retries.
Social Media:
Zero Retries (N8GNJ) is on Mastodon — n8gnj@mastodon.radio — just click:
Zero Retries (N8GNJ) is also on Bluesky — @n8gnj — just click:
Email issues of Zero Retries are “instrumented” by Substack to gather basic statistics about opens, clicking links, etc.
More bits from Steve Stroh N8GNJ:
SuperPacket blog — Discussing new generations of Amateur Radio Data Communications — beyond Packet Radio (a precursor to Zero Retries)
N8GNJ blog — Amateur Radio Station N8GNJ and the mad science experiments at N8GNJ Labs — Bellingham, Washington, USA
Thanks for reading!
Steve Stroh N8GNJ / WRPS598 (He / Him / His)
These bits were handcrafted (by a mere human, not an Artificial Intelligence bot) in beautiful Bellingham (The City of Subdued Excitement), Washington, USA, and linked to the Internet via Starlink Satellite Internet Access.
2024-03-22
Blanket permission is granted for TAPR to use any Steve Stroh content in Zero Retries for the TAPR Packet Status Register (PSR) newsletter (I owe them from way back).
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.
In such usage, please provide appropriate authorship credit for the content.
If you’d like to reuse 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.
Portions Copyright © 2021, 2022, 2023, and 2024 by Steven K. Stroh.
I am eagerly awaiting the AMPRNET VPN as well. There is actually a current method of 44net routing that doesn't involve a local gateway. You can create an IPIP tunnel to the AMPRNET gateway server at the University of California San Diego (AMPRGW) for access to the internet, and you can create a "mesh" of other tunnels for direct connection to other AMPRNET users To be blunt, this system kinda sucks. IPIP isn't supported by every firewall vendor. It needs ports opened for inbound connections (a VPN could be configured for all outbound connections) and this requires a public IPv4 address with no CG-NAT like starlink. Latency and throughput through the AMPRGw is pretty awful.
Our local club has all but stalled out on a repeater linking project partially due to these AMPRNET limitations. We have tried spinning up our own gateway on a VPS (like you mentioned) but our local coordinator has been so slow in responding to emails and requests that our tickets automatically age out before we can get the BGP allocation. We have the skills and experience needed to run the gateway, we just cannot seem to get the allocation. OK, rant done. Sorry and 73. Ben
Regarding CQ Magazine, Wikipedia is now using past tense when referring to the publication. Maybe that's our official unofficial word.