In reply to a post by solchain:

Am I right in getting from this that you may get the HG612 modem stats working with a TalkTalk HG635 or have I completely missed the point?

Yes, that's right.

My program already obtains the raw data & I'm working on getting it formatted to use with the existing graphing programs etc.

I don't have a HG635 here, so it's taking a while to tweak the programs, send them for testing & work out what else to adjust, but I'll get there in due course.

In reply to a post by Bald_Eagle1:

In reply to a post by solchain:

Am I right in getting from this that you may get the HG612 modem stats working with a TalkTalk HG635 or have I completely missed the point?

Yes, that's right.

My program already obtains the raw data & I'm working on getting it formatted to use with the existing graphing programs etc.

I don't have a HG635 here, so it's taking a while to tweak the programs, send them for testing & work out what else to adjust, but I'll get there in due course.

Not wanting to hijack this thread, but bald_eagle if it's any use I have a spare talktalk 633 if it might help, what you are doing would be of interest to me (if it works with the 633 as that is my main modem) so would be happy to help.

I have a customer who has a spare hg612 which I can have if I collect it, but what you are doing would suit me more.

Talktalk only supply the hg633 now.

In reply to a post by solchain:

Not wanting to hijack this thread, but bald_eagle if it's any use I have a spare talktalk 633 if it might help, what you are doing would be of interest to me (if it works with the 633 as that is my main modem) so would be happy to help.

I have a customer who has a spare hg612 which I can have if I collect it, but what you are doing would suit me more.

Talktalk only supply the hg633 now.

I'm sorry. I don't know if the programs will work with a HG633.
Can you access it to get the stats via telnet or like a HG612, does it need unlocking or the firmware updating first?

I have also asked this elsewhere.

In reply to a post by RobertoS:

Line 27 seems to have the same iffiness as in this thread.

I don't think so. The number 17689015 doesn't fit the right format; the best way to check is to put the number into a calculator with a binary mode - the one in Windows 7 has a "programmer mode", with a radio button that allows you to enter in decimal, then swap to binary, and includes an extra binary display.

If it shows with all the high-end bits as "1", then it is a candidate. The highest bit absolutely *must* be "1" (it signifies a negative number, in signed integers).

By "all high-end bits", I mean up to a nice byte boundary - so to bit 15, or bit 31 in most cases.

17689015 = 00000001000011011110100110110111

From the other thread,
4294967290 = 11111111111111111111111111111010

For me, Line 27 is of the right kind of order as Line 4 downstream, with the difference explainable with 1 resync while the box has been up.

The first hint of something wrong is that Line 4 downstream is relatively large compared to Line 3 downstream, suggesting a lot of noise.

What looks "off" is that Line 3 downstream shouldn't hold the same value as Line 1 downstream, and neither should be the same as upstream.

In reply to a post by RobertoS:

I assume it's 20-24 you are referring to?

I've never seen these lines before.

UPBOkle appears to stand for "Upstream Power Backoff" "electrical loop length" "estimated"

UPBO = Upstream Power Backoff
KL = electrical loop length
E = estimated

Going well off-topic:
I've certainly seen "kl₀" used to represent electrical loop length before, in some graphs for vectoring; I think it is measured in dB, and is a form of attenuation ... but it usually comes with a specification of what frequency is being measured. For example, "a kl₀ of 20db @ 1MHz".

One interesting document that shows actual trial results for VDSL2 Vectoring comes from Denmark, but their graphs for rate vs reach are done using "kl₀ @ 1MHz" values...
https://erhvervsstyrelsen.dk/sites/default/files/pun...

From BT's SIN 498, it appears that they think 500m of 0.5mm copper is "(equivalent to an electrical loss of 10dB measured at 1MHz)" which I guess makes it easy to compare the Danish results.

That SIN also tells us that the CAL value for each cabinet is calculated from the loss at 300kHz; my rule of thumb for *that* kind of loss is that 10dB represents 1km, so scales differently from that measured at 1MHz.

The Danish document has this factor: "dB[150 kHz] = 0,38* dB[1 MHz]"

From all that, I reach the conclusion that we can't know what a value of 7738 means for UPBOkle, without knowing what frequency it is measured at.

So things where ongoing and i came home yesterday to find interference/crackling on the phone side and intermittant sync'ing and the line dropping out all over the place.

I removed the openreach mk3 faceplate, put the talktalk router and microfilter back and replaced my cordless phones with a corded phone and still no difference.
After speaking to TalkTalk 3 times last night they are saying it's a "battery" or contact issue outside the property.

Needless to say DLM has gone mental trying to stabilise the line from what was a solid 37mbps for the last 7 days (no drop outs) to a pitiful 15mbps overnight last night and dropping packets left right and center.
I did tidy up all my cabling around the router and remove any things that i thought could affect the line but this made no difference to the interference but it sync'd up at 35mbps before i left for work this morning. I won't know what it's like until i get in later.

I'm just hoping TT will get just get openreach out and make sure everything is as it should be and hopefully reset DLM as yesterdays antics is probably not going to help!