Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Uploader on November 29, 2020, 06:33:22 PM
-
Good Evening all
I've had an issue with our FTTC here since it first was enabled around 5 years ago, from the first day it was installed we could only achieve an upstream sync of somewhere between 8 or 9mbps, but we'd easily hit a downstream sync of close to 80. Our line length is 570mtrs.
I raised this upload issue with BT last week who kindly offered an Engineer visit, the Openreach engineer came out on Wednesday and used his JDSU on the line to look for a bridge tap externally without any success, he then asked politely to enter the property where he proceeded to blame my extension for causing said Bridge Tap (much to my annoyance) and swapped out my MK3 VDSL face plate for a MK4 version. After still finding no sync improvement he went an did a 'Lift and Shift' which has now put the line back into its DLM training mode I guess.
The lift and shift has raised the upload 'slightly' to 9mbps now, but ideally I'd like to see it higher.
Now, regarding the extension.. removing this makes absolutely no difference to down or up sync, the extension was attached the the removable faceplate on the MK3, and was terminated to an NTE5A where our single house phone was plugged in, therefore this rules that out no?
I'm currently using the BT Smart Hub 2 so can't get access to detailed stats any more, I've included a couple of bits that someone here might find useful from back when I used the HG612 a couple of years ago.
My question really is should I keep chasing Openreach to fix this issue should BT be so kind enough to offer me another Engineer visit this week? I'm thinking that another engineer might be able to find a bridge tap on the line? or maybe even attempt a Tie Pair change at the cabinet?
The current stats from the SH2 show as -
Product code:Smart Hub 2
Serial number:+091298+2035017236
Firmware version:v0.21.03.07094-BT
Firmware updated:Tue Nov 3 08:49:10 2020
Board version:R01
GUI version:1.56 15_02_2019
DSL uptime:1 days,16 Hours55 Mins24 Secs
Data rate:9.138 Mbps / 73.651 Mbps
Maximum data rate:9.074 Mbps / 74.852 Mbps
Noise margin:5.5 / 5.0
Line attenuation:9.1 / 18.3
Signal attenuation:9.1 / 20.1
VLAN id:101
Upstream error control:Off
Downstream error control:Off
-
Welcome to the Kitz forum.
It looks like you've posted about this issue here (https://community.plus.net/t5/Fibre-Broadband/New-Fibre-Install-Great-download-Poor-upload-speeds-Please/td-p/1294368) 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. :)
-
Welcome to the Kitz forum.
It looks like you've posted about this issue here (https://community.plus.net/t5/Fibre-Broadband/New-Fibre-Install-Great-download-Poor-upload-speeds-Please/td-p/1294368) 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. :)
Thank you for the Welcome! :cool:
Wow, you're absolutely correct! That is indeed my old account on there, I did try and write a massive long post explaining how this is something I'd looked at before but I've got some major brain fog tonight and every time I read it back it doesn't sound quite right!
Unfortunately I couldn't get a look at the Engineers JDSU as we were trying to keep our distance from one another amidst the Covid-19 situation. I did ask him several times if he could see the same Bridge Tap as shown in the H Log but he said no.
I'm convinced that the Tap lies outside our property and is too close to the premises for his tester to detect on what I assume is the Auto TDR mode, unfortunately I couldn't convince him to climb the pole and take a look.
I mentioned Cross Talk possibly causing the issue but he said straight away that it won't be that as the cabinet is very quiet.
I'll have to try and get the HG612 setup again and running for a more recent HLog, but I'd like to wait a few more days if possible as up until the lift and shift the DLM was happy with the connection and had put us on the 3db SNR Downstream, once we get there again in a few days (fingers crossed) I'll swap the modems over.
Has anyone heard from Wombat recently? I tried checking his post history and it looks like he hasn't been active on any of the forums in a long while, I hope he's ok.
-
Welcome to the Kitz forum. :)
We can clearly see that, back in 2016, there was a bridging tap present. The minimum, located at (approximately) sub-carrier 2895, in the plot of the logarithmic presentation of the Channel Characteristics Function (H) is indicative.
Now, regarding the extension.. removing this makes absolutely no difference to down or up sync, the extension was attached the the removable faceplate on the MK3, and was terminated to an NTE5A where our single house phone was plugged in, therefore this rules that out no?
I am having a little trouble understanding the above. Are you saying that the service lead-in was terminated at an NTE5/A, to which a Mk 3 service specific face-plate had been fitted? Then the modem/router was connected to the top socket of the SSFP? Finally, from the lower front face-plate, a telephony extension was taken to another NTE5/A, via which the telephone was connected?
-
Welcome to the Kitz forum. :)
We can clearly see that, back in 2016, there was a bridging tap present. The minimum, located at (approximately) sub-carrier 2895, in the plot of the logarithmic presentation of the Channel Characteristics Function (H) is indicative.
I am having a little trouble understanding the above. Are you saying that the service lead-in was terminated at an NTE5/A, to which a Mk 3 service specific face-plate had been fitted? Then the modem/router was connected to the top socket of the SSFP? Finally, from the lower front face-plate, a telephony extension was taken to another NTE5/A, via which the telephone was connected?
Thank you for the welcome Burakkucat! ;D
Sorry for my explanation, your interpretation of it is correct.
The drop wire comes directly though the window of the house where it meets the NTE5A, a top of this sat the MK3 SSFP and the modem connected directly to this. I then used the 'removable extension portion' to feed off an extension to a spare NTE5A I had knocking around, this is just the bare NTE5A without a faceplate.
-
The drop wire comes directly though the window of the house where it meets the NTE5A, a top of this sat the MK3 SSFP and the modem connected directly to this. I then used the 'removable extension portion' to feed off an extension to a spare NTE5A I had knocking around, this is just the bare NTE5A without a faceplate.
Thank you for clarifying the previous physical configuration. That should not give rise to a bridging tap but the usage of the second NTE5/A, for the telephony extension socket, would "doubly terminate" the circuit . . . unless, of course, the series connected resistive/capacitive shunt was removed from the second socket.
Since the recent Openreach technician's visit, the aerial service feed/lead-in now terminates at an NTE5C and the modem/router plugs into the relevant socket of the SSFP. The telephony extension remains, as previous, and is connected to the relevant terminals of the NTE5C.
If you were to fit an appropriate extension socket in place of the NTE5/A, there would be nothing to which "an eyebrow could then be raised".
It would be helpful to see a current Hlog plot, with the HG612 connected --
- straight to the test-socket of the NTE5C. I.e. with the SSFP removed.
- to the relevant, data, socket, with the SSFP in situ.
-
Thank you for clarifying the previous physical configuration. That should not give rise to a bridging tap but the usage of the second NTE5/A, for the telephony extension socket, would "doubly terminate" the circuit . . . unless, of course, the series connected resistive/capacitive shunt was removed from the second socket.
Since the recent Openreach technician's visit, the aerial service feed/lead-in now terminates at an NTE5C and the modem/router plugs into the relevant socket of the SSFP. The telephony extension remains, as previous, and is connected to the relevant terminals of the NTE5C.
If you were to fit an appropriate extension socket in place of the NTE5/A, there would be nothing to which "an eyebrow could then be raised".
It would be helpful to see a current Hlog plot, with the HG612 connected --
- straight to the test-socket of the NTE5C. I.e. with the SSFP removed.
- to the relevant, data, socket, with the SSFP in situ.
Thank you Burakkucat
I'll get the extension altered in case of any future visits.
Unfortunately it looks like I've reached the end of the line with Openreach on this one once again, I've had a reply back from the helpful chat at BT saying 'Bridge tap is still showing. I've therefore checked with the engineering team and they have said that it is not service affecting. They have said that the connection is stable with no errors and the speed achieved is also ok.'
So they're unwilling to help and further it seems..
I'll try and get the HG612 back up and running within the next couple of weeks to get some stats off to post here, thank you both you and re0 for your help once again.
-
I'm going to bump this one as I had Openreach back out the other day looking at why the connection kept dropping every day during the hot weather, sometimes 2-3 times per day.
Engineer arrived, I told him about the connection issues and the Bridge Tap that still appears on the GEA Test. After being told that my Bridge Tap was caused by my extension wiring by the last engineer I made sure I disconnected this months ago and instead now situate the phone right next to the NTE5C Master Socket.
Engineer ran all this tests with the EXFO and the line came back as no faults and green, I politely asked him if it would be possible to access his HLog graph and he discovered the same nasty bridge tap image that was on my HG612 back in the day, unfortunately this is where I hit a brick wall, the only possible place left for the Bridge Tap has to be the Pole outside or the Drop wire to the house, but because his tester told him that there's no fault found he said he was unable to scale the pole.
Before he left he fitted another new faceplate to the Master Socket (I'm on my fourth now I think!?) this one has G.Fast branding on it, but he has asked me to get a new Smart Hub 2 from BT to rule that out as the cause of the bridge tap.. and even suggested it could be my phone causing the issue!
Upon leaving he did go to the Cabinet and run some tests there and check the wiring was all to a decent standard.
How on earth do I go about getting this resolved?
-
About the only thing left for you to try is to compose a concise e-mail message, with the pertinent details in chronological order, and send it to the clive.selley@openreach.co.uk address. That will result in a member of the executive complaints team looking into it . . . hopefully with a positive result.
-
About the only thing left for you to try is to compose a concise e-mail message, with the pertinent details in chronological order, and send it to the clive.selley@openreach.co.uk address. That will result in a member of the executive complaints team looking into it . . . hopefully with a positive result.
Thanks burakkucat
That sounds like a great idea, will let you know how I get on :fingers:
-
... he has asked me to get a new Smart Hub 2 from BT to rule that out as the cause of the bridge tap.. and even suggested it could be my phone causing the issue!
...
If he asked things like that I wonder if he even knows what a bridge tap is! :no:
-
If he asked things like that I wonder if he even knows what a bridge tap is! :no:
Honestly I think he just wanted to bin me off and get on to his other jobs of the day.. I guess they're paid per job completion? So I kind of get it.
I was really annoyed though because he could see the Bridge tap on his EXFO graph with the Smart Hub 2 plugged in and the phone installed at the master socket, but he unplugged them both and ran what I assume was another GEA test, he suddenly goes "I've found your Bridge Tap, it's either in the SH2 or the Phone as it's no longer showing a tap with these removed" so I said "Ok then, can you do whatever you did again to get the HLog graph up so we can see if the nasty dip has gone" .......... "Oh, I've not tried that" and he left it at that.
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?
-
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?
I've no idea how the Exfo HHT operates but I would be surprised if it relies upon the presence of the CPE.
-
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.
-
I've no idea how the Exfo HHT operates but I would be surprised if it relies upon the presence of the CPE.
I've not a clue in all honesty :(
The new SH2 arrived today, I've plugged it in and am absolutely shocked to find it has made no difference :lol:
-
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 :cool:
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.
-
I have almost always typed "a bridging tap". But that's just me. :angel:
-
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?
-
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.
-
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.
-
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.
-
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!
-
Welcome to the Kitz forum.
It looks like you've posted about this issue here (https://community.plus.net/t5/Fibre-Broadband/New-Fibre-Install-Great-download-Poor-upload-speeds-Please/td-p/1294368) 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.
-
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.
-
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. :)
-
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?
-
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 <<
-
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.
-
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.
-
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.
Thank you for those three images. As you say, there is potential for sub-optimal connectivity!
I thought I had an image stored away somewhere but it's currently proving to be elusive.
Time for an update!
I've lost count of the appointments I've had since my last post, one missed... one didn't turn up but put down that he'd been!? and one who turned up without an appointment who put all his stuff out (Ladders, Road signs etc) only to be told not to climb :-\
Which brings us to Friday where a great engineer came out and couldn't understand why this had been thrown back so many times, he climbed the pole... found corrosion in the top of the DP and cleaned that up, was still getting a bridge tap result whilst up there with the tester attached so came down and opened up the pole joint which all looked fine and also showed bridge tap, so he switched us to a spare pair back to the cab which also showed up as Bridged tap!
Eventually another engineer turned up with a Hoist and they went along the line bit by bit back towards the cabinet where they believe they've traced the fault to a 150mtr section underground in the road ducts, unfortunately this requires a heavy lift team to get the covers up in the road, it might also require a road closure!
It's progress, but seems like a really weird fault to have a bridge tap on multiple pairs? The chap in the hoist said they've tried all the other spare pairs and they were worse and some were even showing as going to ground with I guess means they're earth faults?
-
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.
This would have had me tearing my hair out!
-
I've got the HG612 back on as I wanted to see what the HLog looked like on the 'new spare pair'
definitely a different shape right? confirming that it is indeed a Bridged Tap still..
Unfortunately it looks like the pair we got switched from was the better performing copper of the two :(
-
. . . they believe they've traced the fault to a 150mtr section underground in the road ducts, unfortunately this requires a heavy lift team to get the covers up in the road, it might also require a road closure!
It's progress, but seems like a really weird fault to have a bridge tap on multiple pairs?
Unless in a dim and distant previous repair to that 150m underground section resulted in a new length of cable being pulled in and there is a stub section of the old cable still in situ and connected, at one end, to the new cable.
The chap in the hoist said they've tried all the other spare pairs and they were worse and some were even showing as going to ground with I guess means they're earth faults?
Yes, earth contact faults.
-
Unless in a dim and distant previous repair to that 150m underground section resulted in a new length of cable being pulled in and there is a stub section of the old cable still in situ and connected, at one end, to the new cable.
Yes, earth contact faults.
We've finally reached a successful conclusion (I hope!)
Had an experienced engineer out today, sent him straight down to where the last couple of Engineers had traced the fault to and he said there was an issue, few hours later I get a phone call to say he found the issue... 'Lightening Protection Joint in the roadway box just outside the cabinet'
So this joint has been affecting everyone supplied by this cabinet for years!
I went down to have a look and he was showing me the three way crimps that feed it, Is this something you've come across before?
Stats looks quite good now, hopefully in a few days the DLM will correct to a full 20 Upstream sync :fingers:
Thank you everyone for all your help, I'm so glad we've got somewhere in the end!
-
That's quite a result if everyone on the cabinet has been improved. Shame they wont know who got it fixed, they owe you a few beers.
-
That's quite a result if everyone on the cabinet has been improved. Shame they wont know who got it fixed, they owe you a few beers.
Would be interesting to look at various addresses served by that cabinet and see if estimated speeds stated by the BT Wholesale checker increase in due course.
-
That's quite a result if everyone on the cabinet has been improved. Shame they wont know who got it fixed, they owe you a few beers.
Indeed, I was rather shocked when I realised how many others it must have been affecting.
The HLog is looking very nice now, HG612 managed to Sync at 80/20 :cool: should hopefully keep me happy until we possibly get FTTP in a year or twos time..
-
Would be interesting to look at various addresses served by that cabinet and see if estimated speeds stated by the BT Wholesale checker increase in due course.
I will try and keep an eye on the neighbours values from the BT Wholesale checker, as I'd noticed that their line too was also showing as Bridge Tap, but without knocking and inspecting their setup I'd have no way of telling if it was CPE or External, they also had a very low upload of around 7, so I'll report back if it changes ;)
-
. . . 'Lightening Protection Joint in the roadway box just outside the cabinet'
<snip>
I went down to have a look and he was showing me the three way crimps that feed it, Is this something you've come across before?
It's not something of which I have had experience but I do remember, possibly nine years ago, that there was a redundant lightning protector still connected to all the pairs at a pole top located in the outskirts of Ewhurst, Surrey. Walter Willcox had discovered it whilst attempting to help residents with poor broadband connections. On telling a visiting Openreach engineer about it, the engineer said it would be a simple task to disconnect it (it was not doing any good as the earth connection had been removed many years ago) but he could not go to the location, as his van was fitted with a tracker. Ever resourceful, Walter enquired if the engineer's ladder and tools were tracked. The answer was "no", so Walter suggested he put the ladder onto the roof-rack of his car and he would drive the engineer to the location. The engineer left his mobile phone in his van and went off with Walter to perform a 10 minute fix. :)
-
The HLog is looking very nice now, . . .
Yes, that is excellent.
-
Great news that it is fixed, and an interesting fix too. :)
What is not great is the time it has taken Openreach to sort it. :no:
-
It's not something of which I have had experience but I do remember, possibly nine years ago, that there was a redundant lightning protector still connected to all the pairs at a pole top located in the outskirts of Ewhurst, Surrey.
Never known them to be fitted on pole-top equipment ?? Certainly, pre BB, there were quite a lot of PU's (Protection Units) installed on the UG network, though.
Typically, they would be in places with a higher chance of being struck, for example we had one near my locality which fed numerous monitoring equipment, weather radars, signal repeater stations, wind-farm controllers ... all on top of a bl00dy big hill.
The problem was, with the advent of DSL, they couldn't get a signal due to the distances involved until somebody (not myself) worked out there was a 100pr buried joint containing these pesky PU's. Once cut out of the circuit, they were up and running albeit on a slow speed, but still up and running.
The OP was obviously closer to the DSLAM as he at least had a service, just not optimized. Good result.