Print

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

[coolsnakeman]

Snadge,

When i meant radius i meant there authentication servers which gives out PPP. As already stated the engineers can connect to these ok but it would take them to enter in the customers username and password details in order to do this but that to them is a pain in the a** (i put the starts in so you know hahaha).

Regards
Gary

[snadge]

@ BS - trying to think back he mentioned some figures - it may have been A/C Balance but I can not be sure, I know one of the previous ones who done A/C balance said it wasnt great, but wasnt poor either, but the last engineer done other tests AFTER the PQT and thats when he picked up on the problem, all other engineers just ran a PQT and FAST test and off they went.

- Thinking about what you just said about the DEAD PAIR (not in use) that sounds about right as you describe it, are these pairs on the MDF so close together that this sort of thing happens?

what the hell is a SPLIT LEG exactly anyway? I have googled but all I have found out is its something to do with pairing legs from different pairs - is it because the pair is not twisted that it causes problems for broadband?


@ Gary - ahh right, I see what you mean - hey Sky are recruiting in my area for CST, im applying hehe

[burakkucat]

@ snadge -- I remember certain parts of your thread quite clearly. It was observing the poor AC balance which allowed the last engineer to finally fix your line.

As for split legs, you have found the correct answer. I'll just add the comment that the xDSL transceivers operate in differential (i.e. difference) mode, so any signal that is in common on both wires of the pair is ignored. So consider a twisted pair connecting two xDSL transceivers that passes by a localised noise source. That noise is induced into both wires of the pair in (virtually) equal level and phase. Hence the noise is rejected at the receiving end. Now consider the case where there are multiple pairs, as in a typical D-side cable and, by accident, one wire from one pair is used with one wire from another pair. A telephone connected via that pair of split legs will still work without any obvious fault. However a pair of xDSL transceivers connected at each end will each be subjected to substantial induced noise signals which cannot be rejected by the differential circuitry . . . because that induced noise is not equal on each wire of the pair.    As far as the transceivers are concerned, the noise "seems" to be part of the wanted signal    and is amplified. 

[soreilly]

Hmm ?? Terminology can be the difference between success and failure. With that in mind, I'll try and put over what 'we' do on-site (or should do), but with my terminology. Other engineers may use different wording ?

The first test should always be a PQT, as if there is an underlying network fault, then by identifying and repairing it the DSL will most likely improve of its own accord. Not all engineers have HHT's, ergo not all engineers can perform a PQT. All BB/FTTC-P engineers should be HHT enabled due to the testing of higher frequencies.

The second test that I do, is that of an Eclipse or Fast Test. They're both the same low-frequency test, and IMO, unwarranted if the engineer has carried out a PQT, as this is the higher-end test. That said, it is the Eclipse/Fast Test that the SP's demand that we do. As an aside, sometimes there will be a CIDT linked to the Eclipse Test (but we engineers don't know this until the results are given back via SMS text), which is slightly more in-depth than the bog standard test. These occur on probably 5% of the tasks I attend.

The third test I will then perform is called a 'DSL Close-out' test. This can be set to the default 5 minutes, or an extended 15 minutes. This will synchronise with the ISP's Exchange Equipment and give the normal stats (Speed, SNR, Atten etc), then it will pass data back and forth for the allotted time looking for CRC,HEC and RS. It will then present a 'Pass' or 'Fail' result at the end. Both the PQT and the DSL Close-out tests are blue-toothed back to our laptops and then transferred via 'Tarvos' to a data-base for all and sundry to see. All the tests mentioned above can be done on all circuits.

As mooted by BK, 'we' are only interested in the bit from EU to DSLAM/MSAN. We can input each EU's log-on credentials and passwords into the HHT to check for a PPP Session, but TBH it's that damned awkward to do, nobody I know bothers. It's easier to ring the ISP and ask them if they can see an active PPP Session. But again, if we've proved its connected to the right Exchange Equipment we don't need to concern ourselves with the PPP side of the fence, however most of us will go that extra mile.

The red light you mention on the tester. I have a JDSU (so can't comment on the EXFO) and there are 2  lights we are concerned about, synch .... and data. The synch light will always go green if the obvious has been accomplished, the data light will go green for BT circuits thus dictating an active PPP Session, for LLU's it will remain red. This last piece of information I retrieved from one of the training guys, so can't confirm this to be absolute fact, but have no reason to disbelieve this particular gentleman.

I hope this clarifies things, or if it doesn't, I'm struggling to put it into words any better.

Hi BS,

Thanks for this insight.

The circuit was unstable from Mon - Thurs last week.  Air temperature was hot - around 28C at its peak.  On Fri the conditions changed.  It cooled to around 23C and was overcast for the majority of the day - result was that the connection became stable with just 1 dropout.  Saturday was cooler again but with broken cloud, again connection was fairly stable.

I am reluctant to book another SFI engineer because of the intermittent nature of the fault and the possible charges that will be applied.  The engineer has confirmed the circuit is testing okay.  Secondly, I cannot guarantee the weather situation.  When I booked the engineer in May, it had been dry and warm for several days and I had been experiencing the fault.  On the day of the visit, it clouded over and cooled meaning the connection became stable!

PS, sorry for the delay in replying.  My PC crashed just before I went on a run of night shifts and I've only just fixed it.

[snadge]

@ snadge -- I remember certain parts of your thread quite clearly. It was observing the poor AC balance which allowed the last engineer to finally fix your line.

As for split legs, you have found the correct answer. I'll just add the comment that the xDSL transceivers operate in differential (i.e. difference) mode, so any signal that is in common on both wires of the pair is ignored. So consider a twisted pair connecting two xDSL transceivers that passes by a localised noise source. That noise is induced into both wires of the pair in (virtually) equal level and phase. Hence the noise is rejected at the receiving end. Now consider the case where there are multiple pairs, as in a typical D-side cable and, by accident, one wire from one pair is used with one wire from another pair. A telephone connected via that pair of split legs will still work without any obvious fault. However a pair of xDSL transceivers connected at each end will each be subjected to substantial induced noise signals which cannot be rejected by the differential circuitry . . . because that induced noise is not equal on each wire of the pair.    As far as the transceivers are concerned, the noise "seems" to be part of the wanted signal    and is amplified. 

excellent explanation there B'Kat and thank you  - thats how I thought it would happen - so when this engineer said i had a SPLIT LEG it means when sky switched my phone from WLR3 to SVBN it did so onto a pair with "SPLIT LEGS" and why my phone still worked but broadband suffered, kinda shocking that all the other engineers did ignore this A/C Balance thing cos I know 2 of them defo tested for that including the first Broadband/SFI Engineer...

@ soreilly - I sympathise with you 100%, its going to be a right twit to get sorted out, I dunno if theres much more you can do, perhaps write to your ISP's CEO office and complain, when I got mined involved they bent over backwards to help, If your very persistent you will get it done and just refuse to pay any costs, did you say you are with PlusNet...? cant remember, but i know they do (or used too) keep records of users connections, such as speeds they are getting every hour of everyday and how many dropouts etc (I seen a pic of it somewhere) so if you have lots of dropouts on hot days then they will be able to see this on their system and therefore should recognize there is a fault, it will call on you to be a bit persuasive with engineers that come out and try and get them to do extensive testing not only more than PQT's but also all other possible tests and at all points down the line to the exchange - either that or ditch your DSL connection for a Virgin Cable one..

[soreilly]

@ soreilly - I sympathise with you 100%, its going to be a right twit to get sorted out, I dunno if theres much more you can do, perhaps write to your ISP's CEO office and complain, when I got mined involved they bent over backwards to help, If your very persistent you will get it done and just refuse to pay any costs, did you say you are with PlusNet...? cant remember, but i know they do (or used too) keep records of users connections, such as speeds they are getting every hour of everyday and how many dropouts etc (I seen a pic of it somewhere) so if you have lots of dropouts on hot days then they will be able to see this on their system and therefore should recognize there is a fault, it will call on you to be a bit persuasive with engineers that come out and try and get them to do extensive testing not only more than PQT's but also all other possible tests and at all points down the line to the exchange - either that or ditch your DSL connection for a Virgin Cable one..

Hi snadge,

I agree it will be a pain to sort out.  I'm actually with Xilo on their Be LLU product.  With regards to the logs for dropouts etc, it doesn't always dropout, the SNR just fluctuates wildly.  So I could have a line that fluctuates wildly but only drops a couple of times, and that is all that would be recorded on my ISPs logs. 

I'm continuing to monitor it along with checking the area for any REIN (no joy so far).

As for moving to Virgin, things are not that bad yet.