Print

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

[Uploader]

Welcome to the forum!

Is it even remotely possible for CPE to cause a bridged tap? I find it hard to believe that, for some reason.

Q: By the way, should it strictly be "bridged tap" not "bridge tap"? If so, since the former is near impossible to say, you can see how it has evolved.

Thanks for the welcome Weaver 

Here are the stats from the new SH2 if they tell anyone here anything.. the only plus side of this 'new' unit which hopefully will do a Firmware update overnight.. is that it has the WAN port on the back so I can use it with my HG612 in a few days and monitor the HLog again 

I'll wait for my helper from the BT Forums to run a GEA test first so we can rule out the SH2 being the cause of the Bridge Tap! ...I'm not sure if it's Bridge or Bridged tbh.

[burakkucat]

I have almost always typed "a bridging tap". But that's just me. 

[Uploader]

I could do with some advice please..

BT have ran the test again with the new SH2 and it has once again come back as a Bridged/Bridge Tap, they claim it says it's in the CPE and are going to send a Qube engineer out as they specialise in Internal faults, I feel like this is a complete waste of time, thoughts?

[Black Sheep]

I was under the impression that the GEA test picks up the Bridge Tap because it can access the HLog data that the SH2 is sending back no? So therefore having this unplugged is going to show the Bridge Tap has gone?

It's been a while, but from experience absolutely the CPE has to be plugged in to detect a 'bridged tap' on a GEA test.

The engineers HHT's (Exfo etc), don't report the wording 'bridged tap' on their equipment when testing the dead pair of wires, it's only when used in 'router mode' and a GEA test is run that it will locate any bridged taps that may be present.

In a nutshell - only a GEA test will present the term 'bridged tap' in its report (if there is one), and the router/hub has to be connected to allow it to run that aspect of its scripted tests.

Caveat - I stand to be corrected if things have indeed moved on slightly, with these tests ... but doubt it.
 

[Alex Atkin UK]

While I agree its kinda silly, at least if they have an expert say in no uncertain terms its NOT CPE, they'll then HAVE to look elsewhere.

[Uploader]

It's been a while, but from experience absolutely the CPE has to be plugged in to detect a 'bridged tap' on a GEA test.

The engineers HHT's (Exfo etc), don't report the wording 'bridged tap' on their equipment when testing the dead pair of wires, it's only when used in 'router mode' and a GEA test is run that it will locate any bridged taps that may be present.

In a nutshell - only a GEA test will present the term 'bridged tap' in its report (if there is one), and the router/hub has to be connected to allow it to run that aspect of its scripted tests.

Caveat - I stand to be corrected if things have indeed moved on slightly, with these tests ... but doubt it.

Thank you Black Sheep, I'd love to get my hands on a tester so I could have a play around with it! They're a lot of money on ebay!

Since my last post I unplugged the Phone from the Master Socket and got my BT guy to run another GEA test which once again came back with Bridged Tap still showing.

I've since had a phone call, we're going to stick with the Qube Engineer who'll be able to do a report back to Openreach to say that the Bridged Tap is an external fault and not in my premises, then this can be raised to Openreach to send someone out to look for it externally, honestly I find the whole thing so silly, a complete waste of time and money.

[Uploader]

While I agree its kinda silly, at least if they have an expert say in no uncertain terms its NOT CPE, they'll then HAVE to look elsewhere.

Fingers crossed, hopefully I get a switched on Qube Engineer!

[Uploader]

Welcome to the Kitz forum.

It looks like you've posted about this issue here some years ago - at least, I believe that's you.

It may be helpful to see a more current HLog. The one you've provided looks like a bit of a nasty tap. Perhaps it still reflects the true nature.

I would agree that your upstream is a little on the low side for the distance, but the downstream looks pretty good - must be a quiet cabinet.

Was the engineer's JDSU showing the same stats for upstream in your property? If it was, then I would probably agree that the problem does not lie with you. You may be able to keep pushing and hopefully you don't get any resistance.

Let's see what else others have to say here.

Sorry for taking so long to actually get the HG612 plugged back in, I've just done so and got some screenshots for you... the tap is still there looking delicious!

The Qube Engineer came out today, lovely lady... very clued up, said definitely no issues at the property here, took a photo of the Master Socket and left to report her findings to BT/Openreach.

[Black Sheep]

I myself was not only stumped, but beaten on a similar fault ... even when I thought I was a know-it-all.

The bridged-tap on the fault I had, was eventually found by a colleague of mine in a Krone connection cabinet, whereby somebody had connected another pair of wires onto the incoming wires (from the DSLAM) at the top of the Krone connection strip .... whereas I had been solely working on the outgoing part of the circuit which is on the bottom side of the Krone strip.

A very unusual circumstance but one lives, and one learns. I certainly did.

[burakkucat]

The bridging tap is clearly still present. 

I wonder, does your service come via an aerial drop? If yes, is it a two pair drop cable? If yes then I wonder if at some time in the past both pairs of the drop cable were connected together (within the coffin block) at the pole top. 

I've known of a couple of occasions where a similar error had been made and, after repeated visits for poor performance, the last engineer actually climbed the pole, looked, found the mistake and took corrective action.

Whilst my slow paws were typing the above, I see that Black Sheep has posted about another scenario which can give rise to the fault. 

[Uploader]

I myself was not only stumped, but beaten on a similar fault ... even when I thought I was a know-it-all.

The bridged-tap on the fault I had, was eventually found by a colleague of mine in a Krone connection cabinet, whereby somebody had connected another pair of wires onto the incoming wires (from the DSLAM) at the top of the Krone connection strip .... whereas I had been solely working on the outgoing part of the circuit which is on the bottom side of the Krone strip.

A very unusual circumstance but one lives, and one learns. I certainly did.

These things are sent to try us as they say!

Your cabinet fix is a suggestion I'll put to the Openreach Engineer if everything else fails, definitely something worth looking at I think.

Is there a reason why the Tap is affecting the Upload so heavily vs the Download? or is the download affected too without me realising it?

[Uploader]

The bridging tap is clearly still present. 

I wonder, does your service come via an aerial drop? If yes, is it a two pair drop cable? If yes then I wonder if at some time in the past both pairs of the drop cable were connected together (within the coffin block) at the pole top. 

I've known of a couple of occasions where a similar error had been made and, after repeated visits for poor performance, the last engineer actually climbed the pole, looked, found the mistake and took corrective action.

Whilst my slow paws were typing the above, I see that Black Sheep has posted about another scenario which can give rise to the fault. 

We are indeed fed via an Aerial drop cable which has been there since I can't remember when.. it's very old, but every Engineer who visits says the line has really good attenuation?

The other pair of cable in the drop wire has been tested from the Master socket and didn't register a voltage, so I'm leaning to think the issue isn't there, instead I've always believed it to be in the cable that runs up and down the pole, in the attached photos you see the 'Bomb Joint' as I call it at the base, this is acting as a join between the overhead cable but our feed then comes out of this and runs back up the pole to the DP at the top, I'm 'Hoping' that someone has accidentally joined a stray wire from this feed and this will be the cause of the tap.

I've always wondered what it looks like inside the DP.. google fails me sadly!

EDIT - Had to use Imgur as the photos were a bit too large even when cut down! >> https://imgur.com/a/B4MCTQQ <<

[burakkucat]

We are indeed fed via an Aerial drop cable . . .

The other pair of cable in the drop wire has been tested from the Master socket and didn't register a voltage, . . .

That is almost the test I was going to suggest. Earth the +ve probe of a DVM and use the -ve probe to test the two wires making up the second pair. If you can see a voltage only on one wire (implying only that one wire is connected) it would be enough to perturb the working pair.

When an xDSL service is operational, the working pair is being used as a radio frequency transmission line. What can be "got away with" at DC and audio frequencies is often detrimental to the good workings of a radio frequency transmission line.

. . . so I'm leaning to think the issue isn't there, instead I've always believed it to be in the cable that runs up and down the pole, in the attached photos you see the 'Bomb Joint' as I call it at the base, this is acting as a join between the overhead cable but our feed then comes out of this and runs back up the pole to the DP at the top, I'm 'Hoping' that someone has accidentally joined a stray wire from this feed and this will be the cause of the tap.

Thank you for those three images. As you say, there is potential for sub-optimal connectivity!

I've always wondered what it looks like inside the DP.

I thought I had an image stored away somewhere but it's currently proving to be elusive.

[tiffy]

Probably not directly relevant to this situation where a bridged-tap appears to be the issue but an example where other factors can directly influence a VDSL-2 line US performance/parameters only, happened to my line at the start of the original Covid-19 lock down, 2020, details here in this rather long post:
https://forum.kitz.co.uk/index.php/topic,24606.msg413899.html#msg413899

Thankfully "Uploader" is receiving good support from his ISP on the issue which certainly was not the case with my ISP, Plusnet, at the time who were very keen to use the Covid lock down restrictions to avoid getting involved while my neighbour, who's line turned out to be the source of my issue was having no problem getting OR via his ISP, BT to address the fault.