OpenWRT and ampr-ripd

In an effort to make it easier to install ampr-ripd on an OpenWRT system, I’ve revisited my packaging code and published it to github. Along with the OpenWRT SDK you ought to be able to generate an ampr-ripd package for any current OpenWRT platform.

ampr-ripd is a modified RIP listener written by YO2LOJ. It is used by licensed amateur radio operators who have received a Net44 allocation from ARDC.

The high-level workflow is:

Install the SDK for the target platform on the host of your choice.
Copy the contents of the repository to ./packages/ampr-ripd/.
make package/ampr-ripd/prepare
make package/ampr-ripd/{clean,compile

The resultant ampr-ripd_{your architecture}.ipk will be found in ./bin/packages/{your architecture}/base/.

73 de K2IE

Weather Software Updates

The National Weather Service has updated their Common Alerting Protocol (CAP) to version 1.2. This broke our noaacap weather software and the related DAPnet NWS paging rubrics for a bit.

Thanks to an alert radio amateur who called this to my attention, both systems have been updated to process the new alerting format. What you see will not change. All the changes have been behind the scenes.

If you’re running aprx or Dire Wolf as your APRS software, be sure to take a look at noaacap and consider providing weather updates for your county. If you’re already running noaacap, please update to the latest release.

Need A Radio Check?

Next time you think about interrupting a digital voice QSO for a radio check, think again and connect to XLX020 Module S.

There, you’ll find our DV Bot. Key up on the module and try something like “This is <Insert Callsign>. May I have a radio check please?” No doubt, this will lead you down an amusing rabbit hole.

The DV Bot is a voice to text interface to ChatGPT, the much talked about artificial intelligence backend. Yes, AI does digital voice!  Give it a try and let me know what you think in the comments.

73 de K2IE

Kenwood D74A Replacement Wishlist

There’s chatter about a new Kenwood HT that will be the replacement for the capable TH-D74A. The D74A is a great radio, but I have a few ideas that would make a replacement even more useful:

Battery Life — The D74A’s major failing is short battery life. Yes, the radio does a lot and draws a lot of power. But I am sure there are ways that battery life could be improved.

Front Panel Programmability — The D74A is very programmable, but for some reason, DR (Digital Repeater) mode cannot be programmed from the front panel. This is rather inconvenient, because DR mode is needed for proper reflector operation on a hotspot. Add DR mode programmability from the front panel.

Rubber Accessory Cap — The rubber accessory cap on the right side that covers the mic, data and power jacks tends to swell over time. Let’s fix this.

Do you have items for the wishlist?

73 de K2IE

IMRS Active on NJ2DG Fusion Repeater

An IMRS connection to the XLX020 reflector has been activated on the NJ2DG Fusion repeater in Martinsville, NJ. All XLX020 modules are now accessible via the repeater.

To select a module, simply transmit with the DGID set to any of (10 .. 35). DGID 10 is XLX020 Module A, DGID 11 is XLX020 Module B, etc. Module D (CNJHAM) uses DGID 13.

Unlike DMR, there is no initial keyup required to connect to the chosen module. This is about as easy as it gets, once you learn how to change the transmit DGID on your radio.

Wires-X is still available via DGID 50 with an inactivity timer of 10 minutes. The IMRS connected modules do not have an inactivity timer.

The NJ2DG Fusion repeater in Martinsville is on 441.400 MHz (+5).

73 de K2IE

Update: Crisis Averted

Thanks to LX1IQ for getting us restored as the rightful owner of XLX020! Also thanks to SA7SVR for agreeing to voluntarily move his XLX to a different number. I have suggested to LX1IQ that we do some analysis to see if a faulty system clock situation did indeed break our registration.

(Original Post)

We’re in a bit of a crisis situation at XLX020. Sometime last night we appear to have lost our XLX registration to ANOTHER XLX020 located in Sweden. While I’m not totally clear on why this happened, we did have a problem at our cloud provider this week. That problem somehow involved the system clock and created unusual timestamps on a bunch of critical files, including a file that tracks registration phone-home calls. Our cloud provider ended up migrating us on an emergency basis to a different physical host but we didn’t become aware of the clock/filestamp issue until today.

Note the file listing below with the dates “Oct 31 2223”!

$ ls -l | grep 2223
-rw-r-----  1 root  adm              7385678 Oct 31  2223 auth.log.1
-rw-rw----  1 root  utmp            13949952 Oct 31  2223 btmp.1
-rw-r-----  1 root  adm             46307238 Oct 31  2223 daemon.log.1
-rw-r-----  1 root  adm              4878047 Oct 31  2223 fail2ban.log.1
-rw-r-----  1 root  adm              1362469 Oct 31  2223 messages.1
drwxr-xr-x  2 drats drats               4096 Oct 31  2223 ratflector
-rw-r-----  1 root  adm             47846088 Oct 31  2223 syslog.1
-rw-r-----  1 root  adm              1322013 Oct 31  2223 user.log.1

Today, I noticed fewer connections on the XLX020 dashboard and started to investigate. Looking at the official XLX Reflectorlist I saw that there is now a reflector in Sweden which has taken our place in the 020 slot. It seems to have been implemented just today by SA7SVR

So right now, we’re in a bit of a limbo situation. I have reached out to SA7SVR as well as the XLX admin team in Luxembourg to see if we can get this remedied and get our registration back. I’m hoping that everyone will be amenable and sympathetic to the situation we were put in.

It also shows the underlying weakness in the XLX registration system. If a system problem, which has not yet been fully diagnosed or understood can lead to the revocation of a longstanding and popular XLX number, that is disturbing.

I’ll keep you updated.

73 de K2IE


Brandmeister is out there innovating again.

There’s a low latency VOIP solution based upon on an open source codec. The codec is called Speex and, as the name indicates, is optimized for speech. So bring on Mumble.

Mumble is a multiplatform VOIP client that makes use of Speex. It has been integrated into the Brandmeister backend and is currently being tested with a few select talkgroups…CNJHAM 31340 is one of them. You can also get on 3100 and some others.

So if you’re brave (and aren’t going to bug me or BM for support), give it a try. Your user ID is your CALLSIGN-DMRID (ex. N0CALL-1234567 and case matters) and your password is your BM hotspot security password. You’ll need to add as your server.

Remember, this is a test. This is only a test, so your mileage may vary.

73 de K2IE

Holiday Mystery on 472 kHz

I decided to monitor the activity on 472 kHz tonight (630 meters). I fired up WSJT-X and saw that at least one station was in the holiday spirit.

Somehow, the transmitting station managed to send data that displayed “Ho Ho Ho” right in the waterfall, without any decoding.

It is nice to see that there are still surprises out there on the radio. They did seem to also transmit a callsign but it was not readable to me. Any ideas about who this Christmas elf is?

73 de K2IE

New YSF Capabilities on XLX020

The Yaesu Fusion radios have a new capability when used with Pi-Star and an XLX reflector. You can now use the transmit DGID to talk on any of the enabled modules. Here is how it works.

Configure your Pi-Star instance to enable WiresX Passthrough.

Use the Wires-X function of your radio to connect to the XLX reflector of your choice. For example, XLX020 is #66396.

Set your transmit DGID to the number representing the module you wish to talk on. For example, Module A is DGID 10. Module D is DGID 13. See this link for the full list of modules.

Thanks to all those behind XLX and Pi-Star for making this feature available. YSF and XLX are now better than ever!