Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Bald_Eagle1 on January 21, 2012, 08:09:36 AM
-
Quite some time ago, following a high number of connection stability and vastly reduced speed problems (regular DS sync speeds as low as 12Mb etc.), I started looking at trying to calculate typical VDSL2 line lengths from known attenuation values & typical attenuation values from known line lengths.
This was with a view to seeing how my connection then stacked up against a "typical theoretical" VDSL2 connection.
i.e. to determine whether or not my own connection now had "faults" that could & should be repaired, or indeed whether or not my expectations were simply too high.
As extensively documented elsewhere, my connection was able to maintain DS throughput speeds of 32Mb to 33Mb for the first month.
The sudden trigger for the vastly reduced performance appeared to be some "unknown" event that caused me to completely lose telephone & FTTC services for a 4 day period.
My previous higher speeds & apparently stable connection have never returned.
I forget where I obtained it now, but the attached document has some basic guidance:-
"For VDSL2 systems that transmit over normal polyethylene-insulated pairs, there is a good approximation of the attenuation A (in dB) at a certain frequency f:
A = k * l * sqrt(f), where k is a wire-dependant constant and l is the length of the wire.
The available spectrum increases distinctly the closer you are to the end user. Whereas the ADSL2 standard (ITU G.992.3) is designed for longer distances (up to approximately 6km, working up to 2MHz), the VDSL2 standard is designed for shorter distances (up to approximately 2km, working up to 30MHz)."
Using my own connection's "engineer reported" details & assuming an overall frequency of 4.15 MHz for the VDSL2 8c profile & a constant cable attenuation of 13.81dB per km we could calculate these examples:-
Attenuation (A) - from a Reported Line length of 0.82km:
A = 13.81 * 0.82 * 2.04
A = 23.1dB (approx)
At one time, an engineer's JDSU reported my attenuation as 30.2dB (a single value for the 8c profile).
Line length (l) - from a Reported attenuation of 30.2dB
30.2 = 13.81 * l * 2.04
1/l = 13.81 * 2.04 / 30.2
l = 1.08km (approx)
Now, for VDSL2 connections, user modems do not report a single attenuation value, rather they report a value for the D1 band, another value for the D2 band, & since the introduction of the 17a profile, yet another value for the higher frequency D3 band.
My modem currently reports:-
D1 = 21.7dB
D2 = 62.9dB
D3 = N/A or 0.1dB
The latest engineer's JDSU recently reported a single attenuation value of approximately 22dB for my 17a profile connection.
It also reported a single attenuation value of approximately 22dB for my 8c profile connection.
At this stage we aren't sure how a JDSU calculates a single attenuation value from the various frequency band attenuation values, but it looks suspiciously like it may have only picked up the value from the lower band.
It surely cannot be reporting an average value across the 3 bands as the maths just don't add up.
If I use the JDSU's single attenuation value of 22 dB to estimate my line length from the formula above, I get a line length of 0.78km.
However, at the time the JDSU's single attenuation value was reported as 22 dB, the JDSU also reported my line length as 1.0km
Due to these discrepancies we could make a number of possible assumptions:-
a) JDSUs are inaccurate
or
b) The formula isn't adequate
or both statements could apply
All the above was based upon the 8c profile.
As the 17a profile uses even higher frequencies than the 8c profile, attenuation values will increase accordingly.
The question "Why does any of this actually matter?" could be posed.
I see it as an aid to troubleshooting either connections that exhibit poor speeds from the outset, and/or an aid to troubleshooting connections that initially exhibited good speeds that have deteriotated.
If we have reasonably accurate ball park figures to work with, we are part way toward understanding what speeds could be reasonably expected for various line lengths etc.
Conversely, we could identify issues such as poor speeds on shorter lines.
Unfortunately I do not have any details of my connection's attenuation values from when its speed performance was much "better".
The simple fact that speeds had deteriorated for a prolonged period suggests (to me) that my connection's current attenuation values must be somewhat higher than they were initially.
I believe my connection is incorrectly being calculated as being 1000m or so in length (possibly based upon attenuation values), thus higher speeds cannot be expected.
If my connection really is closer to 800m or so, maybe I should still expect to achieve the previous higher speeds.
If that is the case, what has caused attenuation values to increase, & perhaps more importantly, what (if anything) could/should be done about it?
From the evidence I have seen in various forum posts, it appears that almost ALL other users who were previously achieving around 33Mb or so DS throughput on the 8c profile are now seeing DS throughput speeds approaching 40Mb since the switch to the 17a profile.
I saw a marginal speed improvement when I was switched to the 17a profile, but I am currently only able to achieve between 26Mb & 27Mb throughput at best (some 13Mb or 14Mb less than the 40Mb cap).
Even when taking typical losses into account, I am still achieving 10Mb or so less than maximum throughput speeds from the 40Mb service.
Thank you asbokid for posting links to various documents in another thread ( http://forum.kitz.co.uk/index.php/topic,10547.msg209077.html#msg209077 )
As soon as time permits, I shall study those documents to hopefully acquire a better understanding of these matters, but I would really appreciate any comments/suggestions from anyone who already has a good understanding, even if it is to completely discredit my various calculations & assumptions by providing more accurate & factual detail.
I do accept that a lot more needs to be taken into account than attenuation values (noise, interference, error counts etc.), but if attenuation values are already artificially too high for any given connection, do other issues perhaps have to take a back seat?
e.g. If attenuation values are higher than expected, could that in itself cause high error rates as the transmitted data simply cannot be received at the same rate that it is being transmitted?
We are all aware that high error counts (amongst other things) can cause DLM to take avoidance action by adding/increasing Interleaving depth, reducing sync speeds etc.
Paul.
-
I haven't got anything to add to your post, Mr Eagle, but just an idea to toss up into the air -- to see if someone catches it or if not, to see how it bounces. ::)
Suppose one were to obtain a Huawei HG612, a LCD screen, keypad, connectors, etc, etc and the services of a competent electronics engineer, who also understands the implementation of a broadband service over Beatie's twisted pairs. Remove the HG612's PCB and use it as the core board of an "Eagle tester"?
The attenuation figures (plural) displayed will be that of all the ranges of the current band-plan and typical line lengths (plural) could be displayed for good copper, good aluminium, poor copper, poor aluminium or any permutation, thereof.
Sync speed, attenuation, possible line lengths, etc, etc, all could be displayed. :-\
Achieve the manufacture of such a device and I'm sure there will be a request for one to be added to the contents of "Walter's Wheelbarrow (tm)". ;D
-
@ BKK & Paul,
Absolutely - it would be an invaluable ballista to help in persuading you-know-who to co-operate !
Kind regards,
Walter
-
Thanks for posting, Paul. You've certainly provided some interesting food for thought.
[...]
the attached document has some basic guidance:-
"For VDSL2 systems that transmit over normal polyethylene-insulated pairs, there is a good approximation of the attenuation A (in dB) at a certain frequency f:
A = k * l * sqrt(f), where k is a wire-dependant constant and l is the length of the wire.
The available spectrum increases distinctly the closer you are to the end user. Whereas the ADSL2 standard (ITU G.992.3) is designed for longer distances (up to approximately 6km, working up to 2MHz), the VDSL2 standard is designed for shorter distances (up to approximately 2km, working up to 30MHz)."
Using my own connection's "engineer reported" details & assuming an overall frequency of 4.15 MHz for the VDSL2 8c profile & a constant cable attenuation of 13.81dB per km we could calculate these examples:-
If I am reading correctly, a nominal insertion loss of 13.81dB/km @ 4.15MHz was discovered for that particular type of cable?
There are mathematical equations that accurately capture the function of insertion loss vs frequency for an empirical set of cable constants.
According to van den Brink, the author of an ETSI publication on cable reference models, those equations are accurate to ~1% at 10MHz and ~2%-3% at 20MHz. [1] They are relatively complex formulas however. (see below).
The formulas can be used to derive the insertion loss at any given frequency for a known cable model.
The attenuation data Hlog(f) obtained from the VDSL CPE could be 'fitted' to the curves formed from plotting the function of insertion loss vs frequency for each model of cable.
That is where our laymen's studies would most profitably continue, IMVHO :-)
cheers, a
[1] http://ftp.tiaonline.org/TR-30/TR-30.3/Public/0206%20Columbia/ETSI%20Documents/970p02r3%20ETSI%20Cable%20Reference%20Models.pdf
-
Hi asbokid,
If I am reading correctly, a nominal insertion loss of 13.81dB/km @ 4.15MHz was discovered for that particular type of cable?
13.81dB/km is the accepted constant for 0.5mm twisted pair cabling and is indeed the value used by Richard M in the spreadsheet that I understand the kitz ADSL calculator was based upon (screenshot attached for reference).
I'm not 100% sure where I got the 4.15MHz frequency from now, but I must have read somewhere that it was an average that could be used for the 8c profile as it appears to be fairly precise value.
TBH, I am really looking for definitive answers rather than attempting to state as fact something that I admit I have very little knowledge of.
Paul.
-
Hi asbokid,
If I am reading correctly, a nominal insertion loss of 13.81dB/km @ 4.15MHz was discovered for that particular type of cable?
13.81dB/km is the accepted constant for 0.5mm twisted pair cabling and is indeed the value used by Richard M in the spreadsheet that I understand the kitz ADSL calculator was based upon (screenshot attached for reference).
I'm not 100% sure where I got the 4.15MHz frequency from now, but I must have read somewhere that it was an average that could be used for the 8c profile as it appears to be fairly precise value.
TBH, I am really looking for definitive answers rather than attempting to state as fact something that I admit I have very little knowledge of.
Paul.
Cheers. The spreadsheet formula seems okay at estimating the attainable rate on this line. (see attached screenshot). . There is an error of ~10% compared to the Huawei's output.
According to Richard's formula, loop length is estimated by dividing (a) the average downstream attenuation value obtained from the CPE by (b) an arbitrary value of 13.81dB/km for cable insertion loss and then (c) multiplying by 1000.
In the source code for the DMT tool, max. loop length is estimated by dividing (a) the downstream attenuation value obtained from the CPE @ 1MHz (DMT tone #231) by (b) an arbitrary value of 13.4dB/km to represent the cable insertion loss(?) and then (c) multiplying by 1000. [1]
When values for the ADSL2+ line characteristics provided by the Huawei HG612 are plugged into those two formulas, the following loop length estimations are obtained:
# xdslcmd info connection info --show
....
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 8000
Max: Upstream rate = 1128 Kbps, Downstream rate = 18468 Kbps
Path: 0, Upstream rate = 1020 Kbps, Downstream rate = 16699 Kbps
Link Power State: L0
Mode: ADSL2+
TPS-TC: ATM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 8.9 12.7
Attn(dB): 19.0 9.7
Pwr(dBm): 20.8 12.4
....
# xdslcmd info connection info --Hlog
....
Tone number Hlog
0 -96.2500
1 -96.2500
....
230 -26.2500
231 -26.3125
232 -26.3750
....
Using Richard's formula, loop length is estimated as (19.0 / 13.81 * 1000) = 1,376 metres
Using the DMT formula, loop length is estimated as (|-26.3125| / 13.4 * 1000) = 1,964 metres
A significant variation of 42%.
cheers, a
[1] http://forum.kitz.co.uk/index.php/topic,2796.msg201269.html#msg201269
-
Thanks asbokid,
Using Richard's formula, loop length is estimated as (19.0 / 13.81 * 1000) = 1,376 metres
Using the DMT formula, loop length is estimated as (|-26.3125| / 13.4 * 1000) = 1,964 metres
A significant variation of 42%.
100m-200m or so difference in physical line length would be quite substantial in VDSL2 terms (regarding achievable speeds), especially if the length was already approaching 1000m.
A variation of 42% appears too significant to be able to consider either of the calculation methods as being "suitable" for VDSL2 connections.
Do you have any indication as to what the "real" line length is likely to be for your ADSL2+ connection, or what is reported in various availability checkers etc. (for comparison purposes)?
Paul.
-
Do you have any indication as to what the "real" line length is likely to be for your ADSL2+ connection, or what is reported in various availability checkers etc. (for comparison purposes)?
Measurements from Google Maps and the Surveying Authority's Definitive Map suggest a loop length of 875m - 925m.
Regarding the cable reference models, linked from [1] and [2] are two academic papers. Both papers are by researchers in Belgium. The authors survey the existing reference models in use, highlight their weaknesses, and suggest a new reference model of their own.
As for discovering loop length, this set me thinking. Is there any way for the public to obtain BT infrastructure records, to secure more accurate data on loop length?
BT Openreach operates a Maps-by-Email service (MBE) for land developers who need to know where underground cabling is laid. [3] Is that service open to the public?
If it is off-limits then perhaps the infrastructure records could be opened up by way of a request under the statutory provisions in the Freedom Of Information Act (FOIA) 2000. [4]
The Information Commissioner has previously ruled that BT is exempt from answering FOIA requests. The Commissioner has cited the private sector status of the Corporation and also the restrictions in s.393 of the Communications Act 2003 on disclosure of information. [5]
However, most of the records about the UK telephone infrastructure will pre-date the flotation of BT. Those records were drawn up during the golden era of the GPO when the corporation was still in public ownership (and much loved). Who legally owns those pre-privatisation documents and what could this mean for the purposes of the FOIA?
Maybe an avenue for someone very bored to pursue some rainy day!
cheers, a
[1] http://wwwtw.vub.ac.be/elec/Papers%20on%20web/Papers/Boets/BoetsIMTC01_3108.pdf
[2] http://www.imeko.org/publications/wc-2006/PWC-2006-TC4-047u.pdf
[3] http://www.openreach.co.uk/orpg/home/network/locatingournetwork/mapbyemail/mapbyemail.do
[4] http://www.whatdotheyknow.com/
[5] http://www.legislation.gov.uk/ukpga/2003/21/part/6/crossheading/disclosure-of-information
-
Measurements from Google Maps and the Surveying Authority's Definitive Map suggest a loop length of 875m - 925m.
So, Richard M's & therefore the kitz calculator appear to be the more accurate of the 2 methods (based upon the very limited data at hand - but for ADSL connections only).
Regarding the cable reference models, linked from [1] and [2] are two academic papers. Both papers are by researchers in Belgium. The authors survey the existing reference models in use, highlight their weaknesses, and suggest a new reference model of their own.
I have speed-read the various documents you provided the links for, but it all seems rather complex at the moment.
The kitz ADSL Exchange & Line Checker suggests 4.99km for my distance from the exchange (by road).
Having driven the route many times, I am inclined to agree with those distances.
My ADSL DS attenuation was reported as 63.5dB, so not necessarily 100% accurate as my Netgear DG834GT modem/router at that time did not report values higher than 63.5dB.
The kitz Max ADSL Speed Calculator gives a distance of 5km when entering a DS attenuation of 69dB, but shows no speeds.
My ISP & the BE BRAS Rate checker both inform me that my distance from the exchange is 5283m (presumably from data held in BT's database).
So those calculators appear to be "reasonably" accurate for ADSL connections.
As VDSL2 connections are usually much shorter distances from the cabinet, once a suitable & reliable calculation method has been determined, the discrepancies would no doubt be much less.
From BT Network records, one engineer quoted my distance from the cabinet as 820m, plus just a few metres for cable drops etc. He said 850m would be a near enough approximation.
He appeared to have checked the part of the records that show cables/poles etc. then transferred the approximate cable runs onto another part of the BT Network records that added up the lines that he "drew" onto what looked like an ordnance survey type map.
Another engineer's JDSU reported 1100m for my VDSL2 line length prior to carrying out some repairs & 1000m afterward.
He said the attenuation level hadn't really changed much, but he REFUSED to let me actually see the JDSU readings.
My ISP has "explained" that I can't expect high FTTC speeds due to my distance from the cabinet.
Unfortunately, the agent that told me that actually quoted the 5283m as my FTTC line length. Doh!
The only explanation my ISP has offered for me achieving sustained higher speeds (& apparent stability) for the first month was that it must have been "a fluctuation".
These discrepancies are the reason I keep banging on about line length & attenuation levels.
If I knew the actual line length was actually 850m (with as close to 100% certainty as possible), it may explain why I initially achieved higher speeds, thus my current lower speeds are due to some factor being introduced when my complete loss of connection was restored (high resistance/increased attenuation levels etc.).
Although actual data details are rather vague, everything I have read about VDSL2 speeds indicates that speeds gradually decline over of a line length of around 900m, then decline rapidly thereafter, until eventually tailing off at around ADSL2+ speeds at around 2000m or so.
Whether any such detail would have any effect in prompting further engineering "repairs" is unknown, especially as my ISP continually states my connection is within their supplier's acceptable limits & current speeds exceed estimated speeds.
The last part WAS true when my estimated speed was 14.6Mb, but it is currently estimated at 30Mb (still less than my initial actual speeds, but getting closer).
As for discovering loop length, this set me thinking. Is there any way for the public to obtain BT infrastructure records, to secure more accurate data on loop length?
:
:
:
:
Maybe an avenue for someone very bored to pursue some rainy day!
I will make some inquiries regarding access to BT's Network Records/maps, but the FOIA sounds a little more like a job for a man with a wheelbarrow in which to carry any obtained data? ;)
As possible food for thought, don't SOME modems have an inbuilt facility to "ping" the DSLAM with some data, timing the return journey & possibly also estimating a line length?
Do you know if the HG612 has any such facility?
It appears that I am in the minority as most FTTC users appear to be very happy with their connections, but I am not the only FTTC user with exactly these queries, but perhaps most of the other disgruntled users don't spend quite as much time "poking around in things".
Paul.
-
Hi
quote It appears that I am in the minority as most FTTC users appear to be very happy with their connections
Just to refresh my memory what is your current synch rate , profile and TX power .
Regards Jeff
-
Hi jeffbb,
Just to refresh my memory what is your current synch rate , profile and TX power .
I know I do go on & on & on & on about it ::), but assuming that's a genuine question:-
Current Sync 26077
Current Profile 26577 (Unusually, that appears to have stuck from when my Sync speed was 27458 for part of yesterday (FTTC profiles = 96.79% of sync speed)
Realistically, my IP Profile should be 25239
Current TX Power 12.2
My connection did have 4 different sync speeds between 07:30 a.m. yesterday & 07:30 a.m. today.
Maybe BT's profile system hasn't had chance to catch up yet?
Paul.
-
Hi
oops sorry meant to ask for receive power . :-[
The one thing that may have changed since your early good days is the receive power .
Regards Jeff
-
Hi
Still losing Synch ? or was that just one of ?
this link might be useful ? http://www.samknows.com/broadband/signup
don't know whether its set up for FTTC
Regards Jeff
-
Hi jeffbb,
The modem's GUI reports Output power (dBmV) 12.2 (Downstream) & 6.3 (Upstream).
I can't give you a single attenuation value as the modem reports different values for each of its 3 frequency band plans, but an Engineer's JDSU did report it as 30.2 dB at the height of my issues & more recently as 22dB (both DS).
Paul.
-
Still losing Synch ? or was that just one of ?
Unfortunately the re-syncs are still quite regular. Not quite as often as they were, but still too many.
Most other FTTC users seem to be able to stay connected for hundreds or even thousands of hours.
Since I have been monitoring closely, I don't think I have exceeded more than around 150 hours, & that was exceptional.
I thought the Samknows Whitebox scheme was either fully subscribed, or had ended.
I'll have a look into that.
Paul.
-
Hi
I may be wrong but your DS power may be low depending which profile you are on ?
see the some profiles below
Selection Of Vdsl2 profiles
Description 8b 12b 17a 30a
Bandwidth (MHz) 8.83 12.0 17.66 30.0
Carriers 4,048 2,783 4,096 3,479
Carrier Bandwidth (KHz) 4.3125 4.3125 4.3125 8.625
Transmission Power(dBm) +20.5 +14.5 +14.5 +14.5 **
Bandwidth (Mbps,bidirectional) 50 68 100 200
** DS power
Regards Jeff
-
Hi jeffbb,
Hi
I may be wrong but your DS power may be low depending which profile you are on ?
see the some profiles below
Selection Of Vdsl2 profiles
Description 8b 12b 17a 30a
Bandwidth (MHz) 8.83 12.0 17.66 30.0
Carriers 4,048 2,783 4,096 3,479
Carrier Bandwidth (KHz) 4.3125 4.3125 4.3125 8.625
Transmission Power(dBm) +20.5 +14.5 +14.5 +14.5 **
Bandwidth (Mbps,bidirectional) 50 68 100 200
** DS power
Ahhh, I assumed you were referring to IP profile rather than VDSL2 profile.
I think the profiles you have mentioned may be either the European or International versions.
I know that parts of America use the 8a profile, & I believe Japan also uses the 8c profile, possibly at full power.
I was on the UK's 8c profile until being switched to the 17a profile near the end of October.
My connection's instability & speed problems actually started at the end of July.
The 17a profile was implemented to enable BT's imminent speed doubling to 80Mb DS & 20Mb US.
I understand that due to the usually longer line lengths in the UK, VDSL2 power levels have been reduced to avoid cross-talk swamping of adjacent ADSL connections on a line-by-line basis. The longer the VDSL2 E-side, the lower the power needs to be near the cabinet.
My cabinet is probably around 4.5km from the exchange, so ADSL signal strengths will already be quite weak at that point, thus my cabinet's power level is probably quite a bit lower than at a cabinet say only 1 km from the exchange.
I must admit that I have wondered if maybe power levels were higher at first & possibly turned down following a month's worth of problem reports from ADSL users in the vicinity of my cabinet.
I have asked my ISP, but like everything else, they have no idea & BT won't tell them.
I still can't fathom out how I achieved very satisfactory & sustained speeds/stability at first, unless something is attenuating my signal more now than it was back in June/early July.
I can only think of reduced power as you have mentioned, or a high resistance issue.
For almost everyone else, the switch to the 17a profile brought a fairly substantial increase in DS speeds, at the expense of a slight lowering of US speeds.
Paul.
-
The longer the VDSL2 E-side, the lower the power needs to be near the cabinet.
sed 's/VDSL2/ADSL/'
I think you mean to say that "The longer the E-side cables, then the more attenuated the ADSL2+ signals will be. Thus the VDSL2 power needs to be adjusted to be comparable to the relatively weak ADSL2+ present at the PCP and, decreasing in strength, along the D-side cables on route to the customers' premises."
-
I think you mean to say that "The longer the E-side cables, then the more attenuated the ADSL2+ signals will be. Thus the VDSL2 power needs to be adjusted to be comparable to the relatively weak ADSL2+ present at the PCP and, decreasing in strength, along the D-side cables on route to the customers' premises."
Yeah, that too ;) :lol:
-
As possible food for thought, don't SOME modems have an inbuilt facility to "ping" the DSLAM with some data, timing the return journey & possibly also estimating a line length?
Do you know if the HG612 has any such facility?
FWIW, I have just discovered that the Fritzbox 7390 does indeed report the VDSL Estimated Loop Length as shown in this TBB forum post:-
How to get a Fritz!Box 7390 working as a VDSL modem (http://forums.thinkbroadband.com/fibre/3994697-how-to-get-a-fritzbox-7390-working-as-a-vdsl-modem.html#Post3994955)
i.e. VDSL Estimated Loop Length : 1120 ft
I know nothing about the Fritzbox 7390, other than a couple of users have it working as a VDSL2 modem for BT's 17a profile FTTC service & it can be accessed via Telnet (with a bit of a palaver).
Perhaps if we could somehow get hold of the code, we may be able to do the same via the HG612 (one way or another)?
Paul.
-
As possible food for thought, don't SOME modems have an inbuilt facility to "ping" the DSLAM with some data, timing the return journey & possibly also estimating a line length?
Do you know if the HG612 has any such facility?
FWIW, I have just discovered that the Fritzbox 7390 does indeed report the VDSL Estimated Loop Length as shown in this TBB forum post:-
How to get a Fritz!Box 7390 working as a VDSL modem (http://forums.thinkbroadband.com/fibre/3994697-how-to-get-a-fritzbox-7390-working-as-a-vdsl-modem.html#Post3994955)
i.e. VDSL Estimated Loop Length : 1120 ft
I know nothing about the Fritzbox 7390, other than a couple of users have it working as a VDSL2 modem for BT's 17a profile FTTC service & it can be accessed via Telnet (with a bit of a palaver).
Perhaps if we could somehow get hold of the code, we may be able to do the same via the HG612 (one way or another)?
Paul.
That's a very interesting find. Some models of 2Wire* Motorola (e.g. 2210, 2241, 3347), models from the Siemens Speedstream series and the Ikanos-based devices from the Sagem f@st family (e.g. 3464) also have an algorithm in their firmware for loop length estimation. [1] [2]
The trouble is these are all closed-source proprietary algorithms and there is no formal mechanism within the xDSL specifications for calculating loop length. When CPE does offer a loop length it must be an estimate derived from other line characteristics data, e.g. HLog(f).
cheers, a
[1] http://www.dslreports.com/forum/remark,22525726
[2] http://www.dslreports.com/forum/remark,22261547
* Thanks to Burakkucat for spotting the error.
-
Thanks for the link asbokid.
It also appears that the FRITZ!Box reports single attenuation values for DS & US rather than differing values for each band plan as per the HG612.
Paul.
-
Thanks for the link asbokid.
It also appears that the FRITZ!Box reports single attenuation values for DS & US rather than differing values for each band plan as per the HG612.
Paul.
I'm sure that between us we could build a reliable algorithm for loop length estimation based on the line characteristics data provided by the CPE.
The maths behind Transmission Line Theory, the "Telegrapher's Equations", and the cable reference models initially looks daunting, but not overwhelmingly so.
cheers, a
-
Hmm. :hmm:
I wonder if the Fritz!Box is running a Linux kernel. If so, the code must be supplied, as per the GPL. :-\
Edit: That TBB thread (http://forums.thinkbroadband.com/fibre/3994697-how-to-get-a-fritzbox-7390-working-as-a-vdsl-modem.html#Post3994955), tells us that the OP was using a AVM Fritz!Box 7390 (http://www.avm.de/en/Produkte/FRITZBox/FRITZ_Box_Fon_WLAN_7390/index.php).
AVM Computersysteme Vertriebs GmbH
Alt-Moabit 95
10559 Berlin, Germany
Phone +49-30-399-760
Fax +49-30-3997-6299
Email: info@avm.de
-
Hi b*cat,
Hmm. :hmm:
I wonder if the Fritz!Box is running a Linux kernel. If so, the code must be supplied, as per the GPL. :-\
Edit: That TBB thread (http://forums.thinkbroadband.com/fibre/3994697-how-to-get-a-fritzbox-7390-working-as-a-vdsl-modem.html#Post3994955), tells us that the OP was using a AVM Fritz!Box 7390 (http://www.avm.de/en/Produkte/FRITZBox/FRITZ_Box_Fon_WLAN_7390/index.php).
Does this link provide anything of interest for those who actually understand these matters:-
Fritz!Box 7390 Linux kernel drivers (http://gpl.back2roots.org/source/fritzbox/7390_5.01/GPL-release_kernel/linux/drivers/char/tffs-2.0/)
Paul.
-
In respect of BT plans......
I live on a private road and we the committee have the plans of all the underground services on the roads - including the BT one. These were obtained quite some time ago (? 2000?) and at that time seemed quite freely available - well I had no problem in getting them but then I did have valid reason to require them.
The world has changed somewhat since then and maybe the plans of critical infrastructure items are no longer made so widely available. The plans I have actually cover area larger than the immediate road. I keep the plans confidential though will supply extracts to residents re the services on their land if they are doing work on their property.
The plans show the main supply cable running down the verge of the road. The details are overdrawn onto the OS digimap series which itself was based on the old 1930's 25" to the mile large scale UK survey. The location of the joint boxes and pole are listed as are their ID/reference Nos. Multipole overhead sections are also shown however the individual routes from the nearest pole to an actual property (ie the dropwire routes) are not shown, nor are the number of houses fed from a particular pole stated.
So it does show the route of the cable should you wish to follow it.
However the plan does not show the depth of the cable in the ground, or the exact position of the cable with reference to any fixed point, nor the cable type, or how many circuits are on each cable. Some of the positions of the joint boxes are out horizontally by up to 5 meters but most are pretty accurate. As all the cable locally is armoured in ground not in ducts so I have no idea if ducted cables are shown differently.
In my area of rural home counties actually the cable run is pretty obvious and the map is of no real use - it's down the verge in all cases and then along undeneath a footpath alongside the road back to the exchange from the street box.
Hop this helps
-
I just downloaded the 424MB tarball of tarballs containing the GPL'ed code for the Fritz!Box 7390 [1]
Unfortunately, there are no signs of a loop length estimation algorithm in the tarballs.
cheers, a
[1] http://download.avm.de/develper/opensrc/
-
Hmm. :hmm:
I wonder if the Fritz!Box is running a Linux kernel. If so, the code must be supplied, as per the GPL. :-\
Edit: That TBB thread (http://forums.thinkbroadband.com/fibre/3994697-how-to-get-a-fritzbox-7390-working-as-a-vdsl-modem.html#Post3994955), tells us that the OP was using a AVM Fritz!Box 7390 (http://www.avm.de/en/Produkte/FRITZBox/FRITZ_Box_Fon_WLAN_7390/index.php).
Does this link provide anything of interest for those who actually understand these matters:-
Fritz!Box 7390 Linux kernel drivers (http://gpl.back2roots.org/source/fritzbox/7390_5.01/GPL-release_kernel/linux/drivers/char/tffs-2.0/)
Apparently not, according to our Asbokid. (See above.) :(
-
Unfortunately, there are no signs of a loop length estimation algorithm in the tarballs.
Ah well, at least it gave you something to do for a few minutes ;)
-
Hi c6em!
Thank you for the info. It's interesting that you obtained the data from BT. That was very fortunate and useful to you. Access to the information is doubtless different when the land is your own.
The dog and I went on midnight manoeuvres the other night. We hoped to discover the route of the line from the house to the exchange. The idea was to trace the ducting by following the GPO/POT/Telecom/BT manhole covers. It was a modern version of the Hansel & Gretel story with an urban twist: we had to dodge the cops. They are on high alert for anyone acting suspiciously around manhole covers. Last month alone, the Great Drain Robbers nicked 200 covers.
Eight candidate cable routes were discovered, of which six are 'sane'. These routes were all paced out. However, at each strategic road junction tracing the ducting any further was complete guesswork. Over three miles were trudged in the pursuit of science! Strangely, just one PCP was encountered enroute. A forlorn little thing it was, too.
cheers, a
-
This document looks interesting / relevant:-
JD Loop Analysis using DSL Data HLog, QLN, SNR, and BPT (http://www.jdsu.com/ProductLiterature/loopanalysis_an_tfs_tm_ae.pdf)
-
Hi c6em,
Unless you have something very special I very much doubt the cable is armoured.
If it is, just watch out in case it is a steel tape armour which is almost certainly a 414 V three phase power cable, usually a minimum of around 25 mm diameter (or larger). A single phase house service is around 20 mm.
If it is steel wire armour around 30 mm dia. then you've probably found the 11 kV high voltage cable !
Kind regards,
Walter