Print

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

[Weaver]

I’m really sorry, I don’t have the data sets for the older ones. I just got the images alone from my "Photos" image library in which they were screen shots. I can of course send you the new data.

[burakkucat]

Ah, no, please don't bother with that. I just wanted to compare the style of plotting. As you will recall, when I was last using an ADSL2 based service my bit loading v sub-carrier plots did not show any pilot tone(s). (I'm not saying that they were not present . . .)

Puzzled. 

[Weaver]

Has anyone else ever seen a disease like this? (Which now seems to be quite possibly a modem disease, not anything to do with DSL lines.)


I wanted to draw a straight line between the two humps and show on it the variables discussed, to make a pretty picture. Especially if I can find a picture where such a straight line would be downwards sloping to the right. (Increasing x, decreasing y). However I don’t have a tool for that. And would get lost immediately amongst the thousands of iOS apps. I would need something that can draw on an existing bitmap, draw straight lines in various line styles, drop various symbols such as dots, blobs, crosses and draw text too. And with multiple undo too.


Pilot tone shows bitloading of 2 always.

[burakkucat]

I wanted to draw a straight line between the two humps and show on it the variables discussed, to make a pretty picture. Especially if I can find a picture where such a straight line would be downwards sloping to the right. (Increasing x, decreasing y). However I don’t have a tool for that. And would get lost immediately amongst the thousands of iOS apps. I would need something that can draw on an existing bitmap, draw straight lines in various line styles, drop various symbols such as dots, blobs, crosses and draw text too. And with multiple undo too.

Have a play with GraphSketch

Here's two that I prepared earlier.

Pilot tone shows bitloading of 2 always.

Crazy idea? "Normalise" the data by subtracting the bit loading of the pilot tone from the bit loadings of all the other sub-carriers and then work only with the data that is greater than zero.

[Weaver]

Another question: is the pilot tone always a single tone only? ie x-width == 1. Never x-width >= 2 ? I step sideways to get away from a suspected pilot tone.

[burakkucat]

Let x be the sub-carrier index (or tone) and y be the bit-loading at x . . .

for (x > 32; x < 120; x++) {
        if (y < 3)
                continue;

        process data;
}


Remember that a pilot tone is a defined frequency, not a 4.3125 kHz block of frequencies. The latter is what we are looking at on the X-axis.

[Weaver]

Ah, that’s a good point. But when it is modulated, then the modulation will cause a single frequency to spread into a band of frequencies of a width determined by the type and top frequency of the modulation, no? But I wasn’t thinking straight, indeed. Is it sometimes a real pure and simple pilot tone and sometimes an ordinary ‘bin’ instead, when carrying data? Did you say that VDSL2 is different or am I imagining things?


In my code as it is now, implementing algorithm one (of the two described above), I test y at 3 x values: x==40, x==60 or 62 and x==85. The x==60 thing is the approximate mid point, but there is a danger of hitting the pilot tone there, so if x < 4 (I see you have 3 there, so I should perhaps amend my code) then I assume I have hit a pilot tone and so I switch to sample y at x==62 instead. I hopped out of the way sideways by x+=2 because of nervousness about the width of the pilot tone but I was overly paranoid in this respect as you have told me, so x+=1 would have suffixed, but there’s no harm in x+=2 so I’ll leave it as is in case I have hit something other than a pilot tone, possible if the bitloadings are extremely low in a very very diseased system. (See one of my earlier pictures.)


Can someone tell me - is the bit loading = 2 thing always true ? For VDSL ? Different for different ADSL implementations ?

[burakkucat]

I really don't know . . . I regard ADSL2(+) and VDSL2 as identical except for the band plans, which define the number of sub-carriers and the split between US & DS.

I know that Fritz!Box devices will very clearly put an indicator for the pilot tone in the plots they show. I have never seen any evidence for a pilot tone when plotting data for my ADSL2 (deceased) and VDSL2 (current) circuits.

[Weaver]

So you haven’t seen a bitloading=2 data point deep dip in your ADSL days?

[burakkucat]

In my code as it is now, implementing algorithm one (of the two described above), I test y at 3 x values: x==40, x==60 or 62 and x==85. The x==60 thing is the approximate mid point, but there is a danger of hitting the pilot tone there, so if x < 4 (I see you have 3 there, so I should perhaps amend my code) then I assume I have hit a pilot tone and so I switch to sample y at x==62 instead. I hopped out of the way sideways by x+=2 because of nervousness about the width of the pilot tone but I was overly paranoid in this respect as you have told me, so x+=1 would have suffixed, but there’s no harm in x+=2 so I’ll leave it as is in case I have hit something other than a pilot tone, possible if the bitloadings are extremely low in a very very diseased system. (See one of my earlier pictures.)

<Nods> in broad agreement.

I was actually looking at that earlier picture when I sketched out that psuedo C-code snippet.

Until such time as you have the raw data, which produces such a plot (from a blighted line), it is difficult to suggest suitable code. Perhaps put together a few examples and wait for the "hollow curve phenomenon" to occur; then test the code.

[burakkucat]

So you haven’t seen a bitloading=2 data point deep dip in your ADSL days?

I don't recall . . . goes to look for anything, stored away, that might help.

<Some minutes later> See the attached image, which shows the bit loading plots for the earliest ADSL2 and the most recent VDSL2 variants of my circuit. (I don't have the data from which the ADSL2 plot was created.)

[Weaver]

So there’s clearly a bitloading==2 in the right place in the ADSL2 plot. I know nothing at all about VDSL2 and the resolution isn’t high enough to allow one to pick out such a thing.

A point about my usage: As you know, I’m not trying to detect the location of a pilot tone, just avoid one if I happen to hit it by misfortune.

Until such time as you have the raw data, which produces such a plot (from a blighted line), it is difficult to suggest suitable code. Perhaps put together a few examples and wait for the "hollow curve phenomenon" to occur; then test the code.

Yes, I don’t know whether or not I have saved data sets from times of illness, I’ll dig around a little more. Maybe if I wait a month or two there will be another outbreak. But

[Weaver]

I just tweaked the algorithm "I" a little. Instead of using y[40]-1, I’m doing the same cautionary test as for y60 in case there’s a pilot tone at x==40. That is:
        x4x = ( y[40] <= 2 ) ? 40+1 : 40;
        y4x = y[x4x];

And as described earlier:
        x6x = ( y[60] <= 2 ) ? 60+1 : 60;
        y6x = y[x6x];

Also the updated algorithm "I", now algorithm v.Ia, reads:
        hollow = y6x < y4x - 1 && y6x <= y[85];

where the -1 is to guard against the effect of quantisation noise messing up the == and < comparisons, that is in case y4x happens to be one bit higher because of quantisation wobble and y6x is not at that same one bit higher level even though they are both approx n+0.5. Also with a final <= test now including an =, altered to better accord with the shape of a hollow curve on the right, which might finish up being horizontal at the right hand end.


Questions:

Is it possible to have zero bitloading on a pilot tone? (I seem to remember something about this in G.992.1 as opposed to G.992.3/G.992.5)

Could anyone who is still on G.992.1 (ie so called ‘ADSL1’, that is the original standard - ADSL that is not ADSL2/ADSL2+) especially send me their bitloading numbers ?

In fact I would be grateful for the bitloading numbers from anyone who is on G.992.x ie G.992.1 / G.992.3=ADSL2 / G.992.5=ADSL2x also send me their bitloading numbers ? Please tell me which standard you’re working on and give me the basic stats too.

[Weaver]

I’m wondering about (1) switching to algorithm II, (2) employing a chained AND of both algorithms. Algorithm II is the ‘height below a straight line midpoint’ algorithm. The more the deviation below a straight line, the more the shape counts as ‘hollow curve’, by definition. Still need the same checks for pilot tones to avoid false data points. Opinions?

BTW, I couldn’t draw a graph with the web app that Burakkucat alerted me to; I realise that I have used that neat little graph drawing app before.


> Is it possible to have zero bitloading on a pilot tone? (I seem to remember something about this in G.992.1 as opposed to G.992.3/G.992.5)

@Kitz, if you are about and are feeling well enough, let me know what you think, as I’m sure that you’re the one who would know. (I know a lot about ‘not being up to it’ at the moment; For example, today I missed my Welsh evening class for the second week now because I was feeling rotten with fatigue.


@Burakkucat - Referring to your ADSL bitloading dataset mentioned c

, I see there’s a 1-tone wide drop down to y=8 bits, somewhere in the region 40 < x < 50. That would really mess up either of my two algorithms if there a hit on x at the ‘mid’ sampling point. I’m using x==60, so by sheer good fortune I would not score a hit on the drop to y=8, but that’s not the point.

@all:
Is there any way to fix this? Need some help from collective brains.

I don’t suffer from that kind of deep dip behaviour in that region currently on any of my three lines, but I want to make the algorithm general; With Burakkucat’s ADSL dataset above, my algorithm II would return a hollow = true for Burakkucat!  

What about replacing the test for a specific pilot tone dip with a test that spots any huge sharp dip? Something like compare :
        is_bogus = (y[x6x] < y[x6x + 2] - 2) && ( y[x6x] < y[x6x - 2] - 2);

Not sure how to weld these expressions into a finished sharp bogus dip guard yet; that’s just a first guess. If a low data point is much much lower than its neighbours then it is bogus, and this includes pilot tones and makes them the same as any other scenarios with other kinds of natural dips. So any bogus points are excluded.

[Weaver]

I have once again altered the core algorithm, now using algorithm II, combined with general sharp dip detection (not just specific to the pilot tone) at the ‘mid’ test point. The x==40 test point has a specific test for being a pilot tone.

    y40 = ( y[40] <= 2 ) ? y[41] : y[40];
    y60_is_bogus = (y[60] < y[60 + 2] - 2) && ( y[60] < y[60 - 2] - 2);
    y6x = y60_is_bogus ? y[62] : y[60];
    ymid = y40 - 1 + (y85 - y40)*(60 - 40.0)/(85.0 - 40.0);
    hollow_curve = ( y6x < ymid );

y6x is supposed to be our ‘middle’ (approx.) test data point. If y60_is_bogus, because that y is a sharp dip, then we step aside to a different x data point and take that y value as our y6x. As discussed earlier, we are looking for a vertical distance hanging down from the straight line (ymid) to our test data point y6x.

I’m not sure what to do about conversion to integers yet. Any thoughts ?