Print

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

[les-70]

 Hi.  I have an ex Nildram connection with Talk Talk Business .  I have been pleased with the connection for a few years then suddenly a few months ago there was a 13 hour disconnection and then a drop in performance.  I contacted Talk Talk and established that the DSLAM had been moved within the exchange but no remedial action was offered.  A few weeks later there was full telephone fault and the line was reconnected in the CAB and possibly also in the exchange, some improvement occurred.  Another few weeks later the DSLAM card failed and a lift and shift was made to another card.  There was again a little improvement and since then all has been stable and although not as good as before, it is good enough for me.

   Looking an the DMT stats I would like to understand the Hlog graph as this may contain some insight into what caused the deterioration.  The graph went from the original smooth decay to a decay with a broad hump.   This does not look like the usual bridged tap impact but maybe that impact broadens depending on where in the line the tap is.

 
   My CAB seems busy and I have had CAB disconnects twice in three years.  Both a pain but quickly fixed with an easy fault report.

   In case of any other future change or fault occurs I would like to be as prepared as possible for the engineer.  Please can anyone offer guidance on interpreting Hlog graphs and what the changes in mine may suggest.

     Thanks in advance

[les-70]

    At risk of answering my own query I have checked other dmt screen dumps on my laptop and looked carefully at dates.  The current line sync degradation of about 1.5Mb/s looks as through it may have occurred just before the DSlAM move.    I think the extra DMT plot below is few days before the DSLAM move and it looks like the current one (with due allowance for time of day of sync).

    I have also been googling and have read a few useful docs -see below-. From these it looks like a bridged tap of about 50m may have been added.  The amplitude is weak suggesting it at my end of the line and not near the exchange.  Alternatively I don't know if taps can occur capacitively? and look weak.  Assuming I get an engineer in the future I will get him to check for this with a TDR. Other sugestions most welcome!
   

 

  http://www.ncc.org.in/download.php?f=NCC2008/2008_P2_1.pdf
    useful examples

  http://documents.exfo.com/appnotes/anote233-ang.pdf
     another example

   http://www.analog.com/library/analogDialogue/archives/34-05/vdsl/VDSL.pdf
     with a bit more on bridged taps

  http://www.elsinco.hu/szeminarium/pdf/manage_your_todays_and%20future_copper_access_network.pdf
     Interesting examples
 
 http://www.jdsu.com/NoIndexLiterature/JDSU_TriplePlay_book_1107.pdf
   with a lot of info and few relevant examples

 

[les-70]

  oops -sorry.  I did not remember to add the extra dmt plot now here



[attachment deleted by admin]

[asbokid]

Some very interesting papers, les-70.  Thank you for drawing attention to them :-)

DMT has a lot of graphing bugs or quirks, which make it difficult to know what we are looking at.

The plots overshoot past XMAX. The plotting code is buggy and doesn't adjust the interval when the first few DMTs are left for POTS.  The Hlog is also plotted upside down to the norm.   Attenuation is usually plotted on a negative Y axis, and runs vertically downwards from 0dB to -100dB.  The SNR graph is also absent from DMT#32 to DMT#64 even though these tones are utilised in the downstream band.

Perhaps the biggest problem with the DMT graphs, which renders them useless for studying VDSL2 tonemaps, is the lack of detail to them.  The graphs need to be vectorised using SVG or similar, and there should be zoom and scroll facilities.

What specifically looks like a bridge tap on your line? The papers you have linked illustrate the tap as a series of narrowband notches in the Hlog graph. These manifest at the fundamental frequency of the wave that is reflected back from the tap end, and at its harmonics.

However, your Hlog graph shows a single broad hump (actually a broad trough once the graph is correctly inverted).

To my untrained eye, the chief anomaly is the drop in bit depths between ~DMT#32 and ~DMT#56.  This is probably due to crosstalk from other pairs carrying xDSL signals.   There are also a couple of very focussed areas of noise at ~DMT#150 and ~DMT#280.  This noise hasn't moved in any of the plot so perhaps it is due to RF noise or internal noise at the transceiver?

Interesting topic, thanks for posting 

cheers, a

[c6em]

As I understand Annex M it moves the split point between the upload spectrum and the download spectrum from 138KHz to 276KHz.
So it is grabbing more of the spectrum available for the upload than previously.
Hence only lines which already have have very high sync on ADSL2+ are suitable candidates for Annex M.  The rest would loose too much of the download section.

If so then in the images, it is the DMT program that is incorrectly plotting as "blue" this section (138 to 276) in the graphs when it should be in green as it is the upload section.

Shame the DMT program is no longer being developed or open sourced ('fraid my program skills date from writing number crunching engineering programs in Fortran)

[les-70]

 Thanks for the responses. Yes the DMT overplot seems to be linked it not really liking annex m.  Looking at "adslctl info --Hlog" the DMT frequencies are roughly correct and the broad hump has its centre in the region of 1Mhz.   This hump matches a calculated loop length of about 50m. See

   http://www.jdsu.com/ProductLiterature/loopanalysis_an_tfs_tm_ae.pdf  For clear statement of calculation details - I should have had this in my list. Most of the references go with vdsl and with it short taps seem more of problem.  This is probably why Openreach always get rid of house wiring effects with a filter on the face plate. Taps longer than 10m are also an ADSL2 issue.

 Also the second of my earlier references "anote233-ang.pdf" has a "figure one" which shows a curve for a 150ft bridged tap ie about 50m. In the example the Hlog change is about 12db and very similar to that shown in my DMT (with due allowance for just plotting just the ADSL2 frequencies and the different Hlog scales)  The amplitude of the effect is supposed to depend on where the tap is.  The biggest problems are stated to occur with a tap near the exchange but I am not sure I understand this, allowing for attenuation after or before the tap seems to give a  similar result to me.

  Perhaps someone who has had experience with finding and getting fixed humps which suddenly appear in the attenuation might know more. 

[asbokid]

As I understand Annex M it moves the split point between the upload spectrum and the download spectrum from 138KHz to 276KHz.
So it is grabbing more of the spectrum available for the upload than previously.
Hence only lines which already have have very high sync on ADSL2+ are suitable candidates for Annex M.  The rest would loose too much of the download section.

Oops! Thanks for the correction.  Sorry. I couldn't really make out what I was looking at.

If so then in the images, it is the DMT program that is incorrectly plotting as "blue" this section (138 to 276) in the graphs when it should be in green as it is the upload section.

Shame the DMT program is no longer being developed or open sourced ('fraid my program skills date from writing number crunching engineering programs in Fortran)

Most of the codebase is open source. It's in C but quite easy to understand. However, the most important part - the graphing functions - are obsolete and everything is hard-coded to specific pixels in a very small bitmap. This makes it very difficult to modify.

I had a tinker with updating the code for VDSL2 and got it to plot Profile 8c data correctly. But then with the advent of Profile 17a, and all those extra tones, too much definition is lost in the graphs. You can't identify anything meaningful from them.

Paul @ sbrk.co.uk and I were talking about re-writing it using a more up-to-date image rendering library, such as libsvg.  In theory you could get the router itself to generate an XML file containing the SVG definitions for the line statistics data. A browser plugin would then be used to actually render the graphic on the PC.

cheers, a

[asbokid]

Will the graphing scripts developed by Bald_Eagle work for an ADSL connection?

You might find this interesting, les-70....  It's an excerpt from Walter Chen's book on transmission lines...

http://huaweihg612hacking.files.wordpress.com/2012/04/chen_wy-home_network_transmission_environments_chapt2_twistedpairs-2.pdf

cheers, a

[jeffbb]

Hi
quote The Hlog is also plotted upside down to the norm
Makes no real difference   
This way it can be read directly as the attenuation per tone , Routerstats plots it the same way . The higher the frequency the greater the attenuation (the more negative the Hlog value).
@les70
Some useful reading material  will read and try to inwardly digest .

Regards Jeff

 

[les-70]

 Thanks for the extra reference.  That is good for showing a more detailed calculation basis.  Thanks also for the plot comments. The vagaries of the plots don't really matter as long as your aware of them, RouterStats is similar -see below.   

 The evidence seems to be consistent with an extra bridged tap in the region of 50m being added so I am now wondering what work in the Exchange, CABS or junction boxes could suddenly cause this to be added?  The home wiring has been static with a straight connection to a filtered face plate on the master socket and 50m is much too long for this house!

[attachment deleted by admin]

[jeffbb]

Hi
@les70
Have you tried to use The SNR margin rather than the SNR per tone  plots I find the margin info more informative .
Regards Jeff

[les-70]

   I am aiming to focus on understanding what changes in my line could suddenly be made to add the dips to the attenuation curve.  It is the attenuation curve that is used help identify the presence of bridged taps.

   I attach the above Routerstats plot and flipped and stretched it to put it more in line with the usual way of plotting attenuation.  The attenuation is the black curve running through the bits per tone bars.  For scales it is best look at the un-stretched version.  Does anyone else have these dips and have they had such dips fixed?  Maybe an Openreach person could comment? My change is is not bad enough to warrant an engineers visit but, as I said, I would like to be well prepared for making the most of any future visits.

[attachment deleted by admin]

[Bald_Eagle1]

@les-70,

   I am aiming to focus on understanding what changes in my line could suddenly be made to add the dips to the attenuation curve.  It is the attenuation curve that is used help identify the presence of bridged taps.

   I attach the above Routerstats plot and flipped and stretched it to put it more in line with the usual way of plotting attenuation.  The attenuation is the black curve running through the bits per tone bars.  For scales it is best look at the un-stretched version.  Does anyone else have these dips and have they had such dips fixed?  Maybe an Openreach person could comment? My change is is not bad enough to warrant an engineers visit but, as I said, I would like to be well prepared for making the most of any future visits.

I too am trying to understand Hlog graphs & in particular trying to get to grips with what causes sudden increases in attenuation etc.

Using this raw data from my modem's log file for a VDSL2 connection & concentrating on tones around 1700, you can plainly see in the resulting graph the slight hump (reduced attenuation) & then the dip (increased attenuation).

Code: [Select]

   1684 -70.7500
   1685 -70.7500
   1686 -70.7500
   1687 -70.7500
   1688 -69.5625
   1689 -69.5625
   1690 -69.5625
   1691 -69.5625
   1692 -69.5625
   1693 -69.5625
   1694 -69.5625
   1695 -69.5625
   1696 -71.0625
   1697 -71.0625
   1698 -71.0625
   1699 -71.0625
   1700 -71.0625
   1701 -71.0625
   1702 -71.0625
   1703 -71.0625
   1704 -71.5000
   1705 -71.5000
   1706 -71.5000
   1707 -71.5000
   1708 -71.5000
   1709 -71.5000
   1710 -71.5000
   1711 -71.5000
   1712 -77.7500
   1713 -77.7500
   1714 -77.7500
   1715 -77.7500
   1716 -77.7500
   1717 -77.7500
   1718 -77.7500
   1719 -77.7500
   1720 -71.5625
   1721 -71.5625
   1722 -71.5625
   1723 -71.5625
   1724 -71.5625
   1725 -71.5625



The dips & humps are not always present in my own Hlog graphs, suggesting they are of an intermittent nature.
Following the engineer's work last weekend, the curve is much smoother, but a smaller dip still exists at the same tone(s) as shown in the above graph.


TBH, I can't quite determine what we are looking at in your own graphs.

Do you happen to have the raw data available i.e. tone No. & attenuation for each tone?

Cheers,


Paul.

[les-70]

  Thanks for the reply.  I attach a log file with my current values.  These values are consistent with the DMT and Routerstats plots.  I don't have actual values from when all was good but the start and end attenuations were then much the same but with a smooth curve in between and the snyc about 2Mb/s faster. 

  You will see that I have broad humps similar to those shown in the links to the PDF documents above ( eg http://documents.exfo.com/appnotes/anote233-ang.pdf ). I am guessing bridged taps and wondering how and where they may have been suddenly added.

   Your sharp feature looks very different. I don't know how the noise and attenuation measurement interact (Out of interest I will think about that) but some examples in the texts show sharp feature at the same frequencies in both the respective plots.

[attachment deleted by admin]

[asbokid]

  Thanks for the reply.  I attach a log file with my current values.  These values are consistent with the DMT and Routerstats plots.

Below, GNUplot [1] was used to multi-plot your Hlog tonemap (blue) against my own (red).

A 'correct' range was used for the y axis. This illustrates that the 'hump' in your graph around DMT#300 represents less attenuation. In other words, the hump cannot be caused by a bridge tap since the wave reflections from a tap would increase attenuation, not reduce it.

Other notable features include the ~15dB increase in attenuation around DMT#35 in my hlog response (red): probably crosstalk from other pairs carrying xDSL in the distribution bundle.
Also note that we both have an insignificant increase (<5dB) in attenuation around DMT#365.

EDIT: The 'elephant in the living room' is your hlog channel response up to DMT#70.  It's not typical. Perhaps the corresponding QLN and SNR datasets could shed some light.

cheers, a

[1] http://www.gnuplot.info/