Print

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

[asbokid]

RFI from ham radio should only be present when the radio enthusiast "keys up".  However this is shortwave, where propagation can be thousands of miles. And the lowlands of north Essex are well known for their good radio reception, wanted or otherwise!  When we lived there, it was commonplace to receive UHF TV transmissions from the Netherlands!   Just the luck of the draw, or not!

cheers, a

[burakkucat]

burakkucat, a copy of the HG612_stats sources would be great thanks.

Please let me know, by PM, of an e-mail address to which I may dispatch the above.

One last question, the spike which is seen on the Hlog graph, is this something I should raise as a fault or just live with?

It would irk me, if I saw it for my line and I would investigate all possible causes for its appearance. Once I could prove the cause was an infrastructure defect, then I would report it and keep discrete pressure applied until the fault was rectified.

I wonder if Black Sheep has seen such a graphical abnormality before, in his professional capacity?    Let's wait for his input . . .

[burakkucat]

That's an interesting and unusual spike in the HLog (attenuation) graph.  It corresponds roughly to DMT#180.   It's actually a trough followed by a peak (or vice versa) which probably says more about its cause.

You observation of a trough & peak fits in with my comment about 'ringing', albeit highly selective to a precise frequency.

I wonder if the frequency of that spike can be transformed into a distance? And then I wonder if it would agree with the ~60 metres noted on the TDR trace, pre-replacement of the service feed? 

[NewtronStar]

RFI from ham radio should only be present when the radio enthusiast "keys up".

it's a funny subject this now Ham radio users are being subject to interference by HomePlugs
and I can confirm this after two days trying to find the source 

http://www.pcpro.co.uk/realworld/350648/does-powerline-networking-nuke-radio-hams

[Black Sheep]

As most of us know, a 'peak' on the display screen when using a Time-Domain Reflectometer (TDR), either as a function of a multi-meter (such as a JDSU), or as a stand-alone tester, is generally indicative of high resistance. The higher the peak, the greater the resistance with an 'Open circuit' practically showing the 'peak' touching the top of the screen.

However, it can also show a 'Poundage change' between jointed cables. IE: The original UG feed to the house may well have been 0.4mm diameter wire, jointed to a 0.9mm diameter OH cable at the pole ??

Also, just an observation, but if I had my mate (an excellent engineer) stood at your premises, and asked him to estimate the distance to the pole, I can tell you now he'd be 30-40mtrs wide of the mark. That's why we have pedometers. What I'm trying to say, is judging distances is pretty hard, and the new drop-wire could well be 60mtrs long ?? Like I say, only an observation.

What is interesting is the comment about a 'trough' followed by a 'peak', this when presented on a TDR screen is more often than not a wet-joint. I've tried to find a picture to show this, but to no avail. . Did the engineers trace actually show this, or is this just derived from HLog data ??

 

[Crickers]

I do use homeplugs, have turned a couple of them off and attached a quick TestStats2. The other is in the garage and its too late to mess around tonight, will run some more stats with them powered off tomorrow afternoon.

Will also measure the length of the new drop cable that has been installed, the pole is just at the edge of my drive. I'm guessing no more than 25m, but I'll confirm tomorrow with a tape measure. This replaced an unknown length of UG cable as we could not determine the routing from pole to master socket, so this indeed could account for the 60m peak.

Stupidly I didn't really pay much attention to the engineers trace at the time, seem to recall a slight dip before the peak but can't be certain and even more annoying that another TDR trace was not completed after the new drop wire was installed.

Hopefully I'm better educated now so will be more observant in future 

Also now have the linux sources so will have a play tomorrow, thanks burakkucat.

[burakkucat]

I've had a quick look through my JDSU & Exfo documentation and, just like Black Sheep, I couldn't find the example for which I was looking! 

I have snipped two example graphs from an Exfo document (as this is for educational and research purposes, I do not expect the company to niggle over copyright) and they are attached, below.

Finally I have expanded the Hlog graph obtained from Crickers line and I think we will all agree that the trace drops sharply before rising sharply. So Asbokid was quite correct in describing it as a trough followed by a peak. 

Also now have the linux sources so will have a play tomorrow, thanks burakkucat.

You are welcome. One quick comment. I have provided you with the means to harvest ongoing statistics, once per minute. To produce pretty graphs from the logged data, you will need to use one of Bald_Eagle1's scripts. I last used that harvesting code back in December (2012) when I was using a Raspberry Pi to monitor my line. At that time I was plagued by RFI hitting my US frequencies and I put it down to being in the 'flashing lights' season. I distinctly remember sending a weeks worth of logged data to The Eagle's Nest but the promised analysis has never appeared! 

[Crickers]

Here's a Hlog graph from before the UG cable was replaced.

[burakkucat]

Here's a Hlog graph from before the UG cable was replaced.

And we see a peak followed by a trough, then some 'fade-out' 'ringing'. I'm not sure what to make of that trace.

[Bald_Eagle1]

I distinctly remember sending a weeks worth of logged data to The Eagle's Nest but the promised analysis has never appeared! 

Apologies for that. It seems to have dropped completely off the radar.

I have just run your 7 day ADSL modem_stats.log through my graphing program, but as the fields are not in the same order as those used for VDSL2 connections, the output is completely incorrect (see attached).

Either 2 separate programs would be required, or the program would need to determine the DSL mode & format the output accordingly to allow the one program to work for different DSL modes.

Also, the Windows version of the VDSL2 ongoing stats harvesting program calculates 'delta' values at harvesting time, storing the data in the modem_stats.log

I believe your Linux version doesn't do that at this time.
That element of the code MAY be more or less compatible across both platforms, so maybe it could be reasonably easily added to the Linux version's code?

I'd be happy to share the 'C' code for the Windows versions if that would assist anyone for conversion to Linux.
It does use some system calls, other programs & specially written utilites though.

[burakkucat]

Apologies for that. It seems to have dropped completely off the radar.

I appreciate that Mrs Eagle was giving you a hard time over the refurbishments of The Eagle's Nest (which was supposed to have been finished by Christmas 2011 and was still not going to be finished by Christmas 2012), so I just kept quiet. 

I have just run your 7 day ADSL modem_stats.log through my graphing program, but as the fields are not in the same order as those used for VDSL2 connections, the output is completely incorrect (see attached).

   Hmm . . . If only you could re-base your fork of the utility on the latest version (0.20, from last December), then there should not be any discrepancy.

Either 2 separate programs would be required, or the program would need to determine the DSL mode & format the output accordingly to allow the one program to work for different DSL modes.

I will remind you that I had to spend many hours putting conditional code into the harvesting utility so that the correct data was recorded for G.Dmt, ADSL2, ADSL2+ and VDSL2 services. 

Also, the Windows version of the VDSL2 ongoing stats harvesting program calculates 'delta' values at harvesting time, storing the data in the modem_stats.log

I believe your Linux version doesn't do that at this time.

Correct.    I recall recommending the use of a separate structure, 'HG612_deltas', for their storage. That should appear in version 0.21, when I get 'a round tuit'. 

I'd be happy to share the 'C' code for the Windows versions if that would assist anyone for conversion to Linux.

I have been 'threatened' with that, before, by you and I am still awaiting for its materialisation.

It does use some system calls, other programs & specially written utilites though.

You should be familiar with the --

#ifdef          __MINGW32__
// Do BGW style thingies.
#else
// Do sophisticated, quality *x code.
#endif

-- as shown many, many months ago by Asbokid. Hence all your 'doze specific code can be eliminated by the C-preprocessor when the source is compiled for -- er -- proper systems! 

[kitz]

 

[Crickers]

Now, now, children play nicely 

Have measured drop cable length from pole to master socket. I make it 24m, measured across the ground and then followed along walls etc. Think I'm within 2m of the actual length, so not even half the 60m distance seen on the TDR.

Also powered down all homeplugs at 10:30am and re-run TestStats2 (attached).

Had resync at 4am this morning, part of the DLM I guess?

[Black Sheep]

Wrong side of the bed this morning, B*Cat ?? 

[asbokid]

Not sure where the diagram below came from, but the troughs and peaks, and the fault type they signify, are all captured in the time domain. 

(Time runs along the x axis, while magnitude is up the y axis)

Whereas the spike in Crickers' Hlog graph is captured in the (discrete) frequency domain.

(Discrete tone frequencies along the x axis and magnitude up the y axis).

Also below are screenshots from TDR devices showing a fault on the line.  A branch rubbing on the drop-wire caused a short just before the pole.   Credit where due, Openreach engineers sorted it out very efficiently:



cheers, a