Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: FTTC - Good Downstream, Bad Upstream.  (Read 476 times)

Uploader

  • Just arrived
  • *
  • Posts: 4
FTTC - Good Downstream, Bad Upstream.
« 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








« Last Edit: November 29, 2020, 06:38:15 PM by Uploader »
Logged

re0

  • Reg Member
  • ***
  • Posts: 749
Re: FTTC - Good Downstream, Bad Upstream.
« Reply #1 on: November 29, 2020, 08:43:02 PM »

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. :)
Logged
ISP: Zen - G.fast 330/50

Gigaclear for 2021? Maybe it's too late.

Uploader

  • Just arrived
  • *
  • Posts: 4
Re: FTTC - Good Downstream, Bad Upstream.
« Reply #2 on: November 29, 2020, 09:09:52 PM »

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. :)

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.
« Last Edit: November 29, 2020, 10:02:54 PM by Uploader »
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 31535
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC - Good Downstream, Bad Upstream.
« Reply #3 on: November 29, 2020, 09:58:42 PM »

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?
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Uploader

  • Just arrived
  • *
  • Posts: 4
Re: FTTC - Good Downstream, Bad Upstream.
« Reply #4 on: November 29, 2020, 10:06:30 PM »

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.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 31535
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC - Good Downstream, Bad Upstream.
« Reply #5 on: November 29, 2020, 10:34:33 PM »

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.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Uploader

  • Just arrived
  • *
  • Posts: 4
Re: FTTC - Good Downstream, Bad Upstream.
« Reply #6 on: November 30, 2020, 12:13:22 PM »

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.
Logged