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.

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

Siriusly, My Radio Listening Just Improved

I’ve been a Sirius subscriber since before it was Sirius XM and before Howard Stern first fled from teresstrial radio to the birds. I stopped being a regular commuter in 2013 and so my listening time shifted from the car to home.

At one point I mounted a small antenna to the side of the house and listened directly to the satellites. This was soon replaced by my Logitech Squeezebox internet “radio”. At some point, Sirius made some protocol change for the internet streaming that broke the Squeezebox app and there was to be no fix. So I switched to a Grace internet “radio”. Then came another change and the Grace could no longer be used.

I’ve been a Google Home smart speaker user for a couple of years and it always seemed odd that Google and Sirius had not partnered on a solution. Well, Happy Radiomas to me! In November, Sirius XM rolled out Google Home device integration. After setting up the credentials in the Google Home app, Sirius radio fun is now as close as saying “Hey Google, Play Spectrum on Siriux XM”.

Thanks Sirius and Google for making it easy to listen to Sirius in the same way that I listen to many other audio sources. If you are not using your smart speaker to listen to the radio, you’re missing out.

Former shortwave listeners, especially, can find a wealth of programming from around the world. For example, you can get the lastest news from the BBC or updates on the fire situation in Australia from Radio Australia. Make a resolution to explore this capability in the new year and you won’t be disappointed. You can even request, “Hey Google, play the latest Glenn Hauser’s World of Radio podcast.”

73 de K2IE

XLX020 Supports Direct YSF

XLX020 has upgraded to Luc (LX1IQ)’s latest xlxd (2.3.1) software. We now support direct connections via the Yaesu YSF protocol.

Luc is in contact with the distributors of Pi-Star and the OpenSpot to have this capability added to the dashboards. In the meantime, there is a simple change that you can make to your Pi-Star configuration to connection to XLX020.

You’ll have to be willing to edit your Pi-Star /etc/mmdvmhost file. Look for the [System Fusion Network] stanza. You’ll need to change the GatewayAddress to xlx020.k2ie.net and the GatewayPort to 42000. You’ll also need to change LocalPort to 0.

[System Fusion Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=0
GatewayAddress=xlx020.k2ie.net
GatewayPort=42000
Debug=0
ModeHang=20

See on you Fusion!

73 de K2IE

D-Star & DMR Interoperability

If you’re a fan of either D-Star or DMR, you have probably noticed the proliferation of multi-protocol gateways. These gateways, such as the XLX020 system, permit users of radios of one type to communication with users of radios of another type. Multiprotocol gateways help to defragement the amateur digital landscape.

However, there can be issues if the transmitting operator is not registered on both systems. Have you been on a DMR radio and seen the transmitting party display as radio id 0? They are a D-Star (or Fusion or P25 or NXDN) operator who has not registered a DMR radio number.

For DMR operators who have not registered with their nearest D-Star gateway, transmissions could even fail to pass through the D-Star gateway to connected D-Star repeaters.

Therefore, k2ie.net highly recommends that all amateurs using any digtial voice mode register for BOTH a DMR radio id and with a local D-Star gateway, whether or not you have a corresponding digital radio.

You can register for a DMR radio ID at http://www.radioid.net. Hams in Europe and Africa should register at http://www.ham-digital.org.

If you’re not sure of your local D-Star gateway, you can follow the instructions at https://www.dstargateway.org/D-Star_Registration.html.

73 de K2IE

Duplex Hotspot Reliability Solution

So you’ve bought a new duplex MMDVM hotspot such as the one from N5BOC. You want to experiment with different DMR networks on each of the timeslots. You’ve set the recommended offset values in the MMDVM Expert settings. Yet every third or fourth PTT press results in a lost transmission. You’re so frustrated you want to throw your radio and hotspot across the room. Sound familiar?

I’ve spent a couple of months chasing down this issue, reading post after article on this subject. The consensus so far has been:

1) Update to the latest firmware.
2) Run the MMDVMcal procedure to minimize the BER.
3) Set the DMR preamble time on your radio to 960 ms.

After weeks of poor results, I came upon the solution that has worked for me (and for others) in a manual for the Anytone 878 produced by Bridgecom. Bridgecom recommends a DMR preamble duration of 100 ms.

1) Update to the latest firmware.
2) Run the MMDVMcal procedure (or enter the sticker offset
values for RXOffset and TXOffset).
3) Set the DMR preamble to 100 ms.

Well, I was testing on an Alinco MD-DJ5, a radio very similar to the Anytone 878. So I tried the preamble setting (called Wake Head Period in my software).

I have now achieved the mystical “five 9s” of reliability. I press PTT, I talk, my transmission gets received.

Ah, the sweet smell of success… And kudos to Bridgecom for the level of support that provide for Anytone 878 users.

This solution has worked so far with an Alinco DJ-MD5, a Motorola XPR, and a CS-700 (where I had to use 120 ms because the dropdown increments in steps of 60.). Oddly, my Hytera PD-365 does not support values lower than 360.

73