Kitz Forum
Broadband Related => ADSL Issues => Topic started by: WWWombat on January 27, 2015, 01:26:49 AM
-
My new(ish) line has a temporary ADSL2+ connection, while waiting for BT to sort out their back-office systems to finally get an FTTC provide to go through.
Unfortunately, this temporary ADSL connection is showing signs of some faults ... but we can't report them while the FTTC order is in place ::) We chose to leave the order in place, and put up with the problems. Hopefully an engineer installation for FTTC will bypass the problem entirely, otherwise it may well be an opportunity to identify and fix it.
Does anyone have any advice as to what the fault might be, and what I might get the FTTC-installation engineer to double-check whilst here?
Symptoms:
- The most regular symptom is a drop in upstream SNRM when the handset is picked up to make an outgoing call. Sometimes a constant drop of 2dB through the call with no resync, sometimes a ragged drop, perhaps 5-6dB, that causes a resync (usually resulting in lower speeds).
- Occasionally, the handset being picked up also triggers a spike on the downstream SNRM graphs too.
- Occasionally, the upstream SNRM can start a period of erratic drops. No obvious trigger nor end; can trigger a resync.
- Very occasionally, the downstream SNRM joins in the period of erratic behaviour, and makes broadband access unstable.
-
Additionally, the Hlog graph (for just ADSL tones) shows a slight "V", which I'd normally take to be a sign of a bridged tap.
However, this "V" occurs right on the boundary between the upstream & downstream tones; as I haven't encountered Hlog graphs for so few tones before, I'm not sure whether this is a standard artefact of ADSL, or a real problem. Any opinions?
-
This is standard artefact on ADSL. What your QLN? You have probably serious line fault, HR fault perhaps.
Best regards
konrado5
-
QLN looks like this, which is the kind of effect I'd expect.
-
Konrado5 is spot-on with his analysis. ;D
I agree that you most definitely have a HR (or semi-conducting) joint somewhere in the metallic pathway.
The dip in your Hlog graph is nothing . . . Just consider it as a "reminder" where the US tones end and the DS tones begin, when viewing the graph from low to high frequencies!
I just hope that the person doing your install is a time-served Openreach technician and not a sub-contractor from Kelly Communications or M J Quinn.
-
And a wee bit of Radio frequency Interference on tone 211 (909 Khz)
-
And a wee bit of Radio frequency Interference on tone 211 (909 Khz)
Which will be Radio 5.
-
I think it is effect of HR fault, it is merely apparent Radio frequency Interferece.
-
b*cat nods. That certainly could be the case. The only way to be sure is to examine the equivalent graph once the fault has been fixed.
-
b*cat nods. That certainly could be the case. The only way to be sure is to examine the equivalent graph once the fault has been fixed.
Or do as much as possible to the internal home broadband cable to neutralize a possible internal fault this way you can be 100% sure that the fault lies outside your premises and confident that you will not be charged for an engineer visit :)
-
Thanks chaps. We'll see if anything happens tomorrow - but I suspect the job will still be built on the wrong DSLAM.
There is no internal wiring involved, so very simple from that perspective.
-
WWWombat the OR engineers will do a good job, and as for line being connected to wrong FTTC cabinet if thats what your saying it would be a first as your FTTC just would'nt work, the OR Engineer will find the current FTTC/PCP cab your line is using at the moment and move you over to FTTC.
I don't know who or what has given this info that your DSLAM info will be wrong :-\
-
@NS
Who has given me the info that the DSLAM data is wrong?
That would be from the 4 engineers who have been on site trying to get the basic phone line working. I've traced the line with them back to a DP shared with all the other properties on the block (flats and shops); all the lines physically go back to cab 20; all the other properties in the block have records that show cab 20.
However, our place is funny; we are in a corner property, built as part of a block along the main road, the whole block being fed by cab 20; but our entrance is on the side street, and the postal address is too - and the side street is served by cab 21. The address manages to cause confusion with some parcel delivery, and it seems to have confused the BT surveyor.
The records for this address, from first survey (September) up to last weekend, said cab 21. The records for this phone number (once working, in mid November), until this weekend, said cab 21.
The engineer who finally got the phone line working made adjustments in cab 20, then went to the MDF and re-made the connections there. Bingo - a working phone line. He gave me a copy of the PCP connection data.
All of those engineers knew the PCP record was wrong, and reported it back - but the update never made it into the back-end system. All of them knew that, with the PCP wrong, the job was then built with the wrong DSLAM, giving me a port in a DSLAM I couldn't physically be connected to.
A further engineer was sent out (in early December) with "just" the task of confirming what the actual routing was. He confirmed the route through cab 20, and gave me all the connection data. It also went back to Openreach; my ISP confirmed with BTW that the new routing data was there, and would be attached to a new order, when it was placed. It wasn't.
The 2 separate engineers (or maybe 3, I've lost count) who have only come to install the fibre portion have all immediately given up, because their job was built with cab 21. They know that FTTC wouldn't work. I knew it too. One of those was ordered to re-attend (by Openreach) later the same day, as things "would be fixed", but refused. Rightly. "Things" weren't fixed.
Today's appointment was made under the promise that the new data would be attached to it, so might work. However, the routing data (as visible in the public DSL checkers) only changed after the order was placed. We (the ISP and me) think today's order will still fail, because it is likely to still hold the wrong cab identity; we'll see.
It has been a long and sorry tale.
Even worse ... the wrong PCP is 10 yards away. The right one is 100 yards away.
-
whats stopping the engineers just overuling the computer and physically connecting you to the right cab? im confused.
-
You mean physically connecting me to the cab in the records, so they could then connect me to the DSLAM where the port is allocated?
Simple - because there isn't a route for the copper to go to get to a DP that is connected to that PCP. I can *see* just such a DP out of the back window; it is an old-style (bell-shaped) one on the side of the next physical building along the side street (see my prev post about the layout of properties). But to get to it, the copper would have to go across a yard (not ours), a garage (ours), a footpath (not ours), a second footpath (not ours) and the garden of that building.
-
And a wee bit of Radio frequency Interference on tone 211 (909 Khz)
Which will be Radio 5.
I think it is effect of HR fault, it is merely apparent Radio frequency Interferece.
Looking in detail at those spikes on the QLN, I see they are at 211, 252 and 282 - mapping to stations on 909kHz, 1089kHz and 1215kHz.
According to this radio page (http://www.mediumwaveradio.com/uk.php) provided by Kitz, it looks like I could be being hit by transmissions from Moorside Edge - which transmits these 3 stations (and only these 3) at pretty high power: 200kW, 400kW and 200kW respectively. That is about 40-50km away.
-
Wombat is completely correct in his comments.
If the ISP's port is built against the incorrect DSLAM/Cab, then there's nothing Openreach can do. Zilch, nada !!
A) We don't start running cables to different DP's fed from different Cab's just to suit a robotic routing tool (ROSE), plus it is a disciplinary action if found to do so.
B) We can't just ring someone up and mention that the VDSL is working at 'X' Cab, please move it to 'Y' Cab. The 'build' of the circuit takes long hours to achieve.
In a nutshell, it's the geography of Wombats premises that's thrown a spanner in the works. It's a shame, but it's not the end of the world, just a lot of frustration. Either way .... 10 or 100mtrs, it's not going to affect your circuit in any noticeable way. I sincerely hope todays visit is successful ? :) :)
-
I agree that it sounds like a HR fault - the upstream SNRm is displaying typical behaviour for either HR fault or faulty filter.
Your symptoms sound remarkably similar to the fault I had which ironically started the day after I'd started migration from adsl2+ (Be) to fttc (Plusnet). Because I'd just started the migration process there was little I could do, and I was half hoping it would clear when fttc got connected.
I didnt have QLN & Hlog from my adsl2+ line, but from what I can recall the SNRm behaviour looked very similar
Symptoms were all the same as you mentioned except this one
Occasionally, the upstream SNRM can start a period of erratic drops. No obvious trigger nor end; can trigger a resync.
I found that people phoning me could trigger this off - I only realised later when I'd tie up a message time on the ansa phone, but its possible that someone like my parents could have rung, as they seldom if ever leave a message. I'd also find that for no reason, the upstream SNRm would sometimes start to slide, sometimes I could bring the upstream SNRm back up by dialling out and then replacing the receiver.
Once fttc was installed things werent much better, so BT duly called out. First was no fault found because my SNRm was so high (16db) so that it was sufficient to mostly stop the line dropping when the phone range. Because the line mostly stayed in sync then it was considered acceptable. I persisted with the fault because the upstream SNRm was mostly swinging between 1dB and 16dB and now only occasionally dropping the line.
To cut a long story short 2nd engineer found a corroded terminal in my BT66, this cleared a small v notch in my hlog & SNRm stopped the wild fluctuations, but I still continued to get the loss of about 12db on the upstream every time the phone was in use, but BT found this acceptable because the line would only drop a couple of times a week. Eventually it got a lot worse and voice started to be affected too. Then an engineer found a faulty NTE which corrected things for a while... It was only when voice degraded to unacceptable level that they gave me a new d-side.
Sorry this is shorter than it could be, I have graphs somewhere, but Ive been up since 5.30 to take dad to hospital. Im awaiting a call before I have to shoot back out. But the whole tale and graphs are in a thread somewhere here (http://forum.kitz.co.uk/index.php?topic=12660.msg242268;topicseen#msg242268)
-
Thanks Kitz - I'll digest this some more when I don't have to concentrate on school stuff for my daughter, and look up your previous experiences.
I sincerely hope todays visit is successful ? :) :)
My expectations were pretty low, and were met entirely. A morning of waiting turned into a no-show.
It seems that Wholesale cancelled the order sometime between Tuesday afternoon (when it was checked by Plusnet staff) and Wednesday morning.
-
:no: :'(
-
is it concerning plusnet dont find out about cancellations until the end user informs them? you not alone on this scenario.
you would think they would get some kind of automated alert or something.
and of course why do BTw/openreach cancel appointments?
-
Until we get the facts, we will never know ??? I don't think it's done out of devilment though ? ;) :)
-
It is concerning for Plusnet that they don't have an automated monitor for this. However, I've learnt, and adapted accordingly ... PN get regular requests from me to just check that an appointment is still in place prior to the appointment day.
Must adapt further, and check *on* the day too.
Why it was cancelled is unclear. One of the earlier orders was also cancelled ... but that happened just after someone at BTW updated it to get PN to ask me for an appointment date. You've got to assume that fat fingers can happen anywhere...
-
New order placed, and an installation due tomorrow... And yes, it was double-checked yesterday and triple-checked again today :-X
The line was truly horrible over the weekend, with the modem dropping and failing to sync on a few occasions. It wasn't helped by PN having a CHAP authentication fault going on at the same time.
I'm going to have to mention the likelihood of the fault to the engineer; any advice on making it more detectable by him? I suspect the best advice is to not use the phone beforehand, so no current gets sent through any iffy joints. However, I bet he tries calling before he makes changes at the cab...
-
How are your expectations for FTTC installation this time, Good Medium or Low ?
-
When an order is placed, if the test systems detect a fault on your line the task will be built as an IFTTC5 task. There will be a note on the task for the engineer to complete the 'Managed Install' and also repair the line fault.
If it hasn't detected anything (such as a HR), then it will be presented to the engineer as an IFTTC2 task.
You are then in the lap of the gods as to how the job pans out. :)
-
I'm pretty confident that the build will be to the right cab now, so I'm in the lap of the scheduling gods right now! Hopes at medium, as we're nearly half way through the morning shift...
PN did a line test just before placing the order, and it came out OK (shame, given how bad the line has been since).
-
All up and running here now, with full 80/20 speeds, 98/32 attainable on a DSLAM that has over 100 of the 200 connections to the FTTC cab in use (not sure if that means over 50 D-side connections or over 100).
The HR fault didn't turn up in the test that Plusnet did prior to order, nor within the test done when building the order, nor in the line test done by the attending (Kellys) engineer prior to starting work. However, a "Potential HR joint fault" did turn up in the line test he did after the connection.
The good news is that the VDSL2 connection is showing none of the disturbances that the ADSL2+connection did: No variation of the SNRM when a handset is picked up, even when left until howler kicks in, nor for an incoming call.
In ADSL2+, there were heaps of errors downstream all the time - and loads upstream when the HR fault made its presence felt. In VDSL2 there is almost nothing at all - less than 4 ES/hr.
Not sure what to do about the HR fault now. No disturbance to broadband, and not audible on voice calls. But a test has finally shown something.
-
That probably means that the HR fault is on the E side and therefore not affecting the broadband connection now you have FTTC.
-
And I had everything crossed that could be crossed for that to be the case. I haven't uncrossed them yet ;)
-
Great set of figures, and I concur with Eric's thoughts. :) Time will be the teller.
-
I think they may be able to fix the fault without disturbing you.
-
My guess also its E side related. If the FTTC is working well I would leave it alone.
-
Phew Im glad that so far so good. :fingers:
I think Plusnet may be able to put your fault on hold for a while. They did with mine.
-
That probably means that the HR fault is on the E side and therefore not affecting the broadband connection now you have FTTC.
I had one of these when I first joined FTTC - no issues at all with broadband, but phone E Side was a state!
-
In our last place, the FTTC broadband was fine. But we'd get intermittent pops and hisses on the voice side which never registered on any line tests . so we mostly ignored them.
I wonder how common it is - that the VDSL2 connection is clear, while the voice isn't.
-
In our last place, the FTTC broadband was fine. But we'd get intermittent pops and hisses on the voice side which never registered on any line tests . so we mostly ignored them.
I wonder how common it is - that the VDSL2 connection is clear, while the voice isn't.
This may give you a clue my broadband is being sent to me by an exchange that is 3 miles from me and the voice/telephone is supplied by my local exchange which is 0.68 miles from me.
Two different exchanges for two different products.
-
. . . my broadband is being sent to me by an exchange that is 3 miles from me . . .
But that will not be a problem. The link is a fibre-optic feed from the head-end exchange to the "fibre" cabinet adjacent to the PCP, where the telephony E- & D-sides meet.
-
. . . my broadband is being sent to me by an exchange that is 3 miles from me . . .
But that will not be a problem. The link is a fibre-optic feed from the head-end exchange to the "fibre" cabinet adjacent to the PCP, where the telephony E- & D-sides meet.
Yes that part is not an issue it's the local exchange that only provides the telehoney/voice to PCP cabinet from the old E-side voice exchange which does not use fibre it's still using the old underground metal cabling .
-
I think my question was more about the relative quality of the two chunks of copper. Which ultimately becomes a question of whether swapping to FTTC improves the (broadband) fault rate or makes it worse. I guess BT know these stats by now...
-
I'm pretty sure it's not something that we can 'stat'. One either has a fault that is reported, or one doesn't. That is the only way we can gather historical data.
I also think it comes down to the difference in EU's expectations ??. I, for example am not bothered in the slightest that I've lost circa 25Meg through cross-talk since I first went 'live' on FTTC. Whereas others go livid if they lose 0.5Meg. Conversely (pun intended), one EU may put up with an extremely noisy landline, whilst another will report the slightest one-off noise event.
I do however, think that a lot of REIN events go un-reported through EU's moving to the greater bandwidth product ?? Even though the REIN will affect the circuit, it is nowhere near as noticeable on VDSL, than it is on ADSL.
-
Whereas others go livid if they lose 0.5Meg. Conversely (pun intended), one EU may put up with an extremely noisy landline, whilst another will report the slightest one-off noise event.
must admit i'm the EU who puts up with what is given to him/her by Openreach the reason for delaying a probable 7 year old HR fault was because of the scare tatic used by ISP's implying that a large fee will be imposed if no fault found, I don't mind if the fee is imposed for an internal EU fault because these days with all the help that is given this should not happen anymore.
-
I think there's a point, when there are enough users, that you can forget about the behaviour of individual end-users. The stats alone become significant, simply because they average over enough separate lines (and separate people).
The whole statistical theory behind telecoms - courtesy of Erlang - is what drives the provisioning strategy, and determines what investment to make where, and ultimately whether profits are made.
Once there are enough FTTC subscribers, the statistics behind call-out rates, fix rates, and fault rates are bound to tell a story. We'll never hear it, of course :(