Kitz Forum

Broadband Related => ADSL Issues => Topic started by: les-70 on April 05, 2012, 02:51:15 PM

Title: Help interpreting Hlog graphs
Post by: les-70 on April 05, 2012, 02:51:15 PM
 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
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 08, 2012, 11:19:58 AM
    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

 
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 08, 2012, 11:49:30 AM
  oops -sorry.  I did not remember to add the extra dmt plot now here



[attachment deleted by admin]
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on April 08, 2012, 02:24:58 PM
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

Title: Re: Help interpreting Hlog graphs
Post by: c6em on April 08, 2012, 04:50:18 PM
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)



Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 08, 2012, 05:11:29 PM
 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. 
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on April 08, 2012, 07:46:27 PM
Quote from: c6em on April 08, 2012, 04:50:18 PM
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.

Quote
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
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on April 08, 2012, 08:06:51 PM
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
Title: Re: Help interpreting Hlog graphs
Post by: jeffbb on April 08, 2012, 11:01:01 PM
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

 
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 09, 2012, 09:40:15 AM
 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]
Title: Re: Help interpreting Hlog graphs
Post by: jeffbb on April 09, 2012, 01:26:55 PM
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
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 11, 2012, 08:34:36 AM
   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]
Title: Re: Help interpreting Hlog graphs
Post by: Bald_Eagle1 on April 11, 2012, 01:43:21 PM
@les-70,

Quote from: les-70 on April 11, 2012, 08:34:36 AM
   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

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1255.photobucket.com%2Falbums%2Fhh629%2FBald_Eagle1%2FHlog-20120325-2047.png&hash=0ff064637a2f58dcd3f62a03005ca3729c33883b)

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.
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 11, 2012, 02:30:28 PM
  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]
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on April 11, 2012, 04:26:09 PM
Quote from: les-70 on April 11, 2012, 02:30:28 PM
  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.

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fhuaweihg612hacking.files.wordpress.com%2F2012%2F04%2Fhlogcompare1.jpg&hash=969bfcda7f70f1d04957627f79702bcebed7706c)

cheers, a

[1] http://www.gnuplot.info/
Title: Re: Help interpreting Hlog graphs
Post by: Bald_Eagle1 on April 11, 2012, 04:28:31 PM
Quote from: les-70 on April 11, 2012, 02:30:28 PM
  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.


Are you transposing TDR traces & Hlog graphs?

Using some of your PuTTy log data, I ran it through my scripts to generate a Hlog only graph:-

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1255.photobucket.com%2Falbums%2Fhh629%2FBald_Eagle1%2FHlog-20120411-1412.png&hash=39b63069cd80bcd38513657057d12e72f1b232a8)

The way I understand matters, the hump roughly between tones 250 & 350 (if that is the one we are talking about) is actually a reduction in attenuation, which I THINK signifies capacitance rather than resistance (attenuation).

When considering Hlog graphs, I believe a bridged tap (increased attenuation) should look a little more like my own graph (a definite dip i.e. increased attenuation).


EDIT:

I see Asbo beat me to it by a few minutes while I was still typing  :lol:.
Mine was also a gnuplot script using my VDSL2 scripts.
Asbo's is the better graph as it has used all the tones from your PuTTy log, but the message is the same.
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 11, 2012, 04:59:30 PM
  I will need to think carefully about the replies and am really grateful for the clear plots - this is a quick reaction!

I don't understand your query over TDR and Hlog, I am just considering Hlog as I have no TDR results.

 Looking back at the old DMT screen dumps it is clear that the hump is not the real feature.  The trace used to run through the top of the hump without a dip at about tone ~230.  I therefore think the feature is dip at ~230 and not a hump at ~250. These are the feature if you superimpose tyhe old and new DMT's (printing and holding up the light!  - wish I had old actual values).  The smaller dip at 350 was always there before but has grown a bit in amplitude.   Puzzling, I would not have worried except for the sudden appearance one morning after a short loss of connection. 

 I don't understand capacitance as cause,  especially how it could give dips.  A high resistance line some capacitively coupled line is supposed show extra attenuation as the low frequencies with higher frequencies being less affected.

  Thanks for the graphs and thoughts
Title: Re: Help interpreting Hlog graphs
Post by: c6em on April 11, 2012, 05:10:57 PM
...and another one
ADSL2+ line, 2.5Km long, 36dB overall attenuation,13279 sync @ 3dB target SNRmargin

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.flickr.com%2Fphotos%2F40749086%40N02%2F7068011457%2Fin%2Fphotostream&hash=36f3fa1e1ea4cf527177a02c514c1e7837b5cabb)


[attachment deleted by admin]
Title: Re: Help interpreting Hlog graphs
Post by: burakkucat on April 11, 2012, 05:31:23 PM
And three from when I was experimenting, last February.  :)

[attachment deleted by admin]
Title: Re: Help interpreting Hlog graphs
Post by: Bald_Eagle1 on April 11, 2012, 05:31:50 PM
Quote from: les-70 on April 11, 2012, 04:59:30 PM

I don't understand your query over TDR and Hlog, I am just considering Hlog as I have no TDR results.


The document you linked to discusses TDR traces (reflected signals).

We can only obtain Hlog data from the modem (attenuation over frequency).

I managed to get a TDR test done at the weekend.
It very roughly looked like this, the large peak on the right being the DSLAM & the much smaller hump on the left being a "potential" high resistance/attenuation issue:-

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1255.photobucket.com%2Falbums%2Fhh629%2FBald_Eagle1%2FTDR_GRAPH.jpg&hash=8328d51b082edc0fe5be22ddb1bc0f626209a489)


My Hlog graph looks like this:-

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi1255.photobucket.com%2Falbums%2Fhh629%2FBald_Eagle1%2FHlog-20120325-2047.png&hash=0ff064637a2f58dcd3f62a03005ca3729c33883b)


Whether the hump from the TDR trace & the dip in the Hlog graph are one & the same thing? .... I don't know.

Quote
Looking back at the old DMT screen dumps it is clear that the hump is not the real feature.  The trace used to run through the top of the hump without a dip at about tone ~230.  I therefore think the feature is dip at ~230 and not a hump at ~250. These are the feature if you superimpose tyhe old and new DMT's (printing and holding up the light!  - wish I had old actual values).  The smaller dip at 350 was always there before but has grown a bit in amplitude.   Puzzling, I would not have worried except for the sudden appearance one morning after a short loss of connection. 

I can't answer that. Hopefully an experienced engineer may be able to shed some light for us.
However, I believe engineers may be more familiar with TDR traces than Hlog graphs?

Quote
I don't understand capacitance as cause,  especially how it could give dips.  A high resistance line some capacitively coupled line is supposed show extra attenuation as the low frequencies with higher frequencies being less affected.

  Thanks for the graphs and thoughts

I'm not clear either.
What I was trying to say was that a big dip in a Hlog graph signifies increased attenuation (resistance) & a hump in a Hlog graph can signify capacitance.

I have to admit that I'm not too sure about any of this, other than a nice steady slope is good & anything else is bad  :lol:.
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 11, 2012, 06:02:43 PM
  Not really a reply but just a clarification -- in the document I last linked,  only Figure 1 is relevant to Hlog.  The other references given earlier also show similar things but in VDSL signal bandwidth and with much shorter tap lengths.  The suggestion in the literature seems to be that looking at the attenuation mainly helps spot bridged taps. It  also seems to help see the presence of capacitive coupling through an HR.   To track down where they might be you need the TDR.

Anything other than a smooth decay is not ideal, thanks also to those posting some other examples  -it is a nice to see what things should look like.
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 11, 2012, 06:32:54 PM
  Reply to asbokid re the elephant.  I have no idea what the upstream tones 0-63 correspond to in attenuation.  I attach QLN and SNR and Bits values.   The router a DG834v4 shows the same type of thing but for 0-31 even with annex-m off.  (By the way without annex m an HG612 did really well on my line but it does not seem to support Annex m and since TalkTalk fully took over Nildram I would have to take a new contract to change from Annex m.  I do in any case use the extra upload speed. )
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on April 11, 2012, 08:06:40 PM
Quote from: les-70 on April 11, 2012, 06:32:54 PM
  Reply to asbokid re the elephant.  I have no idea what the upstream tones 0-63 correspond to in attenuation.  I attach QLN and SNR and Bits values.   The router a DG834v4 shows the same type of thing but for 0-31 even with annex-m off.

Oops. c6em solved that. You're on Annex M. I forgot that.  [1]

Quote
(By the way without annex m an HG612 did really well on my line but it does not seem to support Annex m and since TalkTalk fully took over Nildram I would have to take a new contract to change from Annex m.  I do in any case use the extra upload speed. )

The HG612 should support Annex M, after all it's only a question of different bin allocations. Maybe Annex M needs enabling first through the kernel driver using some parameter of xdslcmd. The confidential now public domain  :P  source code for Broadcom's driver should reveal how to re-enable/activate Annex M (by way of ioctl() kernel calls to the driver itself.)  See DG834GBv4_V5.01.01_src/bcmdrivers/broadcom/char/atmapi/bcm96348/atmapidrv.c  [2]  Maybe not worth looking at if VDSL2 is just around the corner for you.

You seem very interested in TDR.  If you've got an oscilloscope, it can be used for TDR with the addition of a low-cost signal generator  [3]

Burakkucat, BaldEagle, Walter and I, were talking about building an ultra-low cost TDR meter.

In theory, if a laptop is used for the processing and the display of the waveform then the data acquisition and signal generation circuits for TDR should only cost a few pounds.

USB-based oscilloscopes based on an ARM7/9 microcontroller are available for <£20 but their low sample rate (<100KS/s) is not suitable for TDR. [4]  For TDR for cable testing, a sample rate of 100MS/s would be necessary. But the cost of the pre-built equipment then soars to £100+.

TDR for cable testing only requires a single data acquisition channel in the ADC. But to run at 50MHz+, the device also needs a very fast data bus from the ADC controller to the CPU/DRAM, to store those converted sample values, ready for processing.  With no fast bus (PCI, etc..), the RaspberryPi has a major shortcoming here which precludes many industrial applications. It would be interesting to open a BT Hawk or a 301C tester to see how it is achieved on those boards.

cheers, a

[1] http://forum.kitz.co.uk/index.php/topic,10970.msg214555.html#msg214555
[2] http://huaweihg612hacking.wordpress.com/2011/07/26/broadcom-drivers-source-code/
[3] http://www.epanorama.net/circuits/tdr.html
[4] http://www.ebay.co.uk/itm/2-Channel-PC-Computer-USB-Digital-Storage-Oscilloscope-/330702243984
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on April 11, 2012, 09:32:55 PM
Quote from: les-70 on April 11, 2012, 06:32:54 PM
  Reply to asbokid re the elephant.  I have no idea what the upstream tones 0-63 correspond to in attenuation.  I attach QLN and SNR and Bits values.   The router a DG834v4 shows the same type of thing but for 0-31 even with annex-m off.  (By the way without annex m an HG612 did really well on my line but it does not seem to support Annex m and since TalkTalk fully took over Nildram I would have to take a new contract to change from Annex m.  I do in any case use the extra upload speed. )

Baldie is the resident graphing guru. Below is my feeble effort tho' with your data:  The ImageMagick rendering library can't cope with a montage of SVG images. The file bloated to 64MB and then crashed  :lol:

cheers, a

EDIT: corrected ylabel on QLN
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 12, 2012, 01:17:54 PM
  Many thanks to asbokid for the extra graphs, they make things as clear as possible.  I am going to try to use GNUplot.  I was just getting going using visual Fortran running in Windows and it was likely to take me quite a few hours. That probably tells about how long it is since I last did such things.

    I am hopeful of FTTC later this year, my CAB is in the town centre and scheduled to be done but I have my suspicions that BT can sell businesses more expensive things if they don't put in FTTC.

    I have been thinking about Bald_Eagle1's graph.  My current understanding is that the router measurement of attenuation is not significantly affected by noise until the SNR is small.    The Hlog plot should tend to get ragged as the SNR gets low and goes towards zero.  Then finally when the signal is less than the noise the attention per tone should be very ragged and roughly level (as level as QLN) representing noise.  The graph shows higher tones with quite large attenuation of about 70db so I guess that noise must be starting to be significant and giving the slightly ragged look to the curve. This seems to be supported by the other plots that people have helpfully posted.  If this is true I think the dip may be just be tones with extra noise and come and go as the noise does. If it comes and goes at the same time as problems occur the problem may be linked to the noise and not to the "real attenuation" that would be seen with less noise.  The  A full plot of your HLog and SNR for all tones should tend to confirm or discredit this view of things.

   Thanks again to all
Title: Re: Help interpreting Hlog graphs
Post by: c6em on April 12, 2012, 02:30:13 PM
My Quiet Line Noise plot to go with the attenuation one I submitted above
I'm on top of a hill in central southern UK - the spikes will be radio stations (Radio 5 live etc)
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on April 12, 2012, 03:16:49 PM
Quote from: les-70 on April 12, 2012, 01:17:54 PM
  Many thanks to asbokid for the extra graphs, they make things as clear as possible.  I am going to try to use GNUplot.

Go for it. GNUplot is very intuitive to use. Very easy way to get graphing. Hugely configurable.  Another Open Source gem.

Quote
A full plot of your HLog and SNR for all tones should tend to confirm or discredit this view of things.

Your wish is my command!  :angel:

cheers, a


P.S. just to repeat a request made six months ago..

Is anyone interested in developing some graphing code to run natively on the MIPS32 core in the Huawei (and the ECI)?

The code would retrieve the tonemaps (Bits/QLN/SNR/Hlog) from the kernel driver.  Those maps are just large (4096 element) integer arrays.

The tool would use those four arrays to generate the SVG (scalable vector graphics) definitions to plot the four graphs (Bits/QLN/SNR/Hlog).

SVG definitions are described in XML (tree-based text files).

In theory the XML can be generated directly without using any additional software libraries nor an XML encoding engine (space being the limiting factor).

The XML-based SVG graphs would become embedded objects in an HTML resource.

New static web pages would be added to the 'webimg' used by the embedded webserver running on the Huawei (and the ECI).

Those web pages would contain server-side scriplets to invoke the graphing code.

The scriplet engine would embed the response (the SVG XML) from our code into the static HTML.

The HTML complete with graphics would be served up to clients.

To do it nicely, that's about a week's work. Maybe less.   Anyone interested?
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 12, 2012, 03:42:04 PM
  Thanks for your full plot, I should have said that its Bald_Eagle1's full plot that is needed to understand his Hlog features.

  Regarding yours you have nice low attenuation but more noise than me.    The swings and roundabouts of lines I guess.  Your SNR stays high over the full range so the Hlog should stay smooth looking. I also suspect that you have a bridged tap somewhere of about 30m length (the dip around tone 350), the impact looks very small .    I seem to have a bigger ~50m feature and the ~30m one as well. 
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on April 12, 2012, 05:31:23 PM
Quote from: les-70 on April 12, 2012, 03:42:04 PM
I also suspect that you have a bridged tap somewhere of about 30m length (the dip around tone 350), the impact looks very small .

That attenuation 'feature' is probably due to frequency-dependent reflection losses from an impedance mismatch.

At a guess, the cause is a poor splice, perhaps a change in cable parameters, rather than a bridge tap.

cheers, a
Title: Re: Help interpreting Hlog graphs
Post by: Bald_Eagle1 on April 12, 2012, 05:44:25 PM
Quote from: les-70 on April 12, 2012, 03:42:04 PM

  Thanks for your full plot, I should have said that its Bald_Eagle1's full plot that is needed to understand his Hlog features.


Full plot for that same period attached.

It is low resolution, but it does still show the increased attenuation & noise levels etc.
Title: Re: Help interpreting Hlog graphs
Post by: Bald_Eagle1 on April 12, 2012, 05:46:33 PM
Separate graphs for the montage in the previous message are attached
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on April 12, 2012, 06:46:08 PM
Quote from: asbokid on April 12, 2012, 05:31:23 PM
Quote from: les-70 on April 12, 2012, 03:42:04 PM
I also suspect that you have a bridged tap somewhere of about 30m length (the dip around tone 350), the impact looks very small .

That attenuation 'feature' is probably due to frequency-dependent reflection losses from an impedance mismatch.

At a guess, the cause is a poor splice, perhaps a change in cable parameters, rather than a bridge tap.

cheers, a

  You may well be correct on this.  I gather it depends the detail of the effective inductance and capacitance that can occur at mismatch.  I have yet find an example of this in an Hlog plot in any text, the predominance of bridged tap examples was leading me that way.  An engineer and or a TDR seems the way to tell.
Title: Re: Help interpreting Hlog graphs
Post by: Bald_Eagle1 on June 10, 2012, 09:33:06 PM
@les-70,

I believe you have an Annexe M connection (increased US tones).

I have been messing about with the ADSL graphing scripts to use different colours for US & DS.

I currently determine which tones to use based on the "Mode" as reported via "adslctl info --stats"

e.g.
Mode:                   ADSL2+
Mode:                   G.DMT

Could you confirm exactly what is reported for Mode: for your Annexe M connection as I need to allow for it in the script, otherwise it will incorrectly plot like the attachment.

Cheers,

Paul.
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 11, 2012, 07:15:52 AM
  No problem, I have got used to the wrong presentation in display programmes but it would be nice to see it done correctly.    I would also happy to test anything.
 
     Good luck
   
   # adslctl info --stats
adslctl: ADSL driver and PHY status
Status: ShowtimeRetrain Reason: 0
Channel: FAST, Upstream rate = 1747 Kbps, Downstream rate = 17555 Kbps
Link Power State: L0
Mode:                   ADSL2+ AnnexM EU-56
Channel:                Fast
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):       4.8             6.5
Attn(dB):       25.5            8.4
Pwr(dBm):       6.5             13.3
Max(Kbps):      20476           1780
Rate (Kbps):    17555           1747
Title: Re: Help interpreting Hlog graphs
Post by: Bald_Eagle1 on June 11, 2012, 09:42:51 AM
Does this look more like it should?

Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 11, 2012, 11:46:02 AM
 It certainly does.  It will stop people being puzzled when annex m graphs are posted.

   
Title: Re: Help interpreting Hlog graphs
Post by: Bald_Eagle1 on June 11, 2012, 12:08:57 PM
I have emailed the updated ADSLGRAPH.BAT script to snadge for him to add to the download packages via his link(s).

In the meantime, I have attached a version here for you to try.

It would be good to see a full portrait montage of your current stats posted as an attachment (as a comparison with April's partial data).

 
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 11, 2012, 12:58:33 PM
Thanks for that, it worked just fine.  One the montages is attached.  Not a good day for my line as it seems to be more noisy than usual.
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on June 11, 2012, 01:07:23 PM
Quote from: les-70 on June 11, 2012, 12:58:33 PM
Thanks for that, it worked just fine.  One the montages is attached.  Not a good day for my line as it seems to be more noisy than usual.

Which modem is this? 

It looks as if there's something wrong with its Reed Solomon counters. They all record zero (0) errors.  Not realistic from five hours uptime and such a low SNR.

cheers, a
Title: Re: Help interpreting Hlog graphs
Post by: c6em on June 11, 2012, 01:10:50 PM

D the interleaver depth is set to 1 both up and down on his line - that's fast path
so there is no error correction routines on the line so no FEC's
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on June 11, 2012, 01:51:13 PM
Quote from: c6em on June 11, 2012, 01:10:50 PM

D the interleaver depth is set to 1 both up and down on his line - that's fast path
so there is no error correction routines on the line so no FEC's

EDIT: 

You're right - les70 does seem to have FEC disabled - you set me thinking about this though..

So far as I know, Forward Error Correction is independent of the interleaving depth. Reed-Solomon-FEC of the frame payload can still be used with Fast Path. Interleaving simply spreads the codewords across several frames to relieve the load on the RS decoder. But those interleaved codewords need not actually have any redundancy bytes added for forward error correction.

So just as Fast Path can use FEC, there can also be an interleaved latency path with no FEC.  The Forward Error Correction function and the latency path are configured independently. [1] [2]

It seems that some modems maintain separate FEC counters for Fast Path and for interleaved latency paths, e.g see this DSL modem from US Robotics which has counters specifically for Fast Path FEC Correction. [3]

Back in December, Kitz contributor JustAnother, went to a lot of trouble identifying all of the cryptic field names reported by the xdslcmd tool. [4]  JustAnother found a Comtrend manual hosted by Andrews & Arnold which lists the following: [5]

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F8470062%2F1024%2Fsnadge-stats%2Fxdslcmd-fields.png&hash=ee2e4ad6f5156de589f0c2f3a29ad93902454ae9) (http://picturepush.com/public/8470062)

Looking back at les70's stats, his modem lists the interleaving depth as 0 (zero) and the number of RS Codeword check bytes as 0 (zero). So unless that is wrong, it does look like RS-FEC is disabled altogether.

By contrast, this from my modem:

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F8470682%2Fimg%2Fsnadge-stats%2Ftelnet-screenshot.png&hash=b8a32c21271c4414723211ae4b4994b5dd4a06f2) (http://picturepush.com/public/8470682)

According to [2], in my case, the RS decoder takes M data frames, each of B octets (bytes). M*B is the size of the FEC data frame = (2*123) = 246 octets. That becomes the size of the Reed-Solomon codeword.  The number of redundant check bytes in the RS codeword is given by R, which in this case is 6.  So this FEC configuration (n,k) = RS(246,240).  Since RS can correct (n-k)/2 symbols in error per codeword, if a symbol is taken to be a octet, this means that up to 3 octets per 246 octet codeword can be corrected by the RS decoder.  However, thanks to the spreading from that huge interleaving depth D=64, the decoder could still correct a codeword where many more than 3 octets are in error.
 
Does that sound about right?!

cheers, a

[1] https://eeweb01.ee.kth.se/upload/publications/reports/2008/XR-EE-KT_2008_003.pdf  (see 1.4.2)
[2] http://huaweihg612hacking.files.wordpress.com/2012/06/80107515-g992-3-minusannexc-2009-04-final.pdf (see 7.7.1.4)
[3] http://www.usr.com/support/9111/9111-ug/adsl-2.htm
[4] http://forum.kitz.co.uk/index.php/topic,10289.0.html
[5] http://wiki.aaisp.org.uk/images/d/dd/UM_AR-5382u_A1.0.pdf
Title: Re: Help interpreting Hlog graphs
Post by: c6em on June 11, 2012, 07:24:57 PM

I'm afraid your beyond my technical competance/level of understanding with this.
I've never really bottomed out the interleaving depth and the why's etc is it set at a particular level.

As you say there seems no reason why interleaving and FEC's need to go hand it hand. I just imagined that BT/DSLAM designers had decided that they did as a matter of design policy.  I do recall hearing that when ADSL was first being designed that interleaved was the sole option.... it was only later that the concept of fast path was added into the specification.
(Given the number of gamers going hypobolic on ISP forums about demanding interleaving be set off  - only for the DLM to promptly re-apply it; I'll bet they wished they never thought of fast path.)

I've always run at D=64 downsteam both on ADSLmax and now ADSL2+ (sync 13000, target 3.0 dB, attn 36)
Once I recall when I had increased target margins due to a fault (when on ADSLmax) and was on a much reduced sync, D was set lower at 32.

Curiously my other figures are different to yours though we have the same interleaving depth
My M= 1
B= 190
R=14

I suspect the reality is that its so complex that understanding it is beyond the capability of those without a background in the field of data communication and telemetry.
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on June 11, 2012, 08:09:09 PM
Quote from: c6em on June 11, 2012, 07:24:57 PM
As you say there seems no reason why interleaving and FEC's need to go hand it hand. I just imagined that BT/DSLAM designers had decided that they did as a matter of design policy.  I do recall hearing that when ADSL was first being designed that interleaved was the sole option.... it was only later that the concept of fast path was added into the specification.

(Given the number of gamers going hypobolic on ISP forums about demanding interleaving be set off  - only for the DLM to promptly re-apply it; I'll bet they wished they never thought of fast path.)

I've always run at D=64 downsteam both on ADSLmax and now ADSL2+ (sync 13000, target 3.0 dB, attn 36)
Once I recall when I had increased target margins due to a fault (when on ADSLmax) and was on a much reduced sync, D was set lower at 32.

Curiously my other figures are different to yours though we have the same interleaving depth
My M= 1
B= 190
R=14

If that maths is correct then your RS decoder configuration has a codeword length of M*B = 190 octets, and with redundancy octets R=14,  the FEC configuration is RS(190,176), providing 7 octets of error correction per 190-octet codeword, but at an overhead cost of 14 octets (or 7%) per codeword.   Quite a heavy overhead. But that's ignoring the error correction gains (and latency overheads) from the interleaving.
 
Quote
I suspect the reality is that its so complex that understanding it is beyond the capability of those without a background in the field of data communication and telemetry.

Sure. It doesn't help that corporations like Broadcom are so secretive. And as Snadge has noticed, they're getting worse, refusing to even document their new processors. Great shame given that Broadcom relies 100% on the open source licensing of MIPS Linux for all its CPE and DSLAM platforms.  It's only thanks to the likes of Comtrend that we know what the single letter fields (M, B R, etc.) reported by Broadcom's xdslcmd tool actually mean in practice.

cheers, a
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 11, 2012, 08:26:17 PM
Interesting but I can't add anything useful.  The router is a DG834v4 with DGteam and the DSLAM is talktalk/ex tiscali  LLU.  The error rate in the mornings sample is about typical for the SNR.  The connection only resyncs if the SNR goes below about 0.5 but with a 4.0db sync it rarely goes below 2.0. I had interleaving on for a period in the past.  Errors were then all corrected but pings were longer, fast path seems a bit more responsive.
Title: Enabling Annex M in Broadcom chipset devices
Post by: asbokid on June 19, 2012, 02:12:46 AM
Quote from: asbokid on April 11, 2012, 08:06:40 PM
Quote from: les-70 on April 11, 2012, 06:32:54 PM

(By the way without annex m an HG612 did really well on my line but it does not seem to support Annex m...)



The HG612 should support Annex M, after all it's only a question of different bin allocations. Maybe Annex M needs enabling first through the kernel driver using some parameter of xdslcmd.

Hi.. I just got round to looking at this..

Enabling Annex M on the Huawei HG612 is painless enough..

Presumably it is a similar procedure for other Broadcom chipset devices.

Shown below, Annex M is disabled by default:

Code: [Select]
# xdslcmd profile --show

Modulations:
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled

The field of interest below is adsl2Param.  In the HG612 the field is set to 0x0 by default:

Code: [Select]
# xdslcmd info --cfg   
xdslcmd: ADSL driver and PHY status
...
adslTrainingMarginQ4: -1
adslShowtimeMarginQ4: -1
adslLOMTimeThldSec: -1
adslDemodCapMask: 0010447a
adslDemodCapValue: 0010447a
adsl2Param: 00000000
adslPwmSyncClockFreq: 0
adslHsModeSwitchTime: 0
adslDemodCap2Mask: 00540200
adslDemodCap2Value: 00540200
vdslParam: 007f00ff
vdslParam1: 00000000
xdslAuxFeaturesMask: 00000003
xdslAuxFeaturesValue: 00000003
vdslCfgFlagsMask: 00000004
vdslCfgFlagsValue: 00000004

We can check the DSL standards supported by the modem as follows:

Code: [Select]
# xdslcmd --help
Usage: xdslcmd start ... [--mod <a|d|l|t|2|p|e|m|v>] ...
...

Where:
(Some DSL standards are mutually exclusive)

The xdslcmd start --mod subcommand is used to enable Annex M or any of the other standards listed above.

The following command will enable g.dmt, adsl lite, t1.413, adsl2, adsl2plus, annex m, vdsl2:

Code: [Select]
# xdslcmd start --mod dlt2pmv
xdslCtl_GetVersion success

We can check that the command has been invoked correctly:

Code: [Select]
# xdslcmd profile --show
xdslcmd: ADSL driver and PHY status
...
Modulations:
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Disabled
ADSL2+ Enabled
AnnexM Enabled
VDSL2 Enabled

Annex M is now listed as Enabled.

We can also verify the new bitmask of the adsl2Param field. Show below, it has changed to 2. This confirms that AnnexM is now an activated configuration option.

Code: [Select]
# xdslcmd info --cfg

adslTrainingMarginQ4: -1
adslShowtimeMarginQ4: -1
adslLOMTimeThldSec: -1
adslDemodCapMask: 0010447a
adslDemodCapValue: 0010447a
adsl2Param: 00000002
adslPwmSyncClockFreq: 0
adslHsModeSwitchTime: 0
adslDemodCap2Mask: 00540200
adslDemodCap2Value: 00540200
vdslParam: 007f00ff
vdslParam1: 00000000
xdslAuxFeaturesMask: 00000003
xdslAuxFeaturesValue: 00000003
vdslCfgFlagsMask: 00000004
vdslCfgFlagsValue: 00000004

cheers, a
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 19, 2012, 10:39:41 AM
  Many thanks for looking, it looks promising but I can't get a sync. I made the advised changes and checked annex m was enabled -- all looked ready to go.  I set the HG612 ATM to 0 38 PPP0A VCMUX, I left the service type UBR without PCR. No change on PTM. In WAN, selected the atm and gave name/password. Just tries to sync then fails. I will try again this evening!

 I notice the setting is lost on reboot.

  p.s.  Having successfully add serial port pins to an ECI and unlocking it, I thought I  would try the port on an HG612.  I can only get odd garbage characters off the HG612. If there anything subtle about the port settings or may I just have a bad solder job?
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on June 19, 2012, 04:46:18 PM
Quote from: les-70 on June 19, 2012, 10:39:41 AM
  Many thanks for looking, it looks promising but I can't get a sync. I made the advised changes and checked annex m was enabled -- all looked ready to go.  I set the HG612 ATM to 0 38 PPP0A VCMUX, I left the service type UBR without PCR. No change on PTM. In WAN, selected the atm and gave name/password. Just tries to sync then fails. I will try again this evening!  I notice the setting is lost on reboot.

That's annoying.  ???  If you've made any changes through the web GUI, that will probably reset the DSL configuration options and disable Annex M again.

Quote
p.s.  Having successfully add serial port pins to an ECI and unlocking it, I thought I  would try the port on an HG612.  I can only get odd garbage characters off the HG612. If there anything subtle about the port settings or may I just have a bad solder job?

Can't think of any reason for that, if you are sure that the soldering and cable is sound, and the terminal software and serial port parameters are configured okay (115200 8n1).  I've re-populated UART/JTAG pins on four HG612s so far. All work okay. The ground thru-hole was a pain on a couple of them, not being drilled out fully.  But other than that there were no problems. Maybe check the pin continuity, especially GND.

cheers, a
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 19, 2012, 06:36:58 PM
 Still no luck getting a sync with Annex m.  I have been checking with "xdslcmd profile --show" that all is ready before each try so GUI edits should not have been a problem. I looked over your "wordpress" adsl example with the HG612. The only difference I can see is that you had the dialing method as manual when I had auto.  I could try that later but I don't think it relevant.

  p.s. I will try the HG612 again.  I did check pins voltages and had 3.3 on RX and 0.0 TX w.r.t. GND. I will resolder the TX as I think the 3.3 suggests that the other two are OK
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on June 19, 2012, 07:22:46 PM
Quote from: les-70 on June 19, 2012, 06:36:58 PM
Still no luck getting a sync with Annex m.  I have been checking with "xdslcmd profile --show" that all is ready before each try so GUI edits should not have been a problem. I looked over your "wordpress" adsl example with the HG612. The only difference I can see is that you had the dialing method as manual when I had auto.  I could try that later but I don't think it relevant.

This Huawei is configured for "Auto" dialling mode, too.

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww5.picturepush.com%2Fphoto%2Fa%2F8531873%2F480%2FPicture-Box%2Fhuweisnapshot.png&hash=4473fb0d8c07fcc3fcbc3c5b27b784730a4c3194) (http://picturepush.com/public/8531873)

TalkTalk (Business) will apparently supply Annex M now [1] so there might be a chance to try it on this line. Not holding out much hope. According to TDR, the exchange is around 1600 metres, perhaps too far to get much gain from it.

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F8531841%2F480%2FPicture-Box%2Ftdrtraceabwhe.jpg&hash=2ce1a4cc00a8ba18763168a9b103d183845fb6e5) (http://picturepush.com/public/8531841)

Quote
p.s. I will try the HG612 again.  I did check pins voltages and had 3.3 on RX and 0.0 TX w.r.t. GND. I will resolder the TX as I think the 3.3 suggests that the other two are OK

Are you using the same (known good) serial cable that you used with the ECI? Maybe see what is shown on a scope trace. At boot, the Huawei dumps its log over the serial port, so that should always be visible.

cheers, a

[1] http://www.talktalkbusiness.co.uk/about-us/news/video-news/partner-bb--annex-m/
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 19, 2012, 08:00:08 PM
  I tried re-soldering and there is no difference, just an erratic character echo with odd bad characters. Once garbage appeared on reboot but that is not consistent in appearing .  I wonder over my clearing out well with a 1mm drill, maybe I removed more than I intended. I assume that I only need the tx/rx/gnd row of header pins or is lack of hardware control my problem?   Later in the week or at the weekend I will try very carefully from scratch on a 2nd HG612 that I got the other week.  They are occasionally very cheap on ebay.

 I will be interested in how you get on with TalkTalk.  I am with them on annex m as an ex Nildram customer and they say they don't do it for their own customers.  They do provide it for resellers and their DSLAMs, like most, support it.   Judging by your stats I would guess that you would loose 1M down and get about 1.8 to 1.9 in total up.  The up speed is very router dependent.

 Good to see your TDR, like me you look to have quite a bit of cable junction and cable impedance changes in the first 800m.  I am going to look at traces on neighbours connections before pronouncing on mine.

   Many thanks for the help
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 20, 2012, 05:12:09 PM
No problems getting the  UART/JTAG pins to work on the second HG612  :).  As you warned the GND needed drilling, but I avoided it on the other pins. After all the trouble playing with the last one, this time it seemed too easy!!   I tried Annex M again but still no luck - just long sets of green led flashes trying to sync. 
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on June 20, 2012, 11:14:57 PM
Quote from: les-70 on June 19, 2012, 08:00:08 PM
  I tried re-soldering and there is no difference, just an erratic character echo with odd bad characters. Once garbage appeared on reboot but that is not consistent in appearing.  I wonder over my clearing out well with a 1mm drill, maybe I removed more than I intended. I assume that I only need the tx/rx/gnd row of header pins or is lack of hardware control my problem?

No worries about hardware control. Maybe pull off a ground somewhere else if the track has gotten broken?

I just re-populated the UART and JTAG pins on an ECI board.  Heck, that took a long while! God knows what solder they used because it needed a huge amount of heat. In the end with a hot air gun. Hopefully it hasn't fried anything.

Quote
Later in the week or at the weekend I will try very carefully from scratch on a 2nd HG612 that I got the other week.  They are occasionally very cheap on ebay.

 I will be interested in how you get on with TalkTalk.  I am with them on Annex M as an ex Nildram customer and they say they don't do it for their own customers.  They do provide it for resellers and their DSLAMs, like most, support it.   

Aha! Thank you! So it's not clear cut that Annex M is even available.  And the TalkTalk advert sounded so promising. When I asked them they promised that Sales would call back with a price. ???

Quote
Judging by your stats I would guess that you would lose 1M down and get about 1.8 to 1.9 in total up.  The up speed is very router dependent. Good to see your TDR, like me you look to have quite a bit of cable junction and cable impedance changes in the first 800m.  I am going to look at traces on neighbours connections before pronouncing on mine.

This isn't the best line. Seems to work okay though. TDR has revealed the distances to all the main 'features', but no clues yet where the cabinet can be found.  Must be out there somewhere.  Perhaps an advert in the newsagent window...   "MISSING!  SMALL GREEN PCP.  OLD BUT MUCH LOVED.  ANSWERS TO TDR PINGS.  ANY INFO PLEASE CALL 100"


cheers, a
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 21, 2012, 04:08:14 PM
 Thanks for the helpful advice.  I am afraid that to avoid it bugging me I removed the header pins from the first HG612 and put a "uart/jtag output RIP" notice on the back of it.  With all working on the second I am content with that. 

  Good luck with TalkTalk and please do advise of the outcome.

 You may well have seen my TDR traces ( http://forum.kitz.co.uk/index.php/topic,11309.0.html ).  I was amazed but comforted to find my neighbours traces were just the same with only distance changes.   I wonder on whether one of the TDR features shown there gives a possible clue to my Hlog dips.
Title: Re: Help interpreting Hlog graphs
Post by: kitz on June 21, 2012, 10:00:04 PM
At the risk of sounding stupid, because I came in late on this.... and since asbokid knows his stuff, I kept out until now..

But can I just clarify what you meant about the hump in hlog graph?
If you mean the curves that are showing before and after tone 255ish..  this can be indicative of 'normal' crosstalk at the MSAN.

For eg the MSAN could have lots of lines on adsl 1 (using < tone 255) some of those may be very long lines and therefore not using the full tones available for adsl1.  As you reach tones for adsl2+ (>255) then theres not as many users using these frequencies so you see a slight increase in performance again.
Title: Re: Help interpreting Hlog graphs
Post by: les-70 on June 22, 2012, 07:40:29 AM
Thanks for the thought.  Your correct that there is most likely a change in cross talk at the adsl junction adsl2+.  That is probably what is seen in QLN attached (I am surprised so many look to be left on adsl?).  I don't however think the Hlog should be influenced visually by noise, including cross talk, unless the SNR at those frequencies is very low - it is not. see attached SNR.  The dips occurred suddenly when Openreach were doing work in two places. One a DSLAM move in the exchange. i.e. moving the LLU DSLAM to different part of the building.  The other work was along my route to the CAB.  The DSLAM work was associated with no broadband overnight .  The street work came with no phone or broadband for a short period.  The dips also came with a permanent loss of about 2Mb/sec in sync - not a disaster but an annoyance. Possible dip places are marked in the HLOG plot which come from the TDR post noted in my previous reply.

   I am not expecting to get anything changed but to be prepared to try should another issue arise.  They seem to like disconnecting me at the CAB -- 3 times in the last 4 years, so another issue would not surprise me.

   
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on July 05, 2012, 12:28:59 AM
Quote from: les-70 on June 21, 2012, 04:08:14 PM
  Good luck with TalkTalk and please do advise of the outcome.

Quote from: TalkTalk Business Customer Services
Thank you for contacting the Talk Talk Business Customer Services team.

I can confirm that Talk Talk Business do not supply Annex M.

Kind regards,
TalkTalk Business Customer Services

 :(

cheers, a
Title: Re: Help interpreting Hlog graphs
Post by: asbokid on August 17, 2012, 12:36:08 AM
Just jibbering here really,  but it struck me that perhaps the HG612 isn't sync'ing in ADSL2+ Annex M mode because of an incompatible upstream transmit spectral mask.

Suitable PSD masks for the BT and Kingston networks are listed in what is called the Access Network Frequency Plan (ANFP), a Plan laid down by Ofcom.  Maybe the Huawei, by default, is using a mask that is incompatible with that Plan? And consequently the DSLAM is refusing to synchronise with the CPE modem in ADSL2+ Annex M mode?

The Ofcom Guidelines for the ANFP Plan are found at [1]. Similar documentation on Annex M PSD masks, in respect of the Frequency Plan for the Australian telephone network, can be found at [2]

The DSLAM, now homed under Our Wayne's bed, could be coerced into accepting an Annex M connection. And hopefully with the best sync speed possible, given the local loop length of just 3 metres!  At [3] is the CLI documentation for tweaking the Huawei MA5616 mini-DSLAM for different DSL connection modes, including ADSL2+ Annex M.

Whether the PSD Masks used by the HG612 (and similar Broadcom-chipset CPE) can actually be modified from userspace via a telnet shell doesn't seem to be publicly documented.

The ANFP Guidelines for the UK list five different upstream transmit PSD masks for ADSL2+ Annex M.   The Ozzie Plan lists a total of nine masks.  The mask is chosen according to the subscriber's loop length.    The loop length is presumably determined from measurements observed at DSL initialisation, rather than from any network infrastructure records of physical loop length.  As shown in the diagram below, the five ADSL2+ Annex M PSD masks used in the UK are labelled ushort, eshort, short, medium and long.

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww4.picturepush.com%2Fphoto%2Fa%2F8991852%2F480%2FADSL2%252B-Annex-M%2Fannexm-psd-masks.png&hash=16aed549cdefd0f8b58e7e2e1a31d2efa68a75ea) (http://picturepush.com/public/8991852)

The equations for calculating a PSD mask are based on just a handful of constants (for frequency cut-off points, etc.)   Those constants are possibly all that is stored in the CPE, and from which the upstream transmit mask is constructed.

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww2.picturepush.com%2Fphoto%2Fa%2F8991855%2F480%2FADSL2%252B-Annex-M%2Fatu-r-upstream-transmit-spectral-mask.png&hash=e388d6cd979f247d2bffa366275cbe0281fe3216) (http://picturepush.com/public/8991855)

(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww3.picturepush.com%2Fphoto%2Fa%2F8991856%2F480%2FADSL2%252B-Annex-M%2Finband-peak-psd-and-frequencies-f1-and-f2.png&hash=b94b6980a523ffe0adcd0c3b7572153066747e62) (http://picturepush.com/public/8991856)

The documents above all reference the ITU-T G.992.3 Recommendations found here [4]

Maybe something interesting there for others?!

cheers, a

[1] http://www.niccstandards.org.uk/files/current/ND1405V3.1.2.pdf?type=pdf
[2] http://www.commsalliance.com.au/..ADSL_Annex_M_NonDeploymentClassSystems_21Feb06.pdf (http://www.commsalliance.com.au/__data/assets/pdf_file/0015/1743/R59_010_Agile_Communications_submission_proposing_nine_ADSL_Annex_M_NonDeploymentClassSystems_21Feb06.pdf)
[3] http://docs.google.com/open?id=0B6wW18mYsk... (http://docs.google.com/open?id=0B6wW18mYskvBa0Z3T0pOb1R0NHM)
[4] http://www.itu.int/rec/T-REC-G.992.3/en