Buster 1.1 for D-STAR on macOS Sierra

BusterBuster is a macOS application for ham radio written by Jeremy McDermond, NH6Z, that allows Mac users to connect to the D-STAR network without a radio. It works with the ThumbDV™ USB dongle on the local machine or a network connected PiDV™ device (formerly DV3000).

Last fall, I noticed that Buster started to work erratically and wouldn’t connect to many reflectors. The good folks on the D-STAR Roundtable net indicated they were experiencing the same thing, and for many months the application was basically unusable. Finally at the end of May, the Buster 1.1 update was released through the app store.

The good news is that, functionally, Buster 1.1 appears to be working well on Sierra. I don’t remember all the specific problems with it, but I successfully tested connecting, transmitting, and receiving on REF, XRF/XLX, and DCS reflectors. I’m unable to test using a networked PiDV, so this just applies to a ThumbDV connected locally.

The bad news is that the host file still has problems. It’s more up to date than it was, but at least some of the addresses are (very) stale, and there are a lot of IP addresses being used instead of hostnames, which begs for bad links. This is the old “which hosts file is authoritative?” issue, but with a twist…

A look at the issue tracker for Buster on github reveals that the host file data is coming from ar-dns.net, a service intended to be a centralized host file and DNS lookup provider for all things D-STAR that, in turn, gets its data from various unmentioned sources. It’s a project by K7VE, the designer of STARnet. It looks like a nice system and cool project, but the source of the XRF and XLX addresses is problematic.

This means there will be some problems connecting from Buster. There already are.

Case in point: I host XRF010 and XRF011, both of which are XLX reflectors. Both have been up and listed in the Kings of Digital host file, on xrefl.net, and the automatic XLX Reflectorlist since late last year. They were submitted with hostnames and never bare IP addresses.

Buster’s hosts file, now derived from ar-dns.net, has both of these x reflectors listed twice – once as XLX and once as XRF – which is great. However, all four entries use IP addresses instead of hostnames. The IP address for XLX010 has never needed to change, so the XRF010 and XLX010 entries both work in Buster for now. But, XLX011 moved to a different server over a month ago and had to change its IP address, so it’s already broken in Buster. Additionally, the entry for XRF011 is a long-outdated IP that resolves to a host in Germany. So XLX011 won’t connect using either XRF011 or XLX011, and for two entirely different host file related reasons.

Old Problems

What’s not new is that Buster uses an XML-formatted host file. This is probably the right thing to do in Objective C, but it means there’s no easy way to do a quick copy/paste of the entire reflector list from a more current data source. So reflectors that won’t connect require investigation by the user on a case-by-case basis, and the individual addresses then need to be updated directly in the xml file. Somebody could easily script a little utility that pulls down the KD host file and converts it to xml for Buster, but the fix really should be with ar-dns.net’s data — ar-dns.net could be the solution to this and many other related D-STAR problems (provided it is a robust system with redundancy), but the data needs to be sourced better, as mentioned above.

Even if the ar-dns.net data gets straightened out, Buster doesn’t have the ability to download host file updates on demand, a la DStar Commander, so host file updates will continue to be dependent on Buster’s author pushing app updates through the app store.

Hopefully this doesn’t sound like I’m complaining. I’m very happy that somebody took their own time to create a solid macOS D-STAR client, and I don’t personally have a problem changing host addresses when needed – it works well for me. I’m just pointing out some issues that could easily trip some users up, and they have more to do with the ongoing host file issue than with Buster itself.

The Road Back to Radio – Digital Voice

Hotspot for DMR, D-STAR, Fusion, and P25

Hotspot for DMR, D-STAR, Fusion, and P25

There are more than 700,000 FCC-licensed ham radio operators in the United States, but only a small fraction are actively engaged in the hobby at any given time. I’m often one of those inactive people, but every few years I get interested in some new area of the hobby.

Five years ago it was D-STAR, a digital voice mode. This time it’s DMR (Digital Mobile Radio), another digital voice mode mostly used for commercial and public safety applications that’s being somewhat awkwardly retrofitted to the amateur radio paradigm. While the learning curve with DMR is a bit higher, the low cost of entry makes it an easy gamble. It’s not that digital voice is necessarily difficult, but a good portion of the documentation and know-how for both modes is hidden away in haphazardly organized “Files” areas spread across unconnected Yahoo Groups, most of which require membership. Anybody approaching DMR or D-STAR with simple and reliable methods like scouring Google for technical information is in for a frustrating experience.

Roadblocks aside, my venture into DMR circled back through D-STAR and all the development I’d missed over the past several years. There’s a lot of symbiosis between DMR and D-STAR activity, mostly in the form of the little low-cost Raspberry Pi computers. My first goal was to marry these two modes in a single Raspberry Pi box with as many options as possible. The result is the hotspot pictured above.

The hardware consists of a Raspberry Pi 3 B board, a DVMEGA board seated on the GPIO pins, a DV4mini attached directly to USB, and the red DVAP attached to USB by cable.

Also pictured are the ultra-cheap Tytera TYT MD-380 radio for DMR, the Icom ID-51A Plus for D-STAR, and the Yaesu FT2DR for System Fusion.

The software starts with the latest Western D-Star image using Raspbian Jessie Linux, including ircDDBgateway and D-StarRepeater for use with the DVAP and DVMEGA, and the DV4mini application. Then I added MMDVMHost for use with the DVMEGA on DMR, D-STAR, and System Fusion. The SD Card image also functions fine on the Raspberry Pi 2 B board.

The DVMEGA board along with the MMDVMHost software is at the heart of this hotspot and can be used for all three modes. Using radio control alone, it connects to the BrandMeister DMR network, the YSF Fusion reflectors, and any D-STAR reflector. The DV4mini will handle D-STAR and DMR, but I’m mostly using it to connect to the DV4mini FCS System Fusion reflectors. It also technically makes this an APCO25 and DPMR hotspot.

Since most DMR and D-STAR networks are closed-source systems, there’s really not much else to do at the moment other than hope for new developments and enjoy some interesting QSOs with other hams in the meantime. One possible exception is the D-STAR X Reflector network. It uses open source software and operates without any real central authority. I’ve set up two XLX reflectors, one for WARN and one for W8IRC – but without an automatic DNS distribution scheme, I doubt the X Reflectors can ever gain full traction as a mainstream competitor to the original DPlus network. I’m on board to try though.

(Originally published on June 21, 2016.)

Edit 2016-08-02: I bought a Yaesu FT2DR System Fusion rig, so the DV4mini is now getting lots of use again in the hotspot.

Edit 2017-02-25: I purchased an Icom ID-51A Plus to replace the old Icom IC-92AD boat anchor for D-STAR. Much better!

Thanks to Andrew K4AWC for nudging me in the direction of DMR.

Resurrection of a Personal Weather Station

Davis Vantage VueI recently ran across the Davis Vantage Vue compact weather station in the latest AES amateur radio catalog and decided to buy it to replace my old Scientific Oregon WMR-968, a station in total disrepair.

Putting the new station together turned out to be easier than taking the old one apart. Besides being a huge spider convention, the bolts on the old station were so badly rusted onto the mast that I finally had to hammer the old hardware off into pieces.

Despite the Vantage Vue’s low cost, connecting it to a USB port ends up adding an extra $150. That’s for the hardware adapter and a software package. A standalone Ethernet-connected version is also available for $250.  The WeatherLink software appears to be from the Windows 95/98 era, which is good enough to confirm that the station’s data transfer is working, but that’s about it.


I had used wx200d on Linux with the old WMR-968 station. It provided a reliable daemon and included everything needed to graph data, report to Weather Underground and CWOP, and send packets out over the local APRS network via RF on 144.39 MHz. I had to do some extra perl scripting to glue it all together, but that was part of the fun.

The next task was to find something similar that would work for the Vantage View.  “wview” seemed promising at first, but I could feel the inevitable time sink of dependencies and troubleshooting that a lot of Unix based projects become. Then I found a modest sounding package called weewx that was almost too easy to overlook. It’s a thoughtful system written in Python by Tom Keffer. I put it in place, set a few variables, installed the init.d script, and that was that. It provides a comprehensive page of data that can be used in place or automatically FTP’d to a remote server. It reports to Weather Underground, CWOP (APRS-IS), and PWS Weather. It’s also well templated and object oriented – all very extensible in general.

APRS – Back to Radio

The only thing left was how to get it onto the local APRS ham radio network. I got my old Kenwood TH-D7AG working again, hooked it up to the server using a serial-to-USB adapter, and put it in standard TNC mode where it’s bypassing the built in APRS and simply receives regular TNC commands.

Because the CWOP routine in weewx already creates the same packet needed for APRS, it seemed silly to rewrite anything. My first instinct was to use the perl script I’d written for wx200d and have it read directly from weewx’s SQLite database. It was immediately clear that this was a kludgy workaround and not a true solution, so I put a message on the weewx Google Groups forum.  I immediately received direction from Tom on how it might be best integrated and it only took a few hours to get it working. I’ve made it available on github in case anybody else can make use of it.


Okay, it’s actually more of a view-of-sky-somewhat-obstructed-by-trees-cam, but I really wanted to do a real time view of the sky this time. It’s the Foscam FI8918W wifi camera in an upstairs window. It has a built in web server that provides live images and video, and the ability to remotely pan and tilt from any Internet connected device. It also makes a nice way to continue watching a storm long after nearby lightning chases everybody inside. (Edit: There are now three weather cams in place.)

The old weather station lasted three or four years, and I hope this one will last longer. But either way, it will definitely be easier to replace when the time comes.

– Brad N8QQ