Random Wire 140: The AllScan UCI90 with a Raspberry Pi Zero 2W
July 18, 2025: A tiny AllStar node with the UCI90, Raspberry Pi Zero 2W and a K-1 speaker-mic. Also, a new HF antenna is coming soon, plus a full-duplex handheld!
Breaking news
MMDVM no longer supports M17
For those who haven’t heard, Jonathan G4KLX has announced that MMDVM no longer supports the M17 protocol. See the explanation at: https://groups.io/g/OpenDV/message/2311
Jonathan noted that M17 “is being removed from WPSD” and he believes “Pi-Star is going down the same road.”
WPSD builds on the capabilities of MMDVM, so with MMDVM dropping support for M17, WPSD won’t support M17, as confirmed by Chip W0CHP:
To verify this, I updated my WPSD hotspot. After the update, M17 was no longer present in the dashboard. Some people have “forked” the code to help preserve older versions that contain M17 support. This situation is all too fresh and unsettled to know how this will shake out. If you are interested in M17, stay tuned!
Tiny AllStar node: UCI90 and Raspberry Pi Zero 2W
I mentioned in the last issue that I was reviewing the new AllScan UCI90 USB communications interface that lets you use a K-1 speaker-microphone with an AllStar node. When I first saw the UCI90, I thought: I wonder if I can make a really tiny, portable node with it. The answer? Yes, I can!
A temporary tiny node
Here’s what a temporarily-taped-together version looks like:
There is a battery bank on the bottom. The UCI90 sits on top of the battery. The Raspberry Pi (“RPi”) is temporarily taped to the top of the UCI90 case. I’ve tried several different K-1 speaker-microphones and so far, the Kenwood mic sounds the best.
I tested the node by running it overnight from the battery. I had plenty of battery still available the next morning, so that was a success.
What does it sound like?
You probably want to know what it sounds like. The video below captures my test transmissions and a bit of a net conversation. You may hear a bit of whine in my transmissions, and I’ll address that right below the video.
I wondered where the whine was coming from. My first thought was to separate the audio streams, so I went out to the pickup truck and removed my Icom mobile speaker from my Yaesu FTM-300DR mobile radio.
After plugging that in, I tested. I think the audio sounds much better coming through the external speaker than it does through the small speaker-mic. It appears that the whine you might hear in the video was not introduced in my audio transmission, and that’s a good thing. Here’s the recording of audio received through the external speaker:
That sounds pretty good.
Gathering the necessary parts
To upgrade this assembly, I bought a smaller battery that fits better with the footprint of the UCI90. I also bought a few USB-C-to-microUSB cables to eliminate adapters, and also picked up some snap-on ferrites to make sure those cables don’t monkey with the audio. Those three bits — the battery, UCI90, and RPi — are attached to each other with double-sided tape.
Here’s the parts list with links to sources:
Battery with built-in cables: VRURC Portable Charger with Built-in Cable, 10000mAh 22.5W Fast Charging USB C Battery Pack, Cell Phone Power Bank for iPhone 16 15 14 Samsung Galaxy S24 S23 Series Android Tablet, Black (1 Pack)
UCI90 (comes with the necessary cable): AllScan UCI90 USB Communications Interface. Ready to plug in to any computer running ASL, DVSwitch, HamVOIP, EchoLink or other PTT communications applications. Provides a K1 Speaker-Mic/Headset jack, 3.5mm Speaker jack, TRS Line Out jack and Mic gain adjustment controls.
Adapter for the UCI90 cable: UGREEN Micro USB 2.0 OTG Cable On The Go Adapter Male Micro USB to Female USB Compatible with Samsung Phone S7 S6 Edge S4 S3 LG G4 Controller Android Windows Smartphone Tablets 4 Inch Black
Raspberry Pi Zero 2W: CanaKit Raspberry Pi Zero 2 W Basic Kit with Official Case
Raspberry Pi Zero 2W case: Raspberry Pi Zero Case Kit with Heatsink, HDMI Adapter, for Pi Zero 2 / W
Speaker-microphone: Kenwood KMC-21 Compact Speaker Microphone
Protective case: APACHE 1800 Weatherproof Protective Case, Small, Black
Here is what that looks like, all put together and ready to toss in the car and go on the road:
Using the node
To use the node, I enable the hotspot service on my smartphone. I have the node configured to automatically connect to my smartphone, so when I fire it up it soon comes online. To control the node, I need a web interface. I can do this on my phone but usually use a tablet or laptop because those larger screens are easier to read. (I also pack a microUSB-to-Ethernet adapter and a short Ethernet cable in case I need to physically connect to a network to manage the Raspberry Pi.)
The USB power bank I’m using does feature passthrough charging. This means it will power the node even while I’m recharging the power bank. Unfortunately, it’s not quite the clean passthrough charging I was hoping for. When I plug a USB charger into the power bank “in” port, it momentarily interrupts power to the node. I’ll have to find a way to trigger a smooth shutdown of the node to avoid damaging the operating system.
The good news is the 10,000mAh power bank lasts a long time. Starting with a full charge, I left the node running and occasionally checked to see how much juice was left in the power bank.
After 5 hours, 84% charge remained.
After 7 hours, 77% charge remained.
After 10 hours, 68% charge remained.
It’s safe to say that a 10,000mAh power bank should run the node all day and probably for a full 24 hours. That will be convenient when traveling.
By the way, if you tend to listen a lot and rarely talk, this build is an inexpensive way to have a high-quality AllStar node that takes up little room. The 8-ohm speaker out port on the back works great with the Icom speaker, providing easy-to-hear, high quality audio.
An on-off switch?
I purchased a normally open (“NO”) momentary switch to, hopefully, trigger a controlled shutdown of the Raspberry Pi. Unfortunately, issues with my wife’s care this week got in the way of completing this aspect of the project.
My plan is to connect the switch to GPIO pins 5 and 6 and, possibly, set the debounce value to 3000 so that powering off would require a three-second-long push of the button. I’ll use double-sided tape to attach the switch to the top of the UCI90 case.
Broke the node, fixed it, broke and fixed it again
This particular journey involved powering down the node many times. One of those times I must have forgotten to properly power down the node, because the microSD card became corrupted and the node wouldn’t boot up again.
Having been through this a few times, I quickly found the image file (still in my Windows 11 Downloads folder) and used the Raspberry Pi Imager to burn a fresh image to the card. Unfortunately, that image was the stock image so none of my configuration details were included. I used the sudo asl-menu command in a terminal window to configure AllStar.
Once AllStar and Allmon3 and AllScan were all running properly, I made an image of the working microSD card — something I should have done before. This will make it much easier to recover from a fault in the future. (It turns out this was a good thing to do, because a few days later, I disconnected the power bank without properly shutting down the node and again corrupted the microSD card. Having an image of a fully configured node made the second recovery much, much faster.)
You can use Balena Etcher to burn an image of a working card, but I like Win32 Disk Imager for this. Even though the interface is a bit awkward and dated, Win32 Disk Imager seems to work fine for me.
Says SourceForge:
This program is designed to write a raw disk image to a removable device or backup a removable device to a raw image file.
What improvements could I make?
What could I do to make this little portable node better? If you have ideas or suggestions, please do share them so we can all benefit from the dialogue!
I am contemplating putting the whole node package into an Apache 1800 case, including a tiny keyboard and a seven-inch screen. That would allow the node to be controlled without having to have a laptop handy.
As a proof of concept, I pulled my seven-inch screen out of my parts box to make sure it would fit in the lid of the Apache 1800 case. This is the little screen I often use when setting up a node. I also checked my iPad Mini and without its protective case, it also fits inside the Apache case lid.
Here’s a short video showing how the miniature keyboard with mousepad can be used to control the node and even to shut it down properly. (The screen in the video is my laptop, not the seven-inch screen shown above.)
I originally bought the keyboard to use with streaming services on my smart TV. It does come in handy when you want to type a word in the search box, or enter a password. But I rarely do those things, so I’ve been looking for a way to repurpose it. I may have found it!
I’m actually surprised that this little keyboard functions well enough to type in an IP address or URL, and that the mousepad is reasonably responsive and accurate. For more information, you may wish to check out the user manual at: https://www.fosmon.com/media/productattach/2/3/23022kb_fosmon_portable_bluetooth_keyboard_with_built-in_touchpad.pdf
Antenna ordered
I was looking at the SOTA/POTA 150 antenna at Ham Radio Outlet. It seemed like a simple antenna system that would be reasonably quick to set up. It also looks like I could easily carry it in my vehicle. It would work with my Yaesu FT-450D, Yaesu FT-891, and with my new zBitx QRP transceiver.
And then I saw the YouTube video by KB9VBR about the Radioddity HF-009 antenna. It was soon apparent that the SOTA POTA 150 closely resembles the HF-009 antenna system.
If you click the HRO link and compare the images with the antenna at the Radioddity link, I think those similarities will be evident.
Given those similarities, I ordered the Radioddity antenna, intending to use it with my zBitx HF transceiver. I also want to retrofit it to work with a tripod so I can move the radials a couple of feet above ground. (This could just be a couple of pipe clamps to connect the antenna spike to the vertical column in an old camera tripod.) I’ll let you know how it works for me.
The HF-009 user manual is available as a PDF at https://radioddity.s3.amazonaws.com/2025-03-25_Radioddity_HF-009_User_Manual_V1.0.pdf.
If you want to buy the Radioddity antenna, please consider using my affiliate link to save $15 off your purchase: https://radioddity.refr.cc/default/u/thomassalzer?s=esp&t=cp. Note that when you shop with this link, and add the product to the cart, the discounted price is not shown, but it should appear when you go to checkout.
Full duplex handheld ordered
I’m really excited to get the Wouxon KG-UV9D Plus radio! It might actually show up before this issue of the Random Wire publishes on Friday, July 18th.
This is interesting to me because David NR9V has tested the KG-UV9D Plus with an AllScan ANF101 node and found it worked well. You can see and hear this in the video he published this week:
I also like the look of the KG-UV9D Plus display. I’m looking forward to testing this handheld with my AllScan ANF101 full-duplex node. Stay tuned because I’m sure I’ll have some photos and tips to share in a week or two!
Learn more about the AllScan ANF101 at: https://allscan.info/products/#nodes
Thoughts on open source and M17
Once upon a time, when I worked for a small state agency, I switched my computing to all open source software. This was not approved. In fact, it was actively resisted by the state information technology folks. I had previously asked for permission to try it, and while I was not told no, it was clear the IT people were very, very unhappy with me for even asking the question.
I set aside my computer running Microsoft Windows and began using one running Ubuntu Linux. I found an open source mail client that would interface with the agency’s Exchange server. Calendaring was part of that client. Firefox worked fine as a browser. OpenOffice let me create and edit files that were largely compatible with Microsoft Office products.
None of this is a surprise to those of us who appreciate, and try to use, open source software. We know that open source products can be robust, useful tools. However, what surprised the IT folks was that none of my hundreds of customers (citizens and state employees) ever recognized that I was using an open source operating system and software to serve them.
Now, many years later, I also recognize that one of the key issues with using open source products in an enterprise environment is supporting end users and their systems. It can be hard to scale support to thousands of end points and people with packages that don’t have millions of dollars of research and development behind them. Most open source projects are relatively small and may lack well-staffed support systems for end users. Open source often (usually?) starts at the smallest scale of one or two people and expands as revenue increases; generating sufficient revenue is a frequent challenge for small, young initiatives in the open source software realm.
For those who create and provide open source products, the lack of people and money are often key limiting factors in the success of their enterprise. When it’s a one or two-person show, and revenue is lacking or insufficient, it can become very challenging to maintain a positive outlook, build community, and grow the organization. Just dealing with software problems and difficult people can exhaust one’s capacity to carry on, diverting energy away from growth. A corollary to this is the Ninety-Ninety Rule: “The first 90% of the code takes 10% of the time. The remaining 10% takes the other 90% of the time.” Getting to 90% goes quickly. The problems that are more difficult can consume the rest of your time, money, and energy.
One thing I’ve observed in the open source world is that the first offering sometimes is not the one that survives. It takes a tremendous amount of energy to develop and introduce a new idea, reach sufficient users to generate forward momentum, and build a dominating product, especially when one is swatting the numerous, inevitable bugs that come with new software. (And don’t forget that software development is a creative endeavor, and often a solo effort. A creator’s satisfaction often comes from the process of creating, not by solving other people’s problems or working as part of a team.) Meanwhile, others may see what is working and what isn’t and either fork the project or create a new one that improves the service or capability of the software. They don’t have to invest in conceiving and crafting the concept — they just need to make it better, differentiate it from the creator’s version, and market it well. This is known as second-mover advantage.
Let’s fast forward to the current situation where support for the M17 protocol is suddenly on the wane with other systems. Jonathan G4KLX recently published a notice that he is removing support for M17 from MMDVM software. The popular WPSD hotspot software by Chip W0CHP depends on MMDVM, so M17 has been removed from WPSD. Undoubtedly, we will see some other systems drop support for M17.
There is also some conflation going on where criticism of “M17” seems to sometimes point toward the M17 protocol and technical specifications and sometimes toward the M17 Foundation. From my point of view, the formation of the M17 Foundation was an attempt to provide a long-term support framework to M17, supporting the technology and also digital innovation in amateur radio. The M17 Foundation will host their first M17 conference in September.
I think the formation of M17 Foundation was a good development, in part because it directly addresses the single-point-of-failure weakness we see in many other projects. This action will help to build long-term stability, support, and improvement for M17.
It is exceptionally unfortunate that no warning was given to the thousands of users in our community who use MMDVM and WPSD software. The removal of M17 support came suddenly, surprising radio amateurs. This, more than anything, leads me to believe a tipping point was reached that caused G4KLX to react instead of plan, communicate, and implement in a more intentional way. Perhaps, with time, G4KLX will reverse his decision. That would be a very beneficial outcome for radio amateurs who use and enjoy MMDVM technology.
The other very unfortunate part of this is that while the MMDVM project has been one of the great contributions to our amateur radio hobby, it also seems rather underappreciated by the community. Imagine being a creative force whose efforts generate complaints and criticism more than compliments. In such conditions, it becomes easier to understand why G4KLX pulled the plug on M17.
I’m not going to weigh in on the technical issues with M17 raised by G4KLX, or with the belief (fear?) that M17 may be monetized in some way. From my distant point of view, ignorant of the inner workings behind this situation, the issues seem likely to revolve around friction and lack of inclusion/respect. For a point-by-point rebuttal, however, please see https://groups.io/g/M17-Users/message/308.
Creative folks are sometimes not the easiest to get along with. They have a vision and have to have the drive to move their vision forward, despite constant pressure to do it differently in some way. They must have this single-minded approach to succeed. I get it. I also get that sometimes, the very attributes that get us to a certain place also block our ability to move forward. The skills and behaviors that help us build and create something new are often not the ones that help us plan with others, communicate effectively, and manage growth.
Creative individuals are one of the great strengths in our amateur radio community. I am blessed to know many such people. But projects that depend on one person are also a weakness. In engineering, we call this a single point of failure (SPOF).
A single point of failure (SPOF) is a component within a system whose failure would cause the entire system to stop functioning.
In a solo enterprise, the one human is always a single point of failure. This is one of the reasons large enterprises often resist using open source software, because if something happens to the creator, the project becomes orphaned and unsupported…unless someone else steps forward to take on the project. It’s hard to build a corporate enterprise when the ability to perform certain functions depends on a single, external human.
Let’s also remember these are open source projects. If someone wants to fork MMDVM, they can do so. (The act of forking a project is not as simple and uncomplicated as it sounds.) Same with WPSD. Same with M17. Building on past success seems to me a more productive way to approach this than vilifying individuals or the efforts of others. If you can make it better, do it. If not, let’s honor the incredible contributions of the people behind these open source initiatives and be thankful we have such creative people in our community. They give others opportunities to build on that work, benefiting all of us.
I have not given up on M17, the only open source digital voice and data protocol currently deployed by radio amateurs.
This time last year
Where were we a year ago? Check out the July 19, 2024 issue of the Random Wire Review:
Closing
I have an amateur radio club meeting tomorrow (Saturday). This will be a very nice break from the daily work of caring for my wife and assisting in her recovery. She has had a good couple of weeks, becoming more conversational, smiling, and we even heard her laugh — big, deep laughs — several times. These are big changes, especially since I haven’t seen her smile since May 8th. She is also getting stronger, tolerating the transition from bed to sitting and standing better and better each day.
I think the M17 situation is unfortunate. It comes at a time when the M17 Foundation is trying to find a more stable footing. It seems like it might have been preventable. But taking a really long view, it might also present excellent opportunities to strengthen M17. I urge those interested in M17 to stay the course and contribute your support how and where you can.
In the meantime, thank you for reading the Random Wire newsletter. When there is content that you find particularly interesting, let me know and please do share the newsletter with others.
Finally, in the realm of experimenting with AI, I hope you’ll enjoy this jingle about amateur radio and the Random Wire newsletter!
I don’t quite know whether to laugh or roll my eyes at the jingle, but it did make me smile, and that’s not a bad thing.
73 to all. Remember to touch a radio every day!
The Pi Juice UPS HAT is a pretty nice addition to a Raspberry Pi that needs to stay online while mobile. I have several, although they were about half the price I see on Amazon this afternoon. They can run on a battery that was used on a Motorola phone, or you can wire up a few 18650 cells into pads on the HAT.
https://www.crowdsupply.com/pi-supply/pijuice-zero
I really like this. I bought two things from Allscan - and I cannot for the life of me figure this out. I am a General, and I do HF, but I cannot figure out all the things HT/UHF/VHF. It’s quite embarrassing. The only thing I’d like is everything one box - the pi, the power supplies, batteries, and a small screen, etc. - only three connections on the outside - power, speaker, mic. I’d design one, but my second impasse of technical naïveté is AutoCAD design to create STL files for my 3d printer.