Print

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

[waltergmw]

The following data illustrates a problem we’ve had for over two years now on a line of about 7 km.

Amongst other noise problems the modem loses sync when an incoming call is answered but BT are unable, (at least to date) nor are they obliged to solve the problem. It is not helped that their JDSU tester syncs at a substantially lower speed thus making it less likely to fail its tests. However even the JDSU has failed upon occasion.

There can be little doubt that the line is noisy given the number of errors reported and the fact that all cables and some metalwork in the area have significant noise present both on their screens and on individual pairs as illustrated by using a tone tracer - see picture and noise sample seemingly from an electric fence somewhere.

The latest SFI (Special Fault Investigation) attempt has resulted in the suggestion to cap the line at 500 Kbps which, given that a good modem can sync at up to 1400 Kbps seems quite unsatisfactory.

The line was supplied with a Thompson 785 modem which often re-syncs at 1120 Kbps or less thus forcing the IP Profile down to only 750 Kbps for days at a time. The major problem has been hidden by replacing the modem with a 2Wire 2700 HGV; that still loses sync but less frequently and it recovers to speeds well in to the 1000 Kbps IP Profile range.

Can anyone suggest other investigations or test equipment to record the noise levels during incoming calls? A lift and shift has been done in the exchange but this has not solved the problem.

Tone tracer http://www.scribd.com/doc/35745267

TG784 modem data http://www.scribd.com/doc/35745271

2700 HGV Modem diagnostic data  http://www.scribd.com/doc/35745336

JDSU Line test  http://www.scribd.com/doc/35745334

JDSU ADSL summary page http://www.scribd.com/doc/35745295

JDSU ADSL page 1 result http://www.scribd.com/doc/35745307

JDSU ADSL page 2 result http://www.scribd.com/doc/35745318

Please change the extension of the following jpg file to mp3 to play the sound.

Kind regards,
Walter

[attachment deleted by admin]

[sevenlayermuddle]

Walter,

Not sure if this provides any inspiration, but to me the audio file sounds very similar to the sort of thing you get from a radio held close to a cheap switch-mode PSU such as often built into 13A plug/power bricks? 

- 7LM

[waltergmw]

@ 7Lm,

Thanks very much. I believe the ticking is much more widespread. I've got the volume turned up so there's a
lot of mains hum. It's the ticking over many hundreds of yards even in underground cables and in this case just a galvanized cable guard on a pole.
I expect this is a feature causing many errors but I suspect the major problem is some form of significantly increased noise level when the phone is off hook.

Perhaps this is one for Kitz ? We've tried many different filters this end but what if the equivalent exchange filter circuit has been "roasted" ?
Am I correct in thinking there's a bank of filters all assembled on a card or group of cards ?
When the phone is on hook there is a potential of about 90 Volts between the pair and that drops to about 20 when it's off hook ?

Perhaps I need an oscilloscope (if such things still exist) on the line ?

Kind regards,
Walter

[razpag]

The following data illustrates a problem we’ve had for over two years now on a line of about 7 km.

Amongst other noise problems the modem loses sync when an incoming call is answered but BT are unable, (at least to date) nor are they obliged to solve the problem. It is not helped that their JDSU tester syncs at a substantially lower speed thus making it less likely to fail its tests. However even the JDSU has failed upon occasion.

There can be little doubt that the line is noisy given the number of errors reported and the fact that all cables and some metalwork in the area have significant noise present both on their screens and on individual pairs as illustrated by using a tone tracer - see picture and noise sample seemingly from an electric fence somewhere.

The latest SFI (Special Fault Investigation) attempt has resulted in the suggestion to cap the line at 500 Kbps which, given that a good modem can sync at up to 1400 Kbps seems quite unsatisfactory.

The line was supplied with a Thompson 785 modem which often re-syncs at 1120 Kbps or less thus forcing the IP Profile down to only 750 Kbps for days at a time. The major problem has been hidden by replacing the modem with a 2Wire 2700 HGV; that still loses sync but less frequently and it recovers to speeds well in to the 1000 Kbps IP Profile range.

Can anyone suggest other investigations or test equipment to record the noise levels during incoming calls? A lift and shift has been done in the exchange but this has not solved the problem.

Tone tracer http://www.scribd.com/doc/35745267

TG784 modem data http://www.scribd.com/doc/35745271

2700 HGV Modem diagnostic data  http://www.scribd.com/doc/35745336

JDSU Line test  http://www.scribd.com/doc/35745334

JDSU ADSL summary page http://www.scribd.com/doc/35745295

JDSU ADSL page 1 result http://www.scribd.com/doc/35745307

JDSU ADSL page 2 result http://www.scribd.com/doc/35745318

Please change the extension of the following jpg file to mp3 to play the sound.

Kind regards,
Walter

Hi Walter

This sounds to me like a very simple 'HR fault'. HR = High Resistance, and as such the cable poundage will have corroded away to a fraction of its original diameter (due to water ingress usually) and this in turn halts the flow of current required to power both the router and the phone. I come across this type of scenario most days in my guise as a Broadband Engineer for Openreach.
The previous engineers should have carried out a 'PQT' (Pair Quality Test), which can sometimes highlight the 'HR fault' by showing a difference in leg resistance. In other words, the 2-wires that run from the exchange to your socket should really be within a couple of ohms resistance of one another. If 1 wire has corroded more than the other, this will have a higher ohms reading showing that here is high resistance on the line.
However, it depends on the severity of the 'HR' as to whether the PQT will pick this up. What I would be asking the engineer to do is to put a 'Mole' or use the TDR function of his HAWK tester and to look back down the wires with it towards the exchange whilst the line is 'live'. There's a good chance a 'peak' will show on the screen where the 'HR' is. Small HR's are easier to find measuring back from the socket whilst the nominal working voltage is applied from the exchange.
Seeing as you commented that a 'Lift & Shift' has already been carried out, then apart from a dodgy filter, this is really the only reason left that a router would drop synch when the phone is in use !!! It doesn't matter a jot how long your line is, you should be able to use the phone while the router remains in synch. I work on routes that are quite a bit longer than yours and would have stuck with your fault until I had it resolved. best of luck mate.

[waltergmw]

Hi RazPag and thanks for your suggestions.

We had thought it was a HR fault but suddenly, after a 59 second disturbance, the problem is solved. Frustratingly my BT O contact sees no record of what was done.

http://www.ewhurst-broadband.org.uk/wp-content/uploads/2010/08/Line-disturbance.jpg

The ISP's explanation is not very convincing either "They basically upgraded the line to a higher DSLAM.".
The DSLAM type is still registered as TI.

My guess with only a 59 second drop, is that a board was swapped or just possibly a new jumper had been installed except for the final connection pair.

@ 7LM & Peter geep,

Compared with your DLM discussions, I'm quite surprised that the line is rock solid and all that changes in very small amounts are the tone line lengths and the max figures only.
There hasn't been a single re-sync despite a large number of FEC errors running at over 30,000 per day. The config. picture is included below.

Kind regards,
Walter

[attachment deleted by admin]

[razpag]

Glad it's sorted. Not 100% sure, but can't see it being a new jumper as it would take more than 59 seconds to run and terminate the wiring. That is unless you are on a very,very small exchange with the MDF being only a few feet long.

[waltergmw]

I don't think I'd call this one very very small

http://www.samknows.com/broadband/exchange/THCN

I just wonder if a new jumper pair had been pre-configured on the exchange side and just leaving the final existing jumper pair to be exchanged with the new one; but I agree it's unlikely.

Whatever was done must have had an almost zero re-boot / re-authenticate time.

EDIT But if it was work on the SMPF phone side, that probably wouldn't have involved any re-authentication ?

Kind regards,
Walter

[waltergmw]

@ 7LM,

The investigation continues. As far as I can tell the modem is dropping occasionally but NOT because of answering phone calls.
However as the house is unoccupied at present, I can only prove that when I ring the number and it doesn't drop sync.

The following picture is quite interesting, perhaps towards your DLM studies.
Noting that the 2Wire gives the time of the start of the last run EXCEPT for the bottom time entry which is time now.

Between 2010/08/22 12:54:42 and  2010/08/23 11:31:38 with a MGN2 (Current or Final Noise margin) of 6 the modem averaged 57 downstream CRC errors per hour.

Between 2010/08/23 11:31:38 and  2010/08/23 17:39:48 (Time of reading the data) with a MGN2 (Current or Final Noise margin) of 9 the modem averaged 1196 downstream CRC errors per hour.
I was expecting that with the higher margin the CRC errors would drop somewhat rather than increase.
If this is down to line conditions changing significantly I'm still very puzzled.
I wonder if there's some special logic involved when the DSLAM and DLM logic recognise the BT Business Hub ?

With the 2Wire, with 1 exception the achieved rate is remarkably constant and all-importantly always stays well above the critical 1152 thus keeping the bRAS at 1000 kbps.

Kind regards,
Walter

[attachment deleted by admin]