Print

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

[Weaver]

This is the second time I've noticed this problem:-

BT Test xDSL Copper Test:Pass Openreach network fault found.Pass Openreach network fault found. T051:FAULT - Battery Contact

The first occasion was on Boxing Day morning. It was cleared after just a couple of hours, presumably by human intervention. ( http://forum.kitz.co.uk/index.php/topic,16647.0.html )

I performed a "copper line test" using the Andrews & Arnold clueless.aa.net.uk control panel server, and on both occasions the above was the error message produced.

[Weaver]

The resulting high rate of packet loss on this one line meant that my total downstream throughput  dropped from 6.4 Mbps to ~0.6 Mbps (!) and I could only fix it by power cycling modem #3.

It's always this line that gets into this 'dripping blood' state - red streaks coming down from the top of the continuous quality monitoring graph, indicating loss of PPP LCP echo requests (the PPP equivalent of 'ping'). It's never one of the other two lines in the bonded set. There is also a new modem on each line, so it is definitely not a bad modem.

[Weaver]

God it really makes me glad that I've got more than one line. It takes about 10 seconds to switch one out if it goes bad and move over to load onto the other two. The load fraction apportioning  across the three lines seems to be much more fluid, it changes much more rapidly now as it follows the speed is the BT reports from the BRASs, since I changed to ADSL2 from ADSL1.

On such long, and at times, unreliable lines it really helps having the redundancy. Keeps the show on the road.

I have tweeted A & A, who are working today - Thursday, 2012-12-31.

[Weaver]

I thought occurs to me. The sync rate as gone down, but the SNRM has not increased. So surely this means there is actually more noise on the line than before. This is not merely DLM in action but a change in the line.

* Am I correct in my thinking?

[Weaver]

By the way what does FTB stand for? It's in the context of sync rates.

Is it perhaps fault <something> breach, from extremely dicey memory?

[Weaver]

A & A say it's something between me and the exchange. Raised a fault with Openreach

[Weaver]

I was told the following, by another AA user, IRC username Farnz (Simon Farnsworth) :-

“And TO51 means that the voltage measured on your line does not match BT's expectations given their battery pack feeding the line, but that current draw is not high enough to cause BT to think that it's something plugged into the line.”

farnz: “Lots of possible causes for that - damaged line, miswired extensions, fault in the exchange etc.”

Thanks to Simon for that info.

[Weaver]

Openreach ETA at exchange is before end of 2016-01-02

[aesmith]

By the way what does FTB stand for? It's in the context of sync rates.

Fault Threshold Breach.  Means the synch rate is below the Fault Threshold Rate as recorded for your line, and therefore the low synch speed in itself should be taken as a fault.   I say should, because I saw one guy on an ISP who will not be named who was simply told that the MSR and FTR recorded for his line were unrealistic - they then went ahead and restarted the training process on his degraded line.

[Weaver]

Thing is, I'm still in the training period. I'll sort out the MSR etc after the fault is fixed and after the training period has expired. Then might put it straight back into the training phase at a much higher sync rate, like that of the other two lines which are both 2700-2900 kbps d/s sync, not ~2100.

[aesmith]

Did you see this on the output from BTW "xDSL Status Check"?   Is so, does it show MSR and FTR?   

I have a feeling that these are preset to some values at the start of the training period, but that's just based on the facts that (1) my line has MSR/FTR date stamped around 7 days before we first had DSL so clearly ours aren't measured values, and (2) because an ISP faults guy told me that he's often seen those exact figures on other lines where they aren't appropriate, leading him to think there's some sort of default value.   Would be interested in what your figures show.

[Weaver]

They are preset to junk values at the start of the training phase, so it seems.

Here's the output from the latest status report I requested :-

Code: [Select]

Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=1856Kb/s FTR=2272Kb/s MSR=2272Kb/s ServOpt=1 I/L=I
Up Sync=402Kb/s LoopLoss=43.3dB SNR=6dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2218Kb/s FTB LoopLoss=66dB SNR=6dB ErrSec=0 HECErr=N/A Cells=0

[licquorice]

Battery contact means that somewhere between you and the exchange one leg of your pair is shorting to the negative (battery) leg of another customer's pair. A dodgy wet joint somewhere.

[Weaver]

Track WLR Fault 5-7-88548862536 Informational Message: 4040 Notification only - Estimated Response Time.   bt
Today 10:30:52      Track WLR Fault 5-7-88548862536 Informational Message: 3100 Trouble Report Accepted   bt
Today 10:30:52      Track WLR Fault 5-7-88548862536 Estimated Response Time: 2016-01-02T23:59:59   bt
Today 10:30:52      Track WLR Fault 5-7-88548862536 Status: Open - New   bt
Today 10:30:38      Track WLR Fault 5-7-88548862536 Message Informational 9323 The asset care level 2.5 will be applied rather than the specified service level.   bt
Today 10:30:37      Track WLR Fault 5-7-88548862536 Message Informational 3241 Notification Only - Trouble Report Creation Request is Pending   bt
Today 10:29:59      WLR3Test NSY rds00556app02:282166782: Fail FAULT - Battery Contact ServiceLevel:2.5, MainFaultLocation:LN, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement:   steve@a
Today 09:35:03      WLR3Test NSY dys00556app06:275200991: Fail FAULT - Battery Contact ServiceLevel:2.5, MainFaultLocation:LN, FaultReportAdvised:Y, AppointmentRequired:N, LineStability:, NetworkStability:, StabilityStatement:

[Weaver]

Thanks liquorice