AuthorTopic: Failing MSAN Ports (Read 1707 times)

I have a TalkTalk ADSL service and in November 2017 I had a fault where I would lose sync both randomly and when the phone was picked up or rung. There was also data noise audible on the phone when the router was connected. I assumed this was a high resistance fault on the line, and indeed the remote fast tests did sometimes (but not always) state the presence of a CIDT fault. However after 1 PSTN and 2 SFI Openreach engineer visits the fault was found to be with the port on TalkTalk’s MSAN in the exchange. I was changed to a different port and all was well.

However in April 2018, after my router had been in sync for 160 days, the same symptoms reoccurred. A fault was reported and I gave the attending PSTN engineer the name of the SFI engineer who ultimately found the fault last time. The SFI engineer told the PSTN engineer what to test for, and it was once again found to be the MSAN port. Once again this was changed and all is now well.

The engineer said it is very rare for a port to go bad, so two going bad suggests something else is causing it, perhaps some other undetectable fault on the line. The engineer left and returned to his van, and I reconnected my internal wiring and router (I had been using the TalkTalk provided HG633 router and a basic corded phone plugged into the test socket via a dangly filter for diagnostic purposes, but my normal set-up has a data extension from a MK3 SSFP and a TP-Link VR600 router).

From the van the engineer initiated a line test (presumably this is standard procedure when closing a job) and got back a CIDT fault. He tried this 5 times and got the same result, so returned to the house and asked me to remove everything again. On initiating a final line test, no fault was found so he closed the job, but commented that perhaps the house wiring and/or the VR600 is bad and is causing the MSAN ports to go bad.

The line seems perfectly stable now, and I did try swapping to a different pair on the data extension which made no difference to anything. But this has got me wondering, can bad wiring / the VR600 in the house cause MSAN ports to go bad over time (excluding things like shoving 240V down the phone line which would presumably blow up the MSAN port in an instant)?

As you have checked your data extension wiring and found no obvious fault, then there are just two other items to be ruled out. The SSFP which, as far as the circuit is concerned, is a passive device and the TP-Link VR600.

All modems will connect via a high-pass filter which, at the very basic level, can be regarded as a capacitor in each leg of the pair. I am at a loss as to what sort of fault a modem might possess that results in the associated MSAN port to be zapped.

If I was in your situation, I would test by having the VR600 powered up but disconnected from the circuit and then checking for any spurious voltages across the pair, also between each leg of the pair & a good earth. (Prerequisites: a DMM and a good earthing point.)

Before the fault occurred in November I was actually using a MK2 SSFP. I changed this to the MK3 just after the fault was fixed, so I think this rules out it being this. Good thought regarding the check for spurious voltages appearing from the DSL input to the VR600. I'll check tonight.

The phone line is about 1.5km long and has a FTTC cabinet just outside the exchange and an AIO FTTC cabinet around 900m from the exchange. The BT wholesale ADSL checker predicts an ADSL sync speed of 14mbps. In reality I'm syncing at 17.7mbps, and DSLstats now shows an arrow straight and flat SNRM, so I'm inclined to think the whole metallic path from the exchange to the router is in perfect condition.

There weren't any notable external conditions in November when the port went bad, but in April the day the problems started we had around 3 short duration (say 2 seconds) power cuts.

So 4 months down the line and I'm back with the same issue. Given the identical symptoms I'm guessing that I now need to be moved to yet another MSAN port (the 4th)! I now find it very hard to believe that I was just unlucky with getting two bad ports in a row, so the theory has to be that something is causing this.

So before I get Openreach on the case (via TT), would the knowledgeable people on this forum mind taking a look at my connection statistics and let me know if you have any theories.

I would be tempted to check, once again, for the presence of alien voltages (both DC & AC) whilst all your equipment is connected as normal. B-wire to Earth, A-wire to Earth and B-wire to A-wire. Then disconnect everything by removing the lower front face-plate and the SSFP and repeat the measurements on the incoming pair. Finally, repeat the measurements at the plug where your own wiring connects to the NTE5.

Looking at the various plots, I am not sure what to make of the situation. They clearly show a sickly circuit.

I now have the results of these measurements, and they are quite interesting.

Everything connected / V

A-B

A-E

B-E

DC

-49

-50

-1

AC

*

*

1

Disconnected - Internal / V

A-B

A-E

B-E

DC

0

0

0

AC

0

10

10

Disconnected - External / V

A-B

A-E

B-E

DC

-49

-50

-1

AC

*

*

1

*: Gives a wildly fluctuating reading in the range 20-200V on my Amprobe AM520-EUR DVM at a frequency the DVM cannot determine. Repeating this with a generic cheapo M-830B DVM gives a steady 110V AC, the mean of the range given by the Amprobe. This value is achieved on both the 500V and 200V ranges of the M-830B.

Likely the 10V to earth on the internal wiring is just inductive pickup. The measurements indicated by * are odd though. Unfortunately I do not possess a scope, a true RMS DVM or a DVM with a low impedance mode; all of which may well reveal some more information about this.

I'd have thought any stray voltages on the line would be detected during a pair quality test on the JDSU as part of the test for a battery contact fault. This part of the PQ always passes, but I wonder if the JDSU checks for AC. It may only be DC which would explain why this is not being picked up. Perhaps Black Sheep might know. The alternative is that these measurements are just an artefact of what the TT MSAN puts on the line as measured by a DVM. If someone with a TT ADSL service is able to repeat these measurements this may confirm/disprove this.

A quick comment. What you have "labelled" A and B are actually swapped over. There is always a 50% chance that the pair has been inverted as the polarity is no longer considered to be relevant. With the DVM +ve probe connect to a good earth, the B-wire is the one which shows the greatest voltage. So your first table is actually --

Everything connected / V

B-A

B-E

A-E

DC

49

50

1

AC

*

*

1

-- and likewise for the others.

So I think you have found the reason why the MSAN ports are going faulty, there is a high alien AC voltage present on the pair.

As a user of a TT (LLU) service, I can say that your results are definitely abnormal. I see --

Indeed. It's rather satisfying to have found something that could be causing this problem. Thanks for the suggested measurements, I would never have thought to check for stray voltages on the incoming line.

Yes, I thought the DC voltages seemed to be the wrong way round . As far as I remember, when I originally installed the data extension off the SSFP the IDC labelled 'B' was the one with -50V on it, but now it's the IDC labelled 'A'. I guess they must have got swapped somewhere during one of the previous Openreach visits. Presumably this doesn't matter for anything though.

The only mystery remaining now is why this has never been picked up before. I found a video (https://www.youtube.com/watch?v=L0Q0Q7HDZ_s) showing a JDSU PQT taking place, and it does check for AC voltages. This part of the PQT has always passed however. I wonder what the input impedance of the JDSU is when measuring this. I should be able to borrow a true RMS DVM with a low Z mode from work, so should be able to get a little more info later on.

One theory I've got is perhaps this voltage is not there when the 'test conditions' are applied prior to the PQT being done. I don't have much of an idea what exactly these conditions are, but Openreach engineers have mentioned the line being connected to the test head. Presumably this means it is also disconnected from the MSAN, 50V supply and ringing generator. If, for example, the ringing generator has gone bad and is putting this voltage here, then under test conditions the voltage won't be there.

In any case, the plan now has to be to get Openreach here again and show them this, then let them investigate.