Zero Retries 0164

2024-08-09 - SunSpotWatch.com Imminent Server Failure - Donations Requested, Why M17 Is Significant - Part 2, Starlink Mini - Game, Set, Match for Emergency Communications

Zero Retries 0164

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 fourth year of publication, with 1900+ subscribers. Radios are computers - with antennas!

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-0164

Request To Send

Commentary by Editor Steve Stroh N8GNJ

My thanks to Prefers to Remain Anonymous 09 for renewing as an Annual Paid Subscriber to Zero Retries this past week!

Financial support is a real vote of confidence for continuing to publish Zero Retries.


Major Conference Countdowns

  • JARL Ham Fair 2024 in Tokyo, Japan on 2024-08-24 and 25, in 2 weeks!
  • Pacificon 2024 in San Ramon, California, USA on 2024-10-18 thru 20 in 10 weeks. Tina KD7WSF and I plan to attend Pacificon 2024 (which makes it “major” to us). I have offered to do a presentation about Technological Innovation in Amateur Radio, and (I think) my proposal has been accepted.

See the Zero Retries Guide to Zero Retries Interesting Events for additional events.


Seattle Fleet Week 2024 - The USS Sampson (DDG 102)

Steve Stroh N8GNJ - USS Sampson in background - Seattle Fleet Week 2024

Last week was Fleet Week 2024 in Seattle, Washington and the “star” ship available for civilian tours was the US Navy’s USS Sampson - DDG 102. The Sampson is a Arleigh Burke class destroyer, one of the “Flight IIa” variants of the Arleigh Burke destroyers, commissioned in 2007. I’d been curious about these very high tech ships since watching the television series The Last Ship, which was a set on a fictionalized1 Arleigh Burke class destroyer, the “Nathan James - DDG-151”.

The Sampson’s current home port is Naval Station Everett (Washington), just North of Seattle, so this was a neighborly visit by the crew of the Sampson.

We civilians (including a group from several Asian countries) didn’t see much on our guided tour of the Sampson, but what I saw is that the Sampson just radiates power and is built for deadly purpose when that is necessary. You can’t help but viscerally understand this when you see the primary weapons systems up close - the missile launch tubes, the 5 inch main gun (range of 13 nautical miles), and the Close In Weapons System (CIWS) “Phalanx” 20mm rotary cannon.

We didn’t get to see the helicopters that are another weapons system included in the Arleigh Burke destroyers… but you get the point of the deadliness of the helicopters when you’re told that their primary mission is to find and kill submarines. Not to mention there are lots of hard points for machine guns all over the superstructure if it ever comes to close-in battle.

Per Wikipedia, there are 73 Arleigh Burke destroyers in service, with 19 more under construction or planned. I was impressed with this one ship!

Despite the crew’s welcoming and “aw, shucks, it’s our job” mannerisms, I came away knowing, viscerally, that the Sampson and her crew are highly efficient at their assigned missions and tasks. Such ships cannot exist without a strong sense of mission and purpose by the entire crew and the infrastructure (and traditions) that support them.

I was in awe of getting close to those huge phased array Aegis / AN/SPY-1 RADAR antennas. While on the main deck, I couldn’t help noticing that the superstructure is literally covered with all manner of antennas - conventional rotating RADARs (including a couple that would look appropriate on a pleasure boat), radomes of all sizes for satellite communications, many whip antennas of various lengths, and a few unique shapes of which I could not guess the purpose or band they were designed for. It seems obvious that the electronic techs onboard the Sampson are kept busy keeping all the electronics operational.

Military Sealift Command Communications Jobs

After touring the Sampson, we browsed a few exhibit tables where I learned that most Navy ships are replenished at sea (or can be) by ships of the Military Sealift Command (MSC). These “floating warehouses and refueling tankers” are US Navy ships, but are crewed by US civilians, with a few US Navy officers. In a brief conversation with the MSC representatives, they emphasized there are lots of jobs available within Military Sealift Command, including lots of positions for communications specialists including these positions and average salaries / hiring bonuses on the website:

  • Ship Communications Officer - $129,871
  • Ship Communications Officer - $157,409
  • Chief Radio Electronics Technician - $120,244 + $36,161 Bonus
  • Chief Radio Electronics Technician - Mixed Work Schedule - $72,321
  • Chief Radio Electronics Technician - $123,663 + $39,230 Bonus
  • Chief Radio Electronics Technician - Mixed Work Schedule - $78,460
  • First Radio Electronics Technician - $107,496
  • First Radio Electronics Technician - $123,663 + $36,004 Bonus
  • Second Radio Electronics Technician - $75,762
  • Radio Electronics Technician Advancement Program - $55,095 - $64,049

From my personal experience, one of the primary attractions of choosing to work at sea for a few years when I first graduated from Electronics Technician training was that it’s hard to spend your paycheck while you’re at sea. I had my paychecks sent home for my Dad to bank and invest2. If I were young, talented, technically curious, single, with a bit of wanderlust, in this era I’d be tempted by these jobs. I can’t imagine that an Amateur Radio license would be an extra qualification.

Starshield Is Being Deployed

Lastly, on one of the ships docked for Fleet Week, when I mentioned that I was an Amateur Radio Operator, and interested in all the antennas, I was told, quietly, that military ships are already being equipped with antennas for the brand new Starshield broadband communications system. I was surprised that Starshield equipment is being deployed so quickly (for military systems). Starshield was only formally announced in December 2022… but apparently has been quietly under development years earlier than that. The demand for broadband communications, especially secure broadband communications, within the US military, is voracious.

Thank you for your service and sacrifices, crew of the USS Sampson!


Many Independent M17 Projects Demonstrates Energy and Excitement

One of the most subtle aspects of my ongoing study of M17 so that I want write about it in Zero Retries is just how many individual projects involving M17 have been undertaken and completed… and that most were done independently. That is a demonstration of the strength of the open source development model, that all of these various aspects of M17 are now available. Just one example is that I had no idea how many repeaters around the world are “M17 capable” - a lot of them!

What I didn’t understand until recently is how much energy there is within the M17 community! Folks are excited about M17, mostly because it’s entirely open source! The last time I saw such excitement and energy for a VHF / UHF technology was the debut of D-Star, and before that, the TNC-2 era of Packet Radio. In contrast, I haven’t seen anyone energized in the same way about Digital Mobile Radio (DMR) or System Fusion (SF). My sense is that those two systems, and now D-Star, are considered pretty utilitarian - they work, they’re reliable, they’re proven… but not much excitement any more. That’s definitely not the case for those who are actively involved in M17. You really don’t understand this… feel it… experience it… until you really start digging into M17 as I have now done, and Ira Brodsky KC9TC learned from writing his recent article for RSGB RadCom - The M17 project (see below for details).


Zero Retries Overfloweth Yet Again…

Substack Editor banner: Post too long for email… it is to laugh 😆 <click off>

I’ve been pouring text and verbiage into this issue for days now, completely blowing beyond the “quick read” that an email newsletter is intended to be. If you’re (beginning to) read this as an email, I suggest saving yourself some grief and scroll up a bit and click on the web version link just under the contents outline to view the entire issue in a web browser.

In the meantime, I’ll be enjoying the waning weeks of Summer and bright sunshine here in the Pacific Northwet with the roll up doors to N8GNJ Labs wide open, fretting that I still haven’t repaired the wind-damaged antenna pole, working on my HamWAN connection, and hoping the smoke from regional wildfires doesn’t get too obnoxious for working outdoors.

73,

Steve N8GNJ


Image courtesy of SunSpotWatch.com

SunSpotWatch.com Imminent Server Failure - Donations Requested

By Tomas Hood NW7US

Editor’s Note - This article originally appeared on Facebook’s Space Weather + Ham Radio Resources on 2024-08-28. SunSpotWatch is one of many independent services that helps make Amateur Radio such an engaging activity, provided by individuals at their expense and considerable time and effort. These kind of unexpected, major expenses can be existential issues to continuing such services, thus I decided to run this appeal as an article in Zero Retries.

Urgent: Your Help Is Critical!

Reason: Imminent Server Hardware Failure (28 July 2024)

I need your help. As a patron of this page and of our website and related resources of SunSpotWatch dot com, you can directly help keep the service and resources up and running. Time is of the essence, though.

Background:

This page is the Facebook home for the main website, SunSpotWatch dot com. SunSpotWatch dot com is a public, non-commercial educational resource for amateur radio hobbyists, pigeon racers, military users, and other people interested in space weather and the propagation of radio waves in the shortwave spectrum. There are other resources, also tied to this.

The Issue:

The website lives on a server that has been running for years. The server that stores, and presents to the public, the SunSpotWatch dot com website, as well as all related resources (the space weather RSS feed, the live update automation to X, Facebook, and other social media sites, as well as other hobby websites like OliviaDigitalMode dot org), is failing. If the server fails completely, before we have a solution for this problem, all of that public resource will go dark.

The IT staff at the co-location server farm is mandating that we migrate our failing server data to a new server that has full redundancy, automated backups, and better resources. Right now, the IT staff must restart the server nearly daily to keep it alive because the hardware is failing. This failure is hardware and not storage.

The old server is NOT repairable. I must move everything to a new server ASAP, hopefully this last weekend of July.

Here's the issue: the costs of provisioning the new server, as well as necessary IT resource fees, are more than I can do on my own right now.

How You Can Help:

Please donate toward this repair and migration cost. When you donate, below, you can add a note to your donation that you wish to be listed on a "contributor highlight" page, once we are finished moving the website to the new server. Will you help out, today?

Time is of the essence! Donate through the following link:

https://sunspotwatch.com/support.html

Thank you. Your help, today, is greatly appreciated.

For those interested in a short history of this page, our group, and most importantly, our website, SunSpotWatch dot com, here is a reader's digest:

Since the inception of this FB page, years ago -- since February 22, 2010, to be exact -- it has been extremely rare that financial donations are mentioned at all. As a matter of fact, until this year, a request for donations toward the effort to keep the website, the RSS feed, the X(Twitter) feed, and other resources going with fresh information hasn't been made in many years!

Right now, The website is getting a remake - we are overhauling the website. Since the website is NOT a commercial business, this is done in spare time and at my expense. I am a senior software engineer, and an amateur radio operator who loves space weather. The whole new website is using modern technology (such as Next.Js), and will be very informative about both space weather and the propagation of shortwave radio waves.

My website was the FIRST ever non-commercial, non-governmental website on the topic, on the 'net (started in the 1990s). While our technology is sorely in need of upgrade, we have never missed a day in all these years. When I created this page, it made sense because on social media, discussion can be had. I am looking at ways to make the website somewhat interactive, as well.

Your help to move this forward by solving the failing hardware issue with a donation toward the new server, and by being a part of this page, is inspiring.

Thank you,

Tomas, NW7US

Note: I pay for the hosting, the bandwidth, etc., all out of my pocket, since starting the website in the 1990s. I do not make any money from this - it is a gift to the community (ham radio, science, and so on).


Why M17 Is Significant - Part 2

By Steve Stroh N8GNJ

This is a followup on my article in Zero Retries 0163 - Why M17 Is Significant. After this issue publishes, I’ll update that title to Why M17 Is Significant - Part 1.

While I had planned to do an eventual followup, in the days immediately afterward, I received so much good info that only a week later, there’s ample information to justify “Part 2”.

Attributions (or Lack of) - Apologies

Apologies in advance when I don’t get attributions for work done on these projects completely correct in this article. Given the nature of M17 as a “highly decentralized” project, by folks that prefer to develop rather than “document and promote”, it’s hard for a third party like me to provide accurate attributions. I do the best I can with the information I’m able to find. In an eventual, comprehensive treatment of M17 (like a book), accurate and complete attributions will have to be done.

The M17 project by Ira Brodsky KC9TC

This is an open-source digital voice standard which promotes innovation, and which should attract young 'hardware hackers' to amateur radio.

Introduction

The freedom to design, build, and experiment has always been an important part of amateur radio. As our hobby migrates to digital voice technology, that freedom may be limited by proprietary technology used to code and decode the signals. What experimenters need is an open-source digital standard, ie a standard that anyone can use without having to buy a license or pay royalties, and that anyone can extend or modify provided that they share their code with the amateur-radio community.

This was an excellent 3-page article in the May 2024 issue RSGB’s RadCom magazine. After last week’s article, a Zero Retries reader sent me photos of the article which I read eagerly. (No, I won’t share / forward - please don’t ask.)

I was impressed enough with the article that I ordered a copy of that issue for £5.95 ($7.55) from RSGB. Surprisingly, there was no additional shipping charge. The process is:

Shop > Type “RadCom” in the search box > RADCOM BACK ISSUES (Radcom & QST) > and select May. Note that RSGB only stocks the past 12 months of back issues, so if you’d like to do the same, order in time for them to have this issue in stock.

This article would be a perfect introduction to M17 if it could be made available through the M17 Project, but it is copyrighted and available only by paying RSGB. I trust that the irony is obvious that an article about an open source project, of which all of the detail is publicly available for anyone to access, worldwide… but this article is only available behind a paywall (or buying a physical magazine).

The article mentioned a number of M17 implementations that I wasn’t aware of (or just don’t remember), including:

  • The WPSD Project - WPSD is a next-generation digital voice software suite & distribution for amateur radio use, enjoyed by many thousands of hams around the globe. It is used for personal hotspots and repeaters alike. It supports M17, DMR, D-Star, Yaesu System Fusion (YSF/C4FM), P25, NXDN digital voice modes & POCSAG data/paging.

  • mvoice - M17 Digital Voice, now using FLTK - M17 Digital Voice , mvoice, is a fully functional, graphical repeater. It uses David Rowe’s Codec 2 and operates as a complete M17 repeater, only there is no RF component. It can Link to M17 reflectors and it can also do routing! It works best with a USB-based headset with microphone. mvoice uses the default pulseaudio/ALSA input and output device, so for most versions of linux, all you need to do is plug your headset in and you should be ready to go.

  • mrfed - The mrefd reflector is for connecting M17 clients together. mrefd can be configured with up to 26 different channels. M17 clients (M17 repeaters, M17 hot-spots and other MREFD reflectors) can be linked to a channel. An incoming M17 voice stream from one of the clients will be heard by all the other clients.

    Encrypted voice streams will pass through an mrefd channel, but only if they are configured for it.

  • DroidStar - This software connects to M17, Fusion (YSF/FCS, DN and VW modes are supported), DMR, P25, NXDN, D-STAR (REF/XRF/DCS) reflectors and AllStar nodes (as an IAX2 client) over UDP. It is compatible with all of the AMBE USB devices out there (ThumbDV, DVstick 30, DVSI, etc). It also supports MMDVM modems and can be used as a hotspot, or as a stand-alone transceiver via direct mode to the MMDVM device. This software is open source and uses the cross platform C++ library called Qt. It will build and run on Linux, Windows, MacOS, Android, and iOS. No USB device support for iOS though (AMBE vocoder or MMDVM). It should also build and run on any other posix platform that has Qt available (xxxBSD, Solaris, etc). This software is provided as-is and no support is available.

  • SDRPlusPlus - SDR++, The bloat-free SDR software - Features:

    • Multi VFO

    • Wide hardware support (both through SoapySDR and dedicated modules)

    • SIMD accelerated DSP

    • Cross-platform (Windows, Linux, MacOS and BSD)

    • Full waterfall update when possible. Makes browsing signals easier and more pleasant

    • Modular design (easily write your own plugins)

    • One of the “Decoders” available for compilation (not included as a default) is m17_decoder

  • OpenWebRX - OpenWebRX is an open source web-based software defined radio application that allows users to share access to one ore more SDR devices using a browser. M17 support was added in v1.0.0.

    • "Software defined radio": All processing is done in software, using digital signal processing ("DSP") technology.

    • "Web-based": Users do not need to install anything on their PC; all that's required to be able to use OpenWebRX is an HTML5 capable browser.

    • "Shared access": Multiple users can use the same receiver at the same time, and can listen to different frequencies and modes (some restrictions apply).

    • "Open source": The code for all parts of OpenWebRX is available under free and open source ("FOSS") licenses.

DroidStar is a perfect example that I have a lot more to learn about M17. Prior to reading this article, I was only aware of DroidStar as an M17 client app for Android devices. I’m delighted to see that it will also run on a MacOS… which is, for me… “Great… now another short term project to get started on”.

The article concludes with:

M17 and the future of amateur radio

In an increasingly digital and internet-connected world, it's essential that radio amateurs continue to develop their digital voice/data capabilities. An open-source standard is needed so that the entire amateur radio community, licensed operators as well as equipment manufacturers, can contribute to the process. M17 appears to be well- positioned top help make that happen.

Well stated, KC9TC… well stated!

Wikipedia - M17 (amateur radio)

Speaking of good reference material on M17… of course there is a Wikipedia article for M17… I frequently reference Wikipedia articles to elaborate on certain obscure topics (example - OFDM) that are mentioned in passing in articles in Zero Retries. But for some reason, I never thought to look up M17 in Wikipedia, but I should have. The intro there is an excellent brief description of M17:

M17 is a digital radio modulation mode developed by Wojciech Kaczmarski (amateur radio call sign SP5WWP) et al. [1][2][3][4][5][6] M17 is primarily designed for voice communications on the VHF amateur radio bands, and above. The project received a grant from the Amateur Radio Digital Communications in 2021[7] and 2022.[8] The protocol has been integrated into several hardware and software projects[citation needed]. In 2021, Kaczmarski received the ARRL Technical Innovation Award for developing an open-source digital radio communication protocol, leading to further advancements in amateur radio.[9]

Overall, this article is pretty good, but it needs some updating from folks with good knowledge of the current state of M17 (such as a number of Zero Retries readers). For example, the new CS7000 M17 radio isn’t mentioned in the Hardware Support subsection.

On the m17-users email list, I asked for volunteers to update this article. Thus, perhaps by the time this issue is published, the needed update might be complete.

M17 is Open Source, an Open Specification, Largely Software, Thus Can Be Extended

Near the conclusion of Why M17 Is Significant in Zero Retries 0163, was this subsection:

Why Does All This Matter? The Big Picture?

One of the reasons to try / adopt M17 is once there’s some real momentum, it’s all open source so it can get improved, forked, hacked, extended, transmogrified, etc. No other Amateur Radio digital voice system is as well defined as M17 (that I know of), especially the sticky (patented) digital voice chip.

Wojciech (Woj) Kaczmarski SP5WWP reminded me about the mention of the recent experimental inclusion of digital signatures (authentication) in M17.

That development nicely illustrates my point:

M17 can be improved, forked, hacked, extended, transmogrified, etc.

This development was mentioned in Zero Retries 0159 - M17 Experimental Authentication Signatures (slightly rewritten for this article).

ECDSA is Elliptic Curve Digital Signature Algorithm.

Per M17 Project on Mastodon:

Finally some good news regarding digital signatures. I've been experimenting with ST's CMOX library and just got 160-bit ECDSA to run on the Module17. It takes around 8.25 ms to sign a 16-byte M17 voice stream digest. The signature can be appended to the voice stream. The curve used is Brainpool P-160 R1, with secp256r1 signing takes a tad under 15 ms.

In the future, users might be able to generate ECDSA key pairs and use the private key for M17 stream signing. Then, by sharing the public component, allow the rest to perform identity checks. No more impersonation.



Our protocol implementation has just been updated with experimental ECDSA signature support based on the secp256r1 curve. No signature verification has been added yet.
https://github.com/M17-Project/M17_Implementations/tree/auth


Implementing digital signatures in M17 - part 2. Looks like both encoder and decoder work together and the latter is able to verify stream signatures now.

GitHub (`auth` and `crypto` branches are the most interesting):
https://github.com/M17-Project/M17_Implementations


See also micro-ecc - ECDH and ECDSA for 8-bit, 32-bit, and 64-bit processors.

The idea is that in addition to the digitized voice or data and overhead data, an authenticated M17 transmission appends a private key that can be authenticated with checking it against a person’s public key. SP5WWP commented:

The signature occupies 4 last data frames of the stream. It is generated after the data transmission has finished. When there's no more user data to transmit, a hash based on all the contents is calculated. That hash value is then signed with the user's private key. The assumption here is that there would be a central, trusted public key directory (a database with callsign-key pairs). That would ideally be run by IARU or some other international organization. I'm aware that IARU does not have enough human resources to run this, tho.

Key pair generation is trivial (under Linux CLI, it's a one-liner). An experimental (but already fully-functional, even with strong encryption) implementation is already available in our "M17_Implementations" repository ("main" branch).

This is a powerful capability for Amateur Radio given that we can quickly adapt such technology. For example, it could be used in emergency communications scenarios to insure that transmissions can be verified to be from authorized stations. I can imagine a future radio device that displays the callsign of a received signal…

  • ✅ when the transmitted callsign matches the signature / public key on file
  • ❌ when the transmitted callsign does not match the signature / public key on file.

The takeaway from this development isn’t that this particular experimental implementation isn’t complete, or perhaps has some issues, it’s that with an open source system such as M17… such things are possible!

Buying an Assembled Module 17

Zero Retries Annual Paid Subscriber Prefers to Remain Anonymous 15 emailed me to blame me for their purchase of two Module 17 units 🤨 Fair enough, I’ll accept that “blame”… but I wasn’t aware (that I recall) that assembled Module 17 units were available for on-demand purchase from AliExpress for $55:

LILYGO® & Module17-Revision 0.1e STM32 Development Board M17 Modem Board With DE-9 Connector Microphone Speaker Interface Switch.

Be sure to select

M17-R0.1E With OLED

In comparison, the only information on the M17 website about buying a Module 17 is

How to order Module17s at JLCPCB

Months ago in a private (or public?) discussion about Module 17, I stated that it was “good enough” to release as a “just buy it and use it” product to enable folks to generate some M17 radio transmissions. Apparently someone took that idea and went forward with it.

It Takes a Village (or an Email List) to Fully Understand M17

Tony Langdon VK3JED/VK3IRL on the m17-users email list:

I can add that Jonathan Naylor G4KLX was responsible for adding M17 support to the MMDVM project (which is also his work). [See also mmdvm.com.] He also created M17Client, which is client side (radio terminal) software that used a MMDVM board as a user radio. This works with both the modems (paired with a 9600 capable radio, makes an excellent M17 radio) and hotspots (creating a QRP self contained transceiver). Only other thing required is a USB sound device and some form of display usually HDMI or Nextion, though I got it working using a remote X server.

I've been involved in testing the MMDVM implementations of M17. I've also played with the TNC3 [obsoleted, new version is the TNC4] (unfortunately the app doesn't like my Android phone, which makes it a challenge to get working reliably), and today I use a Module17 into my own local M17 systems. The M17Client is still available as an alternative or for demonstrating a different implementation. As your article states, the different implementations work well with each other.

You missed M17Tools, which is a suite of software that runs on a host PC/Pi/Mac etc and can use a soundcard interface (Digirig is a recommended all in one interface that can pass baseband) to do M17 with a 9600 capable radio. At this time, M17Client doesn't like my Windows laptop, but others have reported good results, especially on Linux hosts.

VK3JED added:

Also, a lot of early IP only M17 activity was done by directly connecting to reflectors using mvoice or DroidStar. These methods are still available today, and are in common use.

See above for links to mvoice and DroidStar.

On the same thread, Tom Early N7TAE contributed:

I am pretty much an open-source fanatic, so when I heard of the M17 Project in early 2020, I had a few initial conversations with Steve, KC2AWV, on the M17 IRC channel and I was very excited about the project.

I was working on another project that was taking most of my free hours, but finished it up in the late summer of 2020. I knew I could help the M17 Project, in at least a small way. I got back on the IRC channel and started asking question about M17 internet packets. That part of the spec wasn't yet nailed down so had several email exchanges with Mike, W2FBI and Steve. The three of us settled enough on the specifics, that I squirreled myself away with my trusty laptop.

I wanted to write a reflector for M17. I already knew its name, mrefd. I didn't want to write it from scratch, but I knew of only two open-source reflector at that time. Because of its design, I chose xlxd as a starting point, an open-source transcoding reflector written by Jean-Luc, LX3JL and Luc, LX1IQ. I essentially gutted the multi-mode aspects of xlxd, as a framework for mrefd, so I just had to write the classes for the M17 protocol. I also needed an M17 client to test the reflector, so I coded mvoice basing it on another D-Star app I had written earlier.

After testing everything I could think of, on or about Oct. 17, 2020, my good friend and co-developer, Colby, W1BSB and I used mvoice to have the first M17 QSO going direct mvoice to mvoice (AZ to ME). Then we connected to the M17-USA reflector, at that time running on a server owned by Colby and had another QSO through the reflector. On that day, several bug were found and squashed.

A few days later, after fixing a few more things and filling in some details in the READMEs, I Emailed Mike about what Colby and I had done. Then Mike announce on the M17 IRC channel something like "Tom has developed a ****-load of working M17 software and ...". What happened next was amazing...

There was a lot of excitement! I think a lot of hams just wanted to hear what M17 sounded like. So, within a very short time there were mrefd reflectors running everywhere and mvoice bugs were coming in hot and heavy. Very quickly Doug, AD8DP added the M17-protocol to Droidstar. Within a year, there were over 100 M17 reflectors all over the world and Steve had a page on the M17 Project website where you could register your reflector and view the rapidly growing list of reflectors. It was amazing. There were lots of hams having QSOs with other hams all over the world, using the M17 Spec, even though precious few were doing it with RF. I think this illustrates very well how hungry hams were for a V/UHF digital voice mode that 100% belongs to them!

VK3JED concluded:

Some great early history there Tom, thanks for filling in some gaps I didn't know either. I was one of the DroidStar only early adopters myself.

As for my own involvement, COVID caused a resurgence of my interest in ham radio, as it was the perfect activity for lockdowns - one could stay home and have social interactions with others over the air. I quickly discovered a multimode system on VK3RBA and was intrigued at their integration of several modes. I had done a lot of work on IRLP/Echolink integration and EchoIRLP years earlier.

Anyway, I discovered DVSwitch [see also dvswitch.org] not long after and started experimenting with building my own multimode gateway, and while learning about DVSwitch, I saw mention of "M17" in the DVSwitch groups. I had no idea what M17 was, but a Google search quickly educated me and I was instantly hooked. Some time after, the arrival of USRP2M17 gave me cause to add M17 capabilities to my expanding multimode reflector. That system has since grown into a major multimode hub servicing several independent networks.

Rabbit Hole Explorations - The M17 Project Wiki

And… looking up some references made in the preceding exchanges on the m17-users email list quickly became a chase down a rabbit hole of yet more implementations and documentation of M17. Despite having gotten involved and interested in M17 months ago, in all the times I have visited the M17 website, I completely neglected to notice “Wiki” at the right end of the menu bar, and there is some very good info there, including:

I think that the M17 Project Wiki is an underutilized resource and that should be the repository of a lot of tribal knowledge such as what’s mentioned in this article. What’s great about wikis is that the user community can maintain them with little oversight from a webmaster.

m17-cxx-demod

M17 Modulator & Demodulator in C++ (GPL)

m17-cxx-demod

This program reads a 48k samples per second 16-bit, little-endian, single channel, M17 4-FSK baseband stream from STDIN and writes a demodulated/decoded 8k SPS 16-bit, single channel audio stream to STDOUT.

Some diagnostic information is written to STDERR while the demodulator is running.

m17-cxx-mod

This program reads in an 8k sample per second, 16-bit, 1 channel raw audio stream from STDIN and writes out an M17 4-FSK baseband stream at 48k SPS, 16-bit, 1 channel to STDOUT.

This is yet another discovery of an independent implementation of M17 enabled by the high quality of the M17 specification:

Thanks to the M17 team to for the great work on the spec.

Finding (and Registering) M17 Repeaters

M17 Project on Mastodon:

You can now register M17 repeaters at the Repeater World website - an open-source, open-data repeater directory!

https://repeater.world

To see all of the M17 repeaters worldwide, click the More Modes button, click M17, and click Search. (There’s a lot!)

On RepeaterBook (which is not not open source3), you can also view all M17 repeaters - put your cursor onto SPECIAL MODES on the menu bar and click on M17. You can also Add a Repeater on RepeaterBook; note that there is a checkbox for M17. Kudos that RepeaterBook has apparently had the M17 option since 2023.

I note that the Western Washington Amateur Relay Association (WWARA), the repeater coordination organization in my region, doesn’t yet recognize M17 in their Technical Data Sheet application for coordination. I emailed them to suggest adding it.

Every Friday is M17 Activity Day

M17 Activity Day - get on the air/net with M17!

An all-day event on Fridays where people are encouraged to get on the air or get on the network using the M17 digital voice mode.

Link your hotspots and repeaters to the M17-M17 Reflector on Module C for greater effect!

When: Weekly, on Fridays

Where:

I created an entry in NetFinder for M17 Activity Day. The entry isn’t perfect as it allows only one frequency to be stated, and a specific time (and this event runs all day, with no time zone for “all day” stated. But there’s ample fun to be had from getting on the air, or network, with M17.

Follow-on M17 Projects - OpenHT and Remote Radio Unit

As a continuation of his development work on M17, Wojciech Kaczmarski SP5WWP has begun development of two follow-on projects that incorporate M17 - the OpenHT and the Remote Radio Unit.

OpenHT

The OpenHT is a handheld, self-contained Software Defined Transceiver for the Amateur Radio 420-450 MHz (70 cm) band and the 2.4 GHz band, including display and keyboard. I’ve previously written about the OpenHT in Zero Retries 0099 - M17 OpenHT - A Breakthrough In Ham Radio.

Most of the progress on OpenHT was in mid-2023 for its debut at Ham Radio 2023. I’m not aware of any additional progress on OpenHT reported recently.

Remote Radio Unit (RRU)

The RRU is an M17 and FM radio / repeater that is designed to be installed (remoted) near an antenna, very similar to the Icom IC-905’s radio unit. I’ve written about the RRU several times:

As I understand it, both OpenHT are projects in development, but lack sufficient funding to take them forward and complete them enough to be products (which would then require a group or company to commercialize them for turnkey sale, or at least launch a crowdfunded project to manufacture batches of them).

From my perspective, I consider the RRU to be a very promising concept and project and (again, seems to me) that RRU could be taken forward into being a popular product, especially in the US where there is ample spectrum in the Amateur Radio 420-450 MHz to make use of such a system.

A Demonstration of the Flexibility of M17 - Running on a GameBoy Advance

Wojciech Kaczmarski SP5WWP on LinkedIn:



Can you run an M17 packet encoder on a GameBoy Advance with a custom-made ROM? Of course! The trick is to use fixed point arithmetic instead of floats in the square-root raised cosine baseband filter :-) The point of this proof of concept is to show how versatile and portable libm17 (and the M17 protocol itself) is.

Here's the GitHub repository for my open-source "game" generating M17 baseband:

https://github.com/sp5wwp/gba_m17

The generated signal is available at the headphones port and can be used with an amateur radio transceiver for sending text messages.

Followup email from SP5WWP:

I managed to run libm17 on my Gameboy Advance, generate baseband for a packet and decode it on my PC under Linux with the `m17-packet-decode`. How cool is that?

The point of this is not to make people use GBA for M17, it's to show how versatile libm17 is (and how cool the protocol is!). I'm aware the repeatability of this is low, but it's interesting and educational.

More Concluding Conclusions on M17

The more I have studied M17 in order to write about it in Zero Retries, the more impressed I am with the energy and enthusiasm being applied by the M17 community that has been devoted to making M17 a viable option for Amateur Radio use on VHF / UHF bands. I’m not surprised with this level of enthusiasm and participation as there have been other projects such as Multi Mode Digital Voice Network (MMDVM) that have very broad (and occasionally niche-y) development. But all of that… energy… isn’t readily apparent about M17 as there isn’t a single place to see all of the various facets of M17.

The Wikipedia M17 article isn’t comprehensive, the M17 website isn’t comprehensive, and certainly the history of articles about M17 in Zero Retries isn’t comprehensive. Not to mention, M17 continues to evolve; it’s not stable - and in my opinion, that’s a feature in this era of Radios Are Computers - With Antennas! No one expects a computer to remain static - its software, and often its firmware, is constantly being updated. Radios in the 21st century, being largely computers, shouldn’t be considered differently.

Sometimes… a subject as complex and diverse of subject such as M17 really cries out to be captured in a book - which can contain all of the disparate aspects . I’m working on such a book, with help from SP5WWP. These articles about M17 in Zero Retries are precursors to chapters in that book. I’ll keep you apprised about its progress.


By Steve Stroh N8GNJ

I intend no disrespect to all the varied Emergency Communications activities that are performed within Amateur Radio, or those that perform them. The emergence of Starlink as a Broadband Internet Access system with few dependencies other than power has changed the paradigm of emergency communications. But now, but the emergence of the new Starlink Mini has profoundly changed the paradigm of emergency communications.

Image courtesy of SpaceX / Starlink

The photo above tells the story at a glance about how well-suited Starlink Mini4 is for providing emergency communications when normal communications such as cellular or consumer Internet access are unavailable. Starlink Mini is light enough and compact enough to be carried on one’s back (or in a backpack). It can be powered by any USB-C power source, including compact USB-C battery packs (for at least a few hours) or an AC to USB-C power adapter. Wi-Fi and Ethernet are built-in on the unit. It’s managed by a smartphone app. To set it up, open the app, follow the instructions for orienting it optimally (though it will likely work acceptably by laying flat if there is enough clear sky). Within a few minutes at most you are connected to the Internet at broadband speeds. It can easily be remoted to a rooftop using a simple and inexpensive power extension cord and an Ethernet cable. It will work nearlyanywhere!

The reason I bring this up is that a Zero Retries reader contacted me about an article about a “Go Box” to set up Winlink and noted “things have changed now that Starlink Mini is available”.

Disclaimer - Yes, Starlink is a subscription service, and you have to buy Starlink Mini for a few hundred dollars and keep a service plan active for one’s Starlink Mini to be ready to use at a moment’s notice. To use one’s Starlink unit for emergency communications will likely mean exceeding the “inexpensive” service tier’s maximum data transfer limit of 50 GB. Acknowledged that those are real issues now, but Starlink has exhibited considerable flexibility in adjusting its services in response to changing business conditions. It’s my (optimistic) guess is that in a declared emergency, if one asks, Starlink can temporarily waive data transfer limits or cost penalties for “excessive usage”.

The goal of using Winlink, of course, is to be able to send Internet email over Amateur Radio spectrum, both HF and VHF / UHF. Using Winlink used to be a bit fraught with peril because of the relatively poor data modes Amateur Radio has traditionally used for Winlink. Formerly the only good option had been the pricey and proprietary Pactor 4 modem for HF. Now there are other options for Winlink, especially VARA - FM for VHF / UHF and VARA HF for HF. The cost of a VARA license and audio adapter to use VARA FM and VARA HF are a fraction of the price of a PACTOR 4 modem, and work comparably on HF, and work great on VHF / UHF (up to 25 kbps).

But consider the bigger picture here in “Winlink versus Starlink Mini” as a “Go Kit” solution (in approximately the same form factor):

  • Winlink is “narrowband” email, with some capability for attached files.
  • Starlink Mini is a broadband Internet system, and thus can handle any Internet activity - video cameras, video conferences, viewing streamed video, file transfers, email, Voice Over IP telephones… and can do all of that for multiple client devices such as multiple laptops connected via Ethernet or Wi-Fi.
  • A Winlink Go Kit is a complex assemblage of radio(s), modems, computers, software, antennas, power supplies, and integration.
  • A Starlink Mini is simple by comparison - power from a USB-C source, and connect to it via Ethernet or Wi-Fi, use normal Internet systems such as web browser.
  • A Winlink Go Kit can only be used by an Amateur Radio Operator who is trained / practiced in using the combination of the radio, the modem, the computer, and the software, and all of the procedures on how transmit and receive via Winlink.
  • A Starlink Mini can be used by anyone; it’s effectively “unlicensed” wireless Internet. The app is easy to understand, and once it acquires the satellite constellation, it just works when you connect to it with Wi-Fi or Ethernet. The app provides status, devices connected, some management, and diagnostics including a speed test for troubleshooting and it can tell you if there’s an issue with the satellites, or obstruction.
  • Winlink requires some infrastructure, especially when using VHF / UHF Radio Mail Servers (RMS).
  • A Starlink Mini requires comparatively little infrastructure now (a regional Starlink Ground Station) and in the future will require practically no infrastructure through the use of inter-satellite links.

Analogy - Autopatch

I think there’s a useful analogy in Amateur Radio’s very active use, and then complete disuse, of “Autopatch” on VHF / UHF repeaters. As a new Amateur Radio Operator in the mid-1980s, one of the most popular uses of repeaters was autopatch - “automatic phone connection”. If you wanted to make a phone call from your portable or mobile VHF / UHF radio, you could easily and quickly command the repeater to connect a phone line, dial a call with touch tones from your radio, have your conversation, and then disconnect the phone line. Autopatch was an incredibly popular feature of repeaters… but no one uses autopatch any more. There’s no technical reason not to continue using autopatch; it would work as well in the mid 2020s as it did in the mid-1980s, and there’s only a minor cost issue in having a telephone line connected to a repeater for a monthly fee.

The reason that no one uses autopatch any more is because using one’s own mobile phone is so superior to using autopatch that it’s no longer even a question about using autopatch. Why would you even want to consider using autopatch?

I think that’s the situation we’re now in with Winlink, albeit at the very beginning of the situation where Starlink (Mini) is such a superior solution to the issue of emergency communications. But I believe that the conclusion will eventually be the same as with autopatch; no one will consider using Winlink because using Starlink (and other similar systems now in development5) will be a far superior solution for emergency communications.

On Beyond Starlink - Mobile Phone Direct to Satellite

Not to mention… by the end of this decade, we may not even need Starlink to use at least basic satellite connectivity from our mobile phones in an emergency, thanks to:

It’s amazing to me that Iridium, the one “phone works everywhere on the planet via satellite” service provider, has fallen out of the conversation versus the above developments getting lots of attention.

It’s a brave, interesting, much more communications-rich new world!


ZR > BEACON

By Steve Stroh N8GNJ

Short mentions of Zero Retries Interesting items.

FCC Public Notice - Wireless Telecommunications Bureau and Office of Engineering and Technology Seek Comment on NextNav Petition For Rulemaking

NextNav Inc. (NextNav) filed a petition for rulemaking requesting that the Commission initiate a proceeding to reconfigure the 902-928 MHz band (Lower 900 MHz Band) and adopt new rules to enable the deployment of a 5G terrestrial positioning, navigation, and timing (PNT) network that “complements and backs up” the U.S. Global Positioning System (GPS). By this Public Notice, the Wireless Telecommunications Bureau (WTB) and the Office of Engineering and Technology (OET) jointly seek comment on NextNav’s Petition.



Amateur radio operations are allocated on a secondary basis to LMS. Part 15 unlicensed devices also operate in the band, are not typically afforded interference protection, and may not cause harmful interference to LMS licensees, amateur operations, or other licensed systems. However, Commission rules intended to ensure coexistence between services require M-LMS licensees to demonstrate through field tests that their systems do not cause unacceptable levels of interference to part 15 devices.

This goes on for 8 pages of dense, tortured, legalistic, pseudo-technical explanations from NextNav of how this system is desperately needed and is the solution for “3D positioning accuracy”.

This is NextNav’s second attempt at getting the FCC to reconfigure 902-928 MHz to accommodate their technology. Their previous attempt was dismissed by the FCC in 2014:

By this Order, we terminate the above-captioned Multilateration Location and Monitoring Service (M-LMS) rulemaking proceeding, and conclude that the various proposals for broad revisions of the applicable rules do not merit further consideration at this time.

It’s particularly galling that “LMS” licenses were auctioned in 2005, but the buyers of those licenses simply could not make their technology work to actually deploy a working system in accordance with their licenses and the unique situation and user hierarchies inherent in 902-928 MHz when they bought those licenses!

Originally this system was posited as the solution to more precise automatic location during E911 calls. GPS receivers built into mobile phones, and other measures such as triangulation from cell towers has proven to be an adequate solution for that issue. Thus, NextNav has pivoted its technology’s purpose to “backing up GPS”. The history of Location and Monitoring Service (LMS) in 902-928 MHz has gone on for nearly two decades now trying to exploit an LMS license in this band for monetary gain (likely hoping for a buyout of their license) or a favorable “spectrum swap”. In those nearly two decades, 902-928 MHz has become used for millions of devices (I’d argue hundreds of millions of devices) such as Automatic (radio) Meter Reading (AMR). Usage of unlicensed devices in 902-928 MHz has literally exploded beyond any possible accounting by FCC or anyone else, and is poised to increase even more with inexpensive and capable 802.11ah / Wi-Fi HaLow devices that have recently emerged as a solution for wider range personal wireless networks that can extend up to several miles, including through trees.

My previous house in Woodinville, Washington had three such devices operating in 902-928 MHz - one on the water meter, one on the electric power meter, and another on the natural gas meter, all using a common radio network.

But, however… nonsensical and blatantly self-serving in trying to posit a “crisis” as this Petition for Rulemaking is, it is a formal proceeding underway by the FCC. If granted, it definitely will affect Amateur Radio’s use of 902-928 MHz, such as the new capabilities we could soon be using with 802.11ah / Wi-Fi HaLow devices.

Comments Due: September 5, 2024

Reply Comments Due: September 20, 2024

Sigh… great… more pro forma, legalistic writing of a formal comment to the FCC, with a tight deadline.

My thanks to Zero Retries Pseudostaffer Orv Beach W6BI for mentioning this document to me.


Stealth Mode New Hire at ARDC - Adam Lewis KC7GDY is New IT & Development Manager

ARDC hasn’t announced this yet (as I compose this issue), but it’s confirmed on the ARDC Who We Are page and a brief mention on KC7GDY’s LinkedIn page:

I’m happy to share that I’m starting a new position as IT & DevOps Manager at Amateur Radio Digital Communications (ARDC)!

KC7GDY has been an energetic and talented volunteer on the ARDC Technical Advisory Committee (TAC), especially on the still-in-beta-testing ARDC 44Net VPN project. From that exposure, he’s had to become familiar with the unique challenges of ARDC’s IT infrastructure, and thus… he was warned about what he was getting himself into 😀

Congrats and Kudos, Adam! Well deserved!

(And, if you’re reading this Adam, apologies for being a laggard on the beta 44Net VPN participation. I will get my beta VPN up and running soon!)


A Sneak Peek at the Forthcoming Halibut Electronics Egg Beater Antenna

An Egg Beater antenna is an ideal antenna for receiving from (and transmitting to) satellites in Low Earth Orbit (LEO). Think of it as an omnidirectional antenna whose pattern is directed towards the sky instead of to / from the horizon.

The problem with Egg Beaters is that they’re “fussy” - necessary to achieve the required phasing of the two elements necessary to achieve the “overhead omnidirectional” pattern. Thus professionally built antennas have been the preferred type of Egg Beater antennas… until now.

Mark Smith (Smitty) N6MTS of Halibut Electronics seems have cracked the code for building your own Egg Beater antenna by providing a semi-kit of “the fussy bits”. N6MTS does the tough phasing work providing a pair of printed circuit boards (PCBs) and a choke / coaxial cable assembly. Those components are derived from a lot of testing and measuring to develop the PCBs that really work. Considerable assembly and your own parts are required. The instructions are detailed, including several cautions of what not to do during the assembly process.

N6MTS asked for feedback on the Halibut Electronics email list for his preliminary assembly manual for the EggNOGS antenna kit (he explains the name in the document). Think of it as a preview for the EggNOGS prior to it being generally available for purchase.

This is a cool kit and an EggNOGS looks like a decent antenna to get started with downloading telemetry from Amateur LEO satellites until you’re ready to invest in a full azimuth / elevation tracking directional antenna system.

Separately, N6MTS also provided a brief video “unboxing” of the EggNOGS kit.


Video - Preview of a New User Interface for AREDN

AREDN Ambassador (and Zero Retries Pseudostaffer) Orv Beach W6BI on several AREDN-related email lists:

Coming to an AREDN nightly build near you soon - a shiny new UI :-)

This YouTube overview by Tim KN6PLV explains why the AREDN devs decided a new UI was needed for the AREDN software. Tim goes into the reasons why, then does a deep dive into every corner the new UI. Folks who have seen it like it a lot. Check it out!