Print

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

[Bald_Eagle1]

  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:-



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  .
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.

[les-70]

  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

[c6em]

...and another one
ADSL2+ line, 2.5Km long, 36dB overall attenuation,13279 sync @ 3dB target SNRmargin




[attachment deleted by admin]

[burakkucat]

And three from when I was experimenting, last February. 

[attachment deleted by admin]

[Bald_Eagle1]

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:-




My Hlog graph looks like this:-




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

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?

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  .

[les-70]

  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.

[les-70]

  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. )

[asbokid]

  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]

(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    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

[asbokid]

  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 

cheers, a

EDIT: corrected ylabel on QLN

[les-70]

  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

[c6em]

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)

[asbokid]

  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.

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! 

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?

[les-70]

  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. 

[asbokid]

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

[Bald_Eagle1]

  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.