Building ASL on Debian Buster

Some AllStarLink sysops have expressed the desire to build an AllStarLink system on a modern Debian operating system. I took the time to document a working build process for the 020 Digital Multiprotocol Network and then Scott <KB2EAR> volunteered to create a shell script to automate the process. We are happy to share our work with the amateur radio community.

Please note that this process currently works only on the x86 architecture. It fails on a Raspberry Pi OS Buster system.

Hopefully this effort will fulfill a need for others in the AllStarLink community.

73 de K2IE

When Customer Service is Not Optimum

My cable internet provider is Altice USA a/k/a Optimum Online a/k/a Cablevision. Over the years they have generally been reliable, at least in my experience. However, I recently had a terrible customer experience with this company. The matter was ultimately remedied, but only after I escalated matters to the fullest extent possible.

In addition to internet services, I get a Broadcast Basic package of mostly over the air channels. I don’t actually need the package because I have excellent free over the air (OTA) reception of all of the NYC based stations. Much of the regular programming that we watch is via streaming services and I can always get CNN or MSNBC audio via TuneIn or Sirius XM. But, the Broadcast Basic service also provides the essential public service broadcaster, CSPAN.

The main reason that I take the package is that at some point it turned out to cost the same for a TV/Internet bundle as the Internet alone. So why not? The package also provides some decent music channels provided through a service from Stingray.

On or around May 22nd, in the midst of COVID-19 isolation here in New Jersey, a large number of the channels in my TV package disappeared. And so began 21 days of dealing with mostly outsourced, ignorant and even obnoxiously overly-gracious call center representatives (CCR). They wasted about 20 hours of my time and did not solve my problem.

This is a good time to mention that I don’t have or need a cable box. I own a TiVo DVR with lifetime service plan. The Tivo box has a CableCard slot. It is a nice compact package.

On day one of the outage, almost all of my channels disappeared for a time. Within hours, the broadcast HD channels had mostly returned. Then I began to notice that some channels were still missing. When I phoned customer service, I was told that they were aware of an outage and that I would be called when it was cleared. No one called.

This was followed by call after call. I was told that my problem had been resvoled, when it had not. I was told to reboot my cable box which I do not have. I was told to uplug and replug my TiVo box. I took many passes through an interactive voice response (IVR) system that does not understand CableCards.

At various points, I figured out how to bypass the IVR’s automated troubleshooting process and get to a human rep. The reps repeatedly paired and unpaired my CableCard without acheiving the desired result. Something must have changed on the Cablevision network.

I started talking to others in my area and learned that my problem was not unique. As I researched the problem, I suspected that the missing channels had been changed over to a switched digital video (SDV) protocol. SDV allows the providers to save bandwidth by sending less frequently used video out on demand only. Unfortunately, CSPAN does not seem to be viewed as often as it probably should be.

It seems that a CableCard cannot received SDV channels. An external box termed a tuning adapter is needed to receive the SDV channels. The only call center represtative that might have understood the issue was so obnoxiously and facetiously gracious that it was painful to speak with him. Oh Mr. Dan, speaking to you is the high point of my day…that sort of thing. Repeatedly. I would characterize this as a culture clash with the subcontinent call center.

He offered a tuning adapter as a solution but quickly retracted that offer, saying instead that he wanted to send me new cablecard or to dispatch a technician to my home to troubleshoot my cable. Nope, no way, not in the middle of a worldwide pandemic. No thank you.

Around day 17 or so of the outage, my daily call to the less than Optimum customer service revealed that I could obtain a tuning adapter to see if it solved my issue. I was told to go to the Parlin store to pick it up. I asked the CCR to call the store first to make certain that they had one in stock and that I was not wasting a trip. I have not been out on many shopping expeditions since the 21st of March and I would have preferred that they ship the tuning adapter to me. I was told that they can’t, which would have been more accurate had they said they won’t.

The CCR assured me that a tuning adapter would await me in Parlin. After a 20 minutes drive, I arrived outside the Parlin store. Customers were not being admitted but there was a gentleman at the door answering inquiries. He politely informed me that the had not seen a tuning adapter in that store since November.

At that point, my only option was to go vertical. I filed an FCC complaint, a NJ BPU complaint, and found email addesses for a number of corporate executives. The next day I received a phone call from Tom, a nice fellow who works for Corporate Customer Relations.

He was very apologetic about the company’s poor response to that point. He acknowledged that the outage was indeed caused by a conversion of certain channels to SDV. He arranged for a tuning adapter to be delivered to my house and asked me to call him personally when it arrived to have it provisioned. That happened yesterday, on schedule, and after a 21 day outage I now have all channels to which I am entitled.

This was a major customer service failure that could have been prevented had Optimum provided clear scripts and training to their CCRs that would have immediately pointed them to a solution for missing channels when using a cablecard. Engineering should also be providing the CCRs with a clear change calendar that shows when regions are being converted to SDV or any other major changes are being made so that related incidents are immediately associcated.

And there is a lesson here about outsourcing. It may be cheap, but you get what you pay for. And in the end, it took a technically knowledgable guy from Long Island to solve my issue, not a contractor in Bangalore.

Only a virtual monopoly can get away with providing such poor service and still survive.

Amateur Radio Guide to Digital Mobile Radio

A comprehensive introduction to DMR is available to hams at no cost, thanks to the efforts of John Burningham <W2XAB>. His “Amateur Radio Guide to Digital Mobile Radio” won the 2016 Technical Achievement Award at Dayton Hamvention and the second edition was published in 2019. Even if you think you know how DMR works, this guide is full of useful information.

If your view of DMR is limited to the perspective of Pi-Star and Brandmeister or TGIF, this free book tells the rest of the story in its 27 pages. It is an easy read and will enhance your DMR knowledge.

Hotspot Frequency Guidance

I recently spoke with a fellow who was trying to use his hotspot on a frequency around 438 MHz. He wasn’t having much luck and with good reason. The MMDVM firmware blocks usage on all frequencies between 435 and 438 MHz. The block was implemented because 435-438 MHz is a suband used by the amateur satellite service and some amateurs noticed an increase of terrestrial interference with satellite communications.

Another ham that I spoke to is using a hotspot frequency that is also the input of several coordinated repeaters in my area. This is also not a good idea as it can also create interference, especially when operating a hotspot while mobile.

Here is my list of recommended simplex hotspot frequencies that is not likely to cause interference to other operators, repeaters, or satellites:

145.51 MHz
441.000 MHz
446.500 MHz
446.075 MHz
433.45 MHz

Most hams seem to set the admit criteria on their radios to Always for use with simplex hotspots. I strongly recommend that you use Channel Free instead to reduce the possibility of doubling.

73 de K2IE

The Big List – Connecting to CNJHAM/XLX020D

Last Updated 28 July 2021

D-Star Callsign RouteCNJHAM via Quadnet
D-Star ReflectorsXLX020D
XRF020D
REF020D
XLX020D preferred
XLX DMRXLX020Module D
PC 64004 (Pi-Star)
XLX YSFXLX020DModule D
Wires-X *04004
D-Star RepeatersNJ2DG-A
NJ2DG-C
Fulltime
Brandmeister DMRTG 31340CNJHAM
TGIF DMRTG 31340CNJHAM
NJ-TRBO DMRTS1/TG 31340
PTT 10 minute timeout
Martinsville, NJ
 447.075
Montanna Mtn, NJ
 444.29375
Wayne, NJ
 439.7875
Perth Amboy, NJ
 440.75 (CC9) Fulltime
Hoboken, NJ
 448.275 (CC3)
Elizabeth, NJ
 449.925 (CC 3)
Fusion YSFYSF 44977US CNJHAM
DTMF 44977
Wires-XCNJHAMDTMF 28255
Fusion RepeatersDGID 50Martinsville, NJ
 441.4
P25TG 31340Pi-Star
NXDNTG 31340Pi-Star

020 Project Dashboards

XLX020http://xlx020.k2ie.net
REF020http://ref020.dstargateway.org

The Rules

Please wait one second after pressing PTT before speaking and wait one second after speaking to release PTT. This will ensure that there is no clipping of your first or last words.

All users of the 020 Network connections are required to have both a DMR ID and to be registered on the D-Star Gateway. It doesn’t matter if you don’t own a radio of that protocol. We are a multiprotocol system and by registering on both DMR and D-Star you are doing what needs to be done to be heard across all network connections.

73 de K2IE

Duplex Hotspot Reliability Revisited

Last August, I presented a solution for the “lost transmission” syndrome when using an MMDVM duplex hotspot. Several members of the 020 Digital Multiprotocol Group and I remain dissatisfied with our overall user experience. Granted, fewer transmissions are being lost than at first, but overall the number of transmissions during a longer QSO that fail to properly negotiate with the hotspot are higher than we’d like.

Earlier this week, 020 member Scott <KB2EAR> did some further digging and came up with aditional ideas found on the interwebs. I’ve taken these recommendations, added some others, and tested extensively. Here is my new set of recommendations for MMDVM duplex hotspot reliability when using DMR. This supersedes my article from August 29, 2019.

1) Update to the latest firmware.
2) Run the MMDVMcal procedure to minimize the BER
3) Set the MMDVMHost modem TXDelay=50
4) Set the MMDVMHost modem DMRTXLevel=55
5) Set the MMDVMHost DMR TXHang = 20
6) Turn off any mode other than DMR to avoid protocol scanning negotiation
   issues.

I withdraw my earlier recommendation to reduce the DMR preamble. After much consideration, it seems to be unnecessary, with no clear benefit.

So far, using these setting on 2 different N5BOC duplex hotspots have yielded excellent results and reliability. Negotiation failures are now the rare exception. Tests were conducted with an Alinco DJ-MD5, a TYT MD-380, a CS-700 and a Hytera PD-365. Give these settings a try and let me know how they work for you.

73 de K2IE

X10 Firecracker

Does anyone still make use of X10 powerline control devices? X10 has been largely replaced by more modern wifi based home automation devices, but I still have a few that control lighting.

I recently upgraded my main home/office server to Fedora 32. Fedora dropped python2 from new systems because python2 will be considered obsolete by the end of 2020. I have a serial based device called the X10 Firecracker which I use for wireless on/off control. The Firecracker is controlled by a python script run via crond, the system scheduler.

The script was written long ago by someone else in python2. While doing a post-upgrade checkout, I found that the firecracker.py script no longer functioned because I no longer had python2 installed on my system. So, it was time to port it to python3.

Fortunately, the porting effort was trivial. I have shared the results in my Github repository in case anyone else needs it. And if you’re still running any critical functions using python2 it is time to port them to python3.

Icom Terminal Mode on XLX020

There’s an exciting new development in the XLX reflector world. XLX reflectors now officially support Icom Terminal Mode. If you’re not familiar with terminal mode, it allows you to communicate with the DSTAR world via the internet from your radio. No separate hotspot or dongle is required and since RF is not used, no antenna either.

Terminal mode is supported by the newer Icom radios, including the IC-9700, ID-4100, and the Plus model HTs. If you have a radio that supports terminal mode and want to give it a try, set the host to xlx020.k2ie.net.

Thanks to Marius (YO2LOJ) for cooking up the code and submitting it to the xlxd project. It is great to see that the open source model is helping to advance digital amateur communications.

73 de K2IE

Pi-Star, XLX, and YSF

If you thought that the big amateur radio news of the day is that Andy Taylor has pushed Pi-Star 4.1.0 to general release, I’ll have some other news for you in a moment. But first things first.

If you’re already running a 4.1.0 RC (release candidate), please logon to your pi-star device via ssh and issue the following commands:

sudo pistar-update
sudo pistar-upgrade

If you’re running a pre-4.1.0 system, you’ll need to:

  • Backup your configuration
  • Download the 4.1.0 image from the Pi-Star website
  • Unzip the downloaded file
  • Burn the .img file to an SD card
  • Copy the zip (don’t unzip) of your configuration backup to the SD card
  • Boot the new image

The bigger news today is that Andy has pushed the new G4KLX YSFGateway code into the Pi-Star image. This means that you can now directly connect to XLX020 and change reflector modules from your Fusion radio using Wires-X Passthrough commands.

You’ll have to enable the WiresX Passthrough slider on the Yaesu System Fusion Configuration section of the Pi-Star web gui. If you have an FT-70DR or another radio with an upper case only display, enable the UPPERCASE Hostfiles slider in the same section.

The process may vary a bit between radio models. The general idea is that you first initiate a Wires-X sequence to connect to XLX020. Next, you exit Wires-X mode and initiate another Wires-X sequence to connect to the module of your choice. If you just want to talk on module A, the 2nd connect is not necessary as you’ll default to module A.

Some radios, such as my FT-70DR, do not pull down a room list and you have to manually enter the module number. In that case, use 04001 for module A, 04002 for module B, and so on.

Have fun with this great new feature that makes the most of Pi-Star, XLX, and Yaesu Fusion.

73 de K2IE

Amateur Radio Paging

Did you know that radio amateurs have our own paging network? Really, pagers, those slim devices that you carried on your belt back in the 1980s and 1990s. The devices with batteries that would last for weeks!

The Decentralized Amateur Paging Network was built by hams to provide the backend infrastructure to send messages to your personal amateur radio paging device. And if you’re running Pi-Star, you already have what is needed to turn your local hotspot into a POCSAG paging node on the DAPNET!

You also need need a pager. The AlphaPOC 602R seems to be a popular model that will work on the 70cm amateur band. The default paging frequency seems to be 439.9875 MHz and that is what Pi-Star will use unless you change it.

I wanted to play around with ham radio paging but, since I don’t have a ham radio pager available, I improvised. Isn’t that what amateur radio is all about? I wrote a python3 program to take inbound pages to my RIC (pager identification code) and send them to my email. I’ve shared the code on github and invite you to use it, comment, and contribute.

How can you use amateur radio paging? DX spots, APRS weather alerts, and solar activity are a few applications that come to mind. Share your ideas and be sure to send me a page via the us-nj transmitter group.

73 de K2IE