Internet connection issues, FYI

[N5CQ]

For the last year or so, I have had an increasing number of 'connect' and transfer issues with my K3 remote setup.   The most striking is of course the connection dropping out entirely and the control unit announcing this fact with its "error' sound like an old modem that fails to connect. 

Sometimes I could re-connect immediately, but other times it would be 15 minutes or more before I could reconnect, and a few times not until the next day.   The MTBF on a successful connection was a few hours before it dropped.  Sometimes I could connect and have no receive audio. Sometimes I could connect and receive but had no transmit audio. 

Even when I could not connect with the RRC units I could always access the radio unit via the web interface and all the other devices at the radio site, including the router and the 1269 antenna switch.  Sometimes the Windows 'remote desktop connection' would drop out too, with about the same MTBF.

I tried different ports and settings on the RRC units with no change. All the diagnostics I could run showed everything to be great (with 60 mbps down and 12 up at the 'control site' and 18 mbps down and 1.2 mbps up at the 'radio' site.  Latency was about 27 ms and 'jitter' about 7 ms between the two sites. The cable company support line testing said everything was fine, and they 'could see no problems'. I even switched out to new and upgraded cable modems at each site. No help. I tried a different router at the radio site. No change.

Finally I told the cable people that if we couldn't find the problem, we could just drop their service. After they confirmed that I had the latest and greatest modems on each end, they finally sent a knowledgeable tech out to the radio site.

He confirmed that the modem was working fine, then ran a diagnostic program on his laptop that he said was 'more sensitive' than what they could run from the main office. He said the readings on the 'down side' were 'squirrely' and variable.   After some other test that I inferred was some kind of TDR, he said the problem was with 'the drop'.

He then climbed the pole and discovered that the outer jacket of the cable had been abraded on the pole,and in several places on the way down to the ground, perhaps by falling limbs or other debris during a windstorm.  Water ingress and random drying cycles were his working hypothesis.

He ran a new cable from the 'mainline' all the way to my modem. The diagnostics now looked 'solid'. Since then (about ten days ago), no problems, no dropouts, no issues at all. Even the Windows RDC stays connected until I disconnect it by choice. Fingers crossed. Maybe grinning a little. At some later time, a crew will come to bury the new cable.

Next project is the killing off the occasional digital noise on my transmit audio - next thing is to try connecting the mic direct the RRC instead of via the front panel of the K3 mini.

73 John N5CQ

[Jan (Microbit)]

Thanks for sharing! 

[w9ac]

John,

Access to a spectrum analyzer is indispensable when diagnosing drop cable problems. Generally, only headend techs have access to the better analyzers. The tech ops group use simple analyzers that have poor level and resolution bandwidth.

The spectrum analyzer should be set to display dBmV and not dBm. The current DOCSIS standard calls for cable modem input level between -5 dBmV and +5 dBmV.  Outside that range and strange issues develop. Most cable modems now include basic a basic analyzer and report input level across DOCSIS channels, typically between 4 and 8 channels are used in NA cable systems.

The internal analyzer can be accessed from any web browser on the network. However, level is sampled at periodic intervals and does can give the technician or user a real-time glimpse of the operating conditions. For that, a real spectrum analyzer is needed.  For years, the standard device had been the HP 8591C.   I recently acquired Agilent N1996A and HP 8560E analyzers. These are 50-ohm analyzers but can be used with a high-quality 75:50 wideband transformer to ensure accurate dBmV readings.

It's very important to watch not only the baseband spectrum where the QAM downstream channels operate, but also look at the spectrum near 50 MHz where RF ingress is more pronounced.  If the system has been equalized properly all the way to the user end of the drop cable, there should be little level change from 50 MHz to the upper limit of the system which often beyond 750 MHz. Any unusual pass and ripple is an indicator of leakage or other connectivity problem.   

When I worked in corporate engineering at AT&T Broadband, then later Comcast, probably 90+% of coaxial problems were at the drop.  When you consider every potential point of failure on an HFC cable system, it's a flat-out miracle it works at all.  I was knee-deep in resolving these issues 20 years ago when the company was just starting to launch cable internet service and developing data sensitivity analysis.  In fact, I wrote a chapter in AT&T's Network Architecture Manual that addressed plant certification prior to declaring newly upgraded plant as being service and market ready across three lines of service: video, data, and telephony.

In the early years, the most significant problem was on the upstream where QPSK data typically runs between 25-30 MHz. Shortwave broadcast ingress, and RFI from 11m, 12m and 10m ham operations all played a part in reliability until we developed hardened plant procedures. Of course, these problems can still persist today, especially at the peak of the 11 year sunspot cycle. 

Cable modem service reliability is still very much affected by ingress on the upstream channels.  A typical cable plant serves anywhere from 50 to 500 homes from a fiber node.   From the convenience of one's home and with a broadband RF signal/noise generator, it's possible to shut down service on an entire node since the return path RF is summed together.  Fortunately, that's beyond the capability of most subscribers, and there have been few reported cases of malicious interference in this form.

Paul, W9AC