Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Bald_Eagle1]

It is the alternating "kick" of the ringing voltage that will "punch through" the corrosion / oxidation / minute air gap of a "manky" joint not the RF signal from a TDR tester.

Ouch!

That gave me quite a bang

I wish I could explain then why the 301C sees no differences when my line is O.K. & when it is playing up like this.

Maybe all will be revealed on Friday 

[burakkucat]

I wish I could explain then why the 301C sees no differences when my line is O.K. & when it is playing up like this.

I wish I could have paws-on experience of your line. Only having remote feed-back is not conducive to good fault-finding. 

Maybe all will be revealed on Friday 

For your sanity, that would be good. 

   Hmm . . . not quite the first anniversary of the installation. 

[Bald_Eagle1]

   Hmm . . . not quite the first anniversary of the installation. 

Nearly, 24th June will be its birthday.

It still all points back to whatever was done to restore my 4 day loss of service last July.
Everything seemed pretty much purrfect until then.


Just think how much grief, time & therefore cost could have been saved if the "right" job(s) had been carried out at the outset.


Mind you, we wouldn't have needed to develop any graphing scripts between us if that had been the case .

[burakkucat]

Mind you, we wouldn't have needed to develop any graphing scripts between us if that had been the case .

I see you've found the "silver lining"!

Without the problems currently present with your line, you would not be a Kitz forum member regular and thus posting here. 

[Bald_Eagle1]

Without the problems currently present with your line, you would not be a Kitz forum member regular and thus posting here. 

True, but my house refurb would have been finished months ago & I would now be able to relax on the patio with a nice cold lager or 3 after a tough day at the office 

[eliw]

Since the engineer visit our service has degraded significantly... and strangely we can't run the BT online check on the line anymore (we get a message saying "Sorry, we are not able to test or provide an update on this line.") and if you try and do the check via 150 it fails as well.

Our attainable rates have gone from 58mb to around 50mb now .. and SNRM will now drop gradually until the modem resyncs (will take around 10 hours for this) with everytime a little drop in the IP profile... we have never had a single resync for the 14 days prior to the engineer visit and SNRM was always stable around 6.2...

A new thing = When we pick up the phone now we lose sync ... when we put the phone down we lose sync .. and during the call it resyncs and the SNRM goes to around 7.6db from around 6db - and I can certainly hear some noise on the line now when on calls ---> 

Have we been screwed ?


==============================


Right some progress ..

I removed the new openreach FTTC faceplate, and plugged the modem straight into the master socket - and the connection is back to some kinda normality (attainable rate back up to 55mb and sync rate is highest Ive ever seen at 54mb SNRM around 6.4db)

Reconnect the face plate and only connect the modem - same as above good connection.

Connect the phone no problem .. but make a phone call and hell breaks loose (lose sync ect..) Used a different hand set and still same thing. Now the modem reconnects at much lower rates and attainable and SNMR are silly low.

Only way to fix it again is to remove face plate and do the same again.

Is it a case of a bad filter on this face plate ? Why does it have to be removed before the line is back to normal after a phone call is made ?

I'd love to be doing something else at midnight 

================

Update ... 2 hours after last forced resync

Have not made a phone call .. SNRM not dropping anymore like it used - solid around 6.2db - no resync. CRC count is 3000 (only 1 up) HEC is 250 (0 up) - is this considered a high CRC count ?

Safe to think the faceplate filter is dodgy ? or is there something else thats causing the resyncs when phone is used ? (remember after using the phone only removing the faceplate would bring the connection to a decent state).

[Al1264]

All the symptoms point to the filter faceplate.  Have you got any extension wiring off it though?
A decent ADSL filter should work perfectly well with VDSL so you could try a known good dangly filter with your telephone (If really concerned you could 'double filter' the phone).

[eliw]

Thanks for the answer.

I did use another filter and even double filtered to no avail...

What's disturbing is that even with the phone unplugged and the modem connected straight into the test socket (we do not have any extensions connected to this line), the connection will receive a huge amount of CRCs (millions) when I call myself with say a mobile... If left to ring long enough it will occasionally force a disconnect.

We have another BT line here using the other 2 wires from the same cable (going to another NTE5 socket), no broadband on this line. If I call my broadband line using the phone connected to this second line, the modem will drop sync fairly quickly (CRCs through the roof), again with the modem still connected to the test socket...

I informed BT business today and at the moment all they was that openreach are investigating. They will call me back tomorrow with an update - needless to say as a business we receive a lot of calls on the broadband line which has resulted in a large drop of the IP profile to around 44 now and interleaving has also been turned on. Ping to BBC.com around 28ms from an avg of 7ms just yesterday

[Bald_Eagle1]

When you mention connecting the modem straight into the master socket & straight into the test socket, do you mean via a dangly filter or are you using a cable with a standard UK telephone type plug on it?

[eliw]

Hi Eagle

I did it with a telephone cable into the test socket (tried a couple of cables)

I even tried the modem cable into a microfilter (again tried a few) and into the test socket.

Pick up the phone or receive a call and poof no sync !

But while no calls are on it is solid now no more SNRM gradual drops.

 

[Bald_Eagle1]

@ eliw,

Back in November, my drop wire from the pole mounted DP was replaced & rerouted directly to a whole new master socket & faceplates.

See the attached photos of the master socket/faceplate components that were originally installed last June.

The new drop wire etc. seemed to fix things (but only for a short while).

Since then there have been other issues, not least caused by dialling in and/or out.
Usually, receiving a call fixes things, but again for only a few days.

More recently, these issues have definitely been linked to warm & dry weather.
During wet & cold weather, use of the phone has not caused more than 0.2dB drop in SNRM & has not caused any disconnections.

In early April, an engineer replaced the cabinet jumper wires & replaced the VDSL faceplate.
Well, I think he replaced the faceplate while I went to make a brew, he said he was replacing it.

As DLM had been "stuck" at some low speed for quite a few days again, the engineer got it reset & again, everything looked to be fixed.

Unfortunately, this only lasted for a few days before the phone issue started again, disappearing again for the remainder of April (the coldest & wettest on record).

I have now seen a few posts in various forums describing similar issues, particularly when the weather becomes warm & dry.
b*cat has just pointed out yet another one to me.

Like you, I am now wondering if the service specific VDSL2 filter faceplates are indeed the link here.
Maybe the phone issue is something like a capacitance issue caused by the filter components that is more evident in warmer temperatures?

I have done this all this previously (but not since the ssfp was supposedly replaced in April), but your description of removing faceplates etc. prompted me to remove both the VDSL2 & telephone faceplates & connect the modem & a telephone into the test socket via a dangly splitter/filter again.

Until doing this, there had been a number of re-syncs today, with SNRM levels all over the place (see attached graph).
After doing it, lo & behold, no re-syncs & only a miniscule drop in SNRM when dialling out or in.

I will leave things this set up like this overnight, just to see if SNRM lowers to really low levels again & use of the phone again causes disconnections tomorrow morning.
If it doesn't, I'll reconnect the filtered faceplate & try again.

The forecast is still for very warm & dry weather, so it should be a good test.

Incidentally, my own TDR tests have not identified anything on my connection right back to the cabinet that wasn't already there in April.

An engineer should have visited today who would have checked all this (I was going to ask him about the filtered faceplate anyway), but the visit was cancelled in Plusnet's system just 2 hours after they confirmed the visit to me.
As nobody bothered to tell me it was cancelled I sat around all morning in anticipation of getting my broadband service permanently fixed.



Plusnet were supposed to contact me this afternoon confriming whether or not an engineer visit could be arranged for tomorrow.

Guess what. They didn't bother confirming one way or the other.
So I can now sit around waiting for an engineer who doesn't show again tomorrow, or take the risk of getting on with things, missing the engineer & being charged for that privilege into the bargain.

Have dodgy VDSL2 filters been to blame all along for a number of us users?

EDIT:
FWIW, I have attached a photo of the 1st filter (from behind the test socket).

@b*cat,
I did email a photo of the VDSL2 filtering once over.
I can't find the photo now, do you still have it?
I don't really want to strip down the ssfp even though it is a spare one, as I don't want to risk damaging it, just in case I need to use it again.


2nd EDIT:

I found the photo of the VDSL2 ssfp filter.
It is rather blurred, but I have attached it anyway.

[burakkucat]

Sorry Mr Eagle but the b*cat has developed a "thumping, stormy, headache" which, I'm sure, is weather related.

I attach a somewhat better photograph of the internals of a SSFP (no camera shake, higher resolution). 

What you call "the 1st filter (from behind the test socket)" is not a filter at all. It is just the capacitor and resistor that are (series) connected across the incoming pair. They ensure that the pair are correctly terminated and provide the "bell" wire, from the junction of the capacitor & resistor.

[Bald_Eagle1]

From my photographs it can be seen that the "back plate" that includes the test socket (2nd photo from the left) has 4 terminals in the test socket.

These 4 terminals have arrived at this point after applying the bell wire circuitry from the only 2 available terminals (A & B) on the reverse side, to which the drop wire is directly connected.

Into this test socket is plugged the VDSL2 SSFP.

The male plug on the reverse of the SSFP contains only 2 terminals (the outer pair).

However, we can see from your clearer photo that 8 terminals are present at the VDSL2 socket & 4 terminals are present at its "extension" socket into which plugs the telephone faceplate, also containing 4 terminals.

The telephones in use at my home only have 2 wires in their leads (the middle pair of the 4). 

The lead supplied with the HG612 modem also only contains 2 wires which conect to the middle 2 terminals of its plugs.

My findings from the experiment of removing the SSFP & using a dangly filter plugged into the test socket, with the modem & 1 telephone plugged ito the dangly filter are as follows:-

• SNRM has hardly fluctuated at all overnight.
• At 09:00 this morning, using the phone causes SNRM to drop by only 0.2dB & it certainly does not cause a disconnection.
• Output power levels have remained perfectly flat. b*cat may recall I have previously queried my fluctuating output power levels.
• The connection re-synced at 05:51 this morning. I believe this was DLM's attempt to provide a higher speed based upon the previous 13 hours or so of stability.
  
  However, DLM is curently "stuck" at a sync speed of only 19999k due no doubt to all the disconnections during this week's spell of warm & dry weather.
  
• There have only been 13 DS & 6 US Error Seconds since using the dangly filter & all other error counts are very low (for my connection).
  All error counts (apart from RSCorr errors due to Interleaving still being switched on) are completely non-existant sine the early morning re-sync.
  
  

I will continue using the dangly filter setup for the rest of what promises to be a very warm & dry day before retesting with the VDSL2 SSFP.

If returning to the VDSL2 SSFP also produces such clean results, I will have no idea whatsoever as to what is/has been causing these recent issues.

I wonder if OR secretly found & fixed something while I just happened to be on the phone to Plusnet, complaining that the engineer hadn't turned up for the specially arranged appointment.


So, to summarise, things do appear to be pointing toward a faulty VDSL2 SSFP being the culprit.
This is not identical to eliw's issue, but is very similar indeed.
Thanks eliw for mentioning your experimentation & prompting me to start all over again, despite my SSFP supposedly only being replaced in April.

If this is indeed the cause of my more recent issues, the lesson learned has to be "NEVER, NEVER, NEVER IGNORE THE BASICS JUST BECAUSE SOMETHING IS "SUPPOSEDLY" FIXED.

For the first time ever since being able to graph my connection's stats I am able to present a completely clean bill of health.
It does only cover 200 minutes hours, but it is indeed a FIRST!

[Black Sheep]

Good result BE. I can 100% confirm that we do have issues with some VDSL frontplates. I wouldn't say it's in the extreme, but maybe one every 2-3 weeks when working on ADSL/VDSL faults, will require swopping out.

[Bald_Eagle1]

Hi Eagle

I did it with a telephone cable into the test socket (tried a couple of cables)

I even tried the modem cable into a microfilter (again tried a few) and into the test socket.

Pick up the phone or receive a call and poof no sync !

But while no calls are on it is solid now no more SNRM gradual drops.

Just to confirm, you do actually mean the "test" socket with the VDSL2 SSFP already removed, don't you?

Also, just to mention (possibly mentioned previously), CRC, FEC & HEC errors (as reported in the HG612 modem's GUI) are NOT to be trusted as they do not match the more detailed (& probably more realistic) RSCorr, RSUnCorr errors etc from xdslcmd info --stats.