Print

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

[burakkucat]

Some more data. Freshly obtained after power on and sync'd with the MSAN, this time in ADSL2+ mode.

[les-70]

  Thanks Burakkucat.  That is different again at 15-16 tones per 2pi.

 I am now focusing on why things are different every resync. I have been playing with the bcmdsldiagsl tool to see if that might be able to force some more sensible Hlin.  No luck though, I don't get back any response from most the tests others than various error messages and sync being lost.  The utility messages indicate a failure to resync and to finally return to normal I need to reboot the modem/router.   I wondered whether DELT mode might help but as I just get the failure messages. Maybe my annex m is the problem, it seems a nuisance when your messing around!   Don't expect any rapid progress now, it seems hard to track down any clues regarding the inconsistency.  In the mean time I will be interested to hear what others can get out of the tests in the bcmdsldiagsl tool.

[les-70]

  As an extra comment, based on above, I think the line length should be about

            47/n km where n is the number of tones per 2pi.

 i.e. 47 tones per 2pi or cycle in the real and imaginary parts --  corresponds to about 1000m line length.   Less tones per 2pi is longer and more shorter.  Things like 4 and 5 tones per 2pi give crazy lengths of about 10km.    This also, as it should, matches the calculation of a bridged tap.  Thus a 50m bridged tap has a total up and back length of 100m and should show a first dip at about 235 tones (pi) about 1Mhz and subsequent dips every 470 tones(2pi) or about 2Mhz apart  The same as the 2pi length corresponding to 470 tones. see http://documents.exfo.com/appnotes/anote168-ang.pdf for an example.

   It seems that not only are we getting varying results but ones giving much too short a length.   If the Huawei patent were correct the lengths would be about 60 times smaller due the 180/pi numerical difference.   From the ridiculous to the sublime.

[asbokid]

The following is taken from a French broadband forum (clubnews.fr) [1]   It is by the Swiss poster Divico.

I think we begin to see a little clearer about the forms "hedgehog" or "cardioid"

• We discover that in principle the modem's Hlin table presents the transfer function with a phase "reduced" to get an extreme phase shift of 3 or 4 pi radians.   In my opinion, this approach clarifies this Hlin representation in complex cartesian graphs and permits rapid comparisons of very different long connections (attenuation).
  
  
• It should be noted that a twisted pair introduces a significant phase shift, which is further enhanced by the modem's own filtering. For example, for a cable pair of 0.4mm (50nF/km and 0.60mH/km), the extent of the phase shift in a line of 1 km at 1100 kHz (tone 255) is:
  
  2*pi*1100e3 Hz * sqrt(50e-9 F * 0,60e-3 H) = 38 radian/km
  
  
• To try to better understand the significance of the Hlog and Hlin representations, I tried to model a telephone pair associated with high-pass and low pass filters, representative of those of a modem, to obtain a solution that is as close as possible to a real Hlog curve.

Attenuation [dB] as a function of frequency [kHz]

Blue in the simulation (0.4mm pair of 2 km length), in red the weakening of a modem (Hlog)



Hlin in Cartesian representation of a function of frequency (real (Hlin) red and imag (Hin) in green)



Note that the curves pass in negative fifteen times each, this means that the final phase will be about 15 * 360 degrees (94 radians).

Phase according to the frequency



Representation of the phase from complex numbers being known as modulo 360 degrees (pi radians ±). The actual phase must obviously be reconstituted with an unfolding function (unwrapping).

Variations in the evolution of the phase versus frequency, which appears to be linear, can be identified by the inverse of the evolution of the group velocity (= group delay time), expressed in micro- second / km



Representation in a complex of Hlin (1 to 63 tones in green, blue 64-127 and 128 to 255 in red)



Representation in a complex plane of Hlin after reduction of the phase maintaining the value of the modulus


..
..
(For clarification):

F simply means Farad and Henry H.

The approximation phase = Omega * sqrt (L * C) is only valid for R smaller than (L * Omega), say above 60 kHz for a twisted pair.
L and C are coefficients per unit length expressed in units per kilometer, this must be taken to a line of any length.

The inverse of the group velocity (1/Vg) or group delay, which is expressed in micro-seconds/km, for example, is equal to:

1/Vg dbéta = (w) / dw * 1e6: Computation with Matlab function diff (), beta is imag (Hlin) unfolded expressed in radians (for a given length) or in radians / km and dw is 2 * pi * 4312.5 expressed in radians / second for a vector of ADSL tones (1104 Hz = 4312.5 kHz/256 channels)

Note:
- Omega or w = 2 * pi * f
- The prefix "d" means differential, of course
- Dbéta (w) = beta (n) - ​​beta (n-1), for a vector of ADSL tones

[1] http://forum.clubnews.fr/viewtopic.php?t=6085

[les-70]

Good find asbo.  I am however no further after reading all of the thread -- I wonder if I am missing something in the translation by google.   Maybe you can see more in it?

 They start off seeing all that we are seeing and note the very large rates of phase change don't match the more moderate phase changes that the line on its own should produce. They suggest the DSLAM/modem is introducing extra phase change --this indeed seems most likely -- it is hard to see what else could do it.  It is why I wondered whether the modem might have a test mode in which this did not happen and which the broadcom diagnostics utility might be able to invoke. 

  The bit that you post seems to be a calculation of what is expected.  I think the final plot is the phase change with the linear component removed. That removal does not seem to get them anywhere other than with a simple picture.  Within the whole thread there are references to correcting the hlin phase but as far as I can see they just remove the linear bit, which I think "removes the baby with the bath water" -- water that the modem/dslam has added.

  I think we need to understand exactly what phase compensation occurs when Hlin is measured, or perhaps stop that compensation if there is a test mode that does that.

[burakkucat]

This is a very interesting topic, to which I am unable to add any input . . . Apart from another data set, once again in ADSL2+ mode, which was collected promptly after a power-on of the HG612, following a few hours of disconnection.

(As an aside, it is clear to me that ADSL2+ mode does not perform well on my line. Tomorrow I shall revert to ADSL (G.Dmt) and continue my investigations. I need to adapt Bald_Eagle1's dynamic statistics collecting script, from its current format (for BillyGatesWare) to be able to use it on a superior OS.)

[asbokid]

Good find asbo.  I am however no further after reading all of the thread -- I wonder if I am missing something in the translation by google.   Maybe you can see more in it?

You're right. There's nothing new in that thread which you haven't already discovered. I was mainly interested in the spiral graphs  , and the overplotting of a theoretical Hlog curve using empirical parameters from the BT cable reference model.

They start off seeing all that we are seeing and note the very large rates of phase change don't match the more moderate phase changes that the line on its own should produce. They suggest the DSLAM/modem is introducing extra phase change --this indeed seems most likely -- it is hard to see what else could do it.  It is why I wondered whether the modem might have a test mode in which this did not happen and which the broadcom diagnostics utility might be able to invoke.

There doesn't seem to be an obviously relevant checkbox, but haven't studied it closely yet. The utility reports itself as a 'Lite' version.  Some of the functions and reporting of some line data is disabled, yet the dsldiagd daemon still appears to send that data.  Maybe tucked in there is what is needed?   What form would you expect the phase change data to take?  What might it look like?  Some sort of scaling factor?

EDIT: Have you looked at the Broadcom driver source code? [1]

cheers, a

[1] https://forum.openwrt.org/viewtopic.php?pid=120035#p120035

[les-70]

   Yes it was nice to see all the various graphs (including hedgehogs! good name)  plotted as well as the nice example of what it should look like.    To convert what we have to what we should get, all that is missing is single value for the rate of phase change per tone that the DSLAM/Modem is managing to add on each sync.  Since we expect a constant rate of phase change and already have one, but of the wrong rate, we just lack info on the constant which is added.  It puzzles me that on each resync the added constant seems itself to change a lot by up factors of 4. It might make sense if something was added that helped improve the tone separation, but again the factor of 4 changes don't seem rational.

   I have not looked at the source as it would doubtless be beyond me.  I will however try find time have look  it case it contains any comments that may help. 

    With the broadcom utility we would either need to find the added constant or get it to sync without adding anything.   As I mentioned I wondered over the DELT test mode.  That seemed to try to sync but fail to sync for me.

  Regards

 

[burakkucat]

Here is today's fresh data, Les. Please let me know if you would like me to continue collecting the same . . . otherwise I'll leave the HG612 constantly powered up, from now on.

[les-70]

  Thanks very much for the sequence of stats burakkcat.  I don't need any more now -- enough to confirm similar and hard to interpret responses from 3 different modems and lines now. 

[burakkucat]

Purrfect. Happy to have helped. 

[asbokid]

I think we need to understand exactly what phase compensation occurs when Hlin is measured, or perhaps stop that compensation if there is a test mode that does that.

    With the broadcom utility we would either need to find the added constant or get it to sync without adding anything.   As I mentioned I wondered over the DELT test mode.  That seemed to try to sync but fail to sync for me.

I just found this thread from googling (not a good omen!)

Did you find any more about the phase compensation, les-70?

cheers, a

[les-70]

  No, I am afraid that I have not made any progress.  I had a good go through the DG834G source code and the associated broadcom driver source by both just looking and various full searches but I missed anything helpful.  I also googled a bit more and like you was depressed to keep finding this thread!  I also tried some of the curious options is the BCMdiag utility, some lost sync, but even in these cases the Hlin had the same behaviour.

 You would think someone must know what use to put  Hlin and HlinS to or they would not always be produced!

[asbokid]

Ahh. Thanks for the update, Les-70.  Not sure what's left to try. Though, we do have a DSLAM to play with now. Our Wayne's mate Fingers Jenkins (the legendary locksmith of The Scrubs) managed to prise open a cab, and away he went.  Clever lad!  (Only joking! It was a Good Lucky Taobao find!)   Maybe peering down both ends of the local loop could unravel the hlin phase mystery!

cheers, a

[konrado5]

As I mentioned I wondered over the DELT test mode.  That seemed to try to sync but fail to sync for me.

I have working ADSL2+ diag mode. Perhaps my Hlin data contain useful phase changes.

Best regards
konrado5