Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: gazaai on December 01, 2015, 09:59:11 AM
-
Hi all, I thought I would create my own topic on here about the Bridge Tap, 'WWWombat' has found with my stats on MyDSLWebStats. Here is an image that proves my line does not look normal:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fimagizer.imageshack.us%2Fa%2Fimg907%2F7558%2FwfVZaO.png&hash=1f4cfa3531cb954892a971648eb1220affdd88ab)
I have had a look online about bridge taps and none seem to look like mine, as others seem to have one v dip where as mine seems to continue from the start of the graph to the end. So can anyone help explain why my graph looks like this?
Thanks
-
It is possible for a bridging tap to cause multiple dips in an Hlog graph.
I will recommend that you download the "Detecting Bridged Tap and Noise Interference in VDSL2 Access Networks using the JDSU SmartClassTM TPS" (http://www.viavisolutions.com/sites/default/files/technical-library-files/sctpsbridgedtap_an_tfs_tm_ae.pdf) PDF document and take note of the method described on Page 6, which makes use of Table 2 on Page 7.
-
It is possible for a bridging tap to cause multiple dips in an Hlog graph.
I will recommend that you download the "Detecting Bridged Tap and Noise Interference in VDSL2 Access Networks using the JDSU SmartClassTM TPS" (http://www.viavisolutions.com/sites/default/files/technical-library-files/sctpsbridgedtap_an_tfs_tm_ae.pdf) PDF document and take note of the method described on Page 6, which makes use of Table 2 on Page 7.
Interesting read :).
-
It is interesting although I don't understand most of it lol :D
-
@gazaai it's to do with the reflections back from the far end of the loose wire. These reflections setup an interference pattern when they are combined with the outgoing waves heading towards the far end. The combined interference pattern from these two wave chains produce a resonance, the resonance pattern is determined by the wavelength of the waves travelling up the wire. The resonance is exactly like an organ pipe's resonance, a guitar string is not quite the same as both ends of it are tethered whereas here one end is free to waggle about.
The reason for the dips in the graph is to do with the fact that changing frequency means changing wavelength. That means either a whole number of wavelengths fit into the length of the loose wire or not, and it's the pattern of fitting a varying number of waves of varying wavelength into the fixed length of the wire that produces the repeating pattern you see. Going to a higher frequency means shortening wavelength until n+1 whole waves will fit into the wire's length.
I do hope I made sense of this; it's easier with nice pictures.
-
Incidentally the same thing can happen on a TV aerial installation if someone thinks 50Hz techniques apply !
-
@JGO quite so. And with (parallel) SCSI hard disk cables, which have an absorber at the end of the cable to eat up the signal and prevent back reflections.
-
It is interesting although I don't understand most of it lol :D
If you would be willing to make the raw Hlog data available, I'll see if I can do the relevant calculations. :)
-
I have had a look online about bridge taps and none seem to look like mine, as others seem to have one v dip where as mine seems to continue from the start of the graph to the end. So can anyone help explain why my graph looks like this?
Short answer: your dip appears to be caused by a long length of extra wire (I calculated 66m); other examples may well be shorter lengths.
Long answer:
As others mention, the technical explanation is that the dip is caused by reflections from the far end of the extra bit of wire; the frequency the first dip is seen at depends on the length of that wire, and the wavelength of the matching frequency; Table 1 in that linked PDF gives you an idea of the relationship.
Whatever the first frequency (or tone number N) the dip first appears on, there will be repeats at 2N, 3N etc. This is a kind of resonance effect - whatever length of wire is an exact match (in terms of whole wavelengths) for frequency F is always *also* going to match 2 wavelengths of half that size (ie 2F frequency), and 3 wavelengths of a third that size (ie 3F frequency).
In figure 2 of the PDF, the example shows a dip at tone 1400. By table 1, that means the tap is 8m long. It also means there will be further dips at tone 2800, 4200 etc ... but the display just doesn't show them.
Your picture has the first dip at about tone 164, which is too low for table 1 to help - suggesting the tap is longer than 46 metres, up to maybe 100m-ish. However, table 2 does apply, even though the text describing how to use it (at the end of page 6, "Occasionally, this is too difficult ...") can be hard to follow.
The way to use table 2 is to see that your first dip is at tone 164, and your third dip is at tone 834. The difference between tone 164 and tone 834 (or tone delta) is 670. Using the column titled "1 sub-dip" (because there is one sub-dip between the first & third), we can see the tap is of a length between 66.3m and 71.3m
-
If you would be willing to make the raw Hlog data available, I'll see if I can do the relevant calculations. :)
Sorry - I've had my calculations in a partially-written post all afternoon, waiting for me to finish it off!
Raw data is on MyDslWebStats, but I don't think you use that, do you?
-
Hmm . . . Assuming that the tone number per minima can be ascertained reliably, then a simple multiplication of the tone number by 4.3125 kHz will give the relevant frequency.
But as you are already "part way there", I'm happy for you to finish the task. :D
Edited to add -- I am fairly sure that I have read (somewhere) how it is possible to determine the length from the observation point to the start of the tap. And with that figure, it should then be easy to "point a paw" to where in the circuit that the tap begins.
-
I seem to remember that the TDR facility on the HST-3000C will detect bridge taps - but at the Cab?
-
Hi, how can I get my raw Hlog data then. Is there a command? and yes I am on myDSLwebstats. Username: GaZaai
-
Hi, how can I get my raw Hlog data then. Is there a command? and yes I am on myDSLwebstats. Username: GaZaai
I see you're using DSLstats. Look at Telnet Data --> HLog. Copy that text to a message here.
-
I seem to remember that the TDR facility on the HST-3000C will detect bridge taps - but at the Cab?
Indeed. Any time domain reflectometer will be capable, even my Tester 301C.
Thought experiment.
Once upon a time, there was a primary cross connection cabinet. As it was a lonely cabinet, a "fibre twin" was located nearby and those two cabinets were then interlinked with a pair of tie cables. Looking into the newer "fibre" cabinet, we see that the two pairs of tie cables can be designated as D-side and E-side. The only difference between the two separate cable bundles is that the circuit pairs in the designated E-side cable are connected via low pass filters, one per circuit.
Question: What would be the result if one low pass filter was faulty? Or was never correctly fitted?
Answer: The E-side pair of that particular circuit would act as a very definite bridging tap of significant length.
Musing: Could the above be the cause of what is visible in the Hlog plot for gazaai's circuit? :hmm:
-
It sounds like it could be burakkucat ;), as there defiantly no extra cables in my house, it comes from the telephone to the side of the house then through the atic into the master socket.
Here is my Hlog Data from DSLStats:
http://pastebin.com/RLJ7tri1 (http://pastebin.com/RLJ7tri1)
-
The raw data of the Hlog plot was downloaded and saved as Hlog-gazaai.txt (attached below).
Using one of the scripts (saved from the very early days of our circuit statistics analysis) the Hlog plot was created locally as Hlog-gazaai.png (attached below).
Using the latter as a reference guide into the former, the following table was then drawn up --
Index Tones at Minima Use as Midpoint Frequency of Midpoint (kHz)
----- --------------- --------------- ---------------------------
1 160 - 167 163.5 705.09375
2 496 - 503 499.5 2154.09375
3 832 - 839 835.5 3603.09375
4 1144 - 1151 1147.5 4948.59375
5 1512 - 1519 1515.5 6535.59375
6 1848 - 1855 1851.5 7984.59375
7 2192 - 2207 2199.5 9485.34375
8 2528 - 2535 2531.5 10917.09375
9 2864 - 2887 2873.5 12391.96875
10 3208 - 3215 3211.5 13849.59375
11 3552 - 3567 3559.5 15350.34375
12 3936 - 3943 3939.5 16989.09375
Reworking the above table to show the delta of the midpoints gives --
Index Tones at Minima Use as Midpoint Delta of Midpoints
----- --------------- --------------- ------------------
1 160 - 167 163.5
336
2 496 - 503 499.5
336
3 832 - 839 835.5
312
4 1144 - 1151 1147.5
368
5 1512 - 1519 1515.5
336
6 1848 - 1855 1851.5
348
7 2192 - 2207 2199.5
332
8 2528 - 2535 2531.5
342
9 2864 - 2887 2873.5
338
10 3208 - 3215 3211.5
348
11 3552 - 3567 3559.5
380
12 3938 - 3943 3939.5
The average of the above eleven deltas is 343.
Looking at Table 2 (in the PDF document (http://www.viavisolutions.com/sites/default/files/technical-library-files/sctpsbridgedtap_an_tfs_tm_ae.pdf), referenced in my initial post) we see that there are entries for deltas of 300 and 350 --
Tone delta Sub-dips
0 1 2 3
300 77.3 154.6 231.9 309.2
350 66.3 132.5 198.8 265.0
By simple algebra, we can inset a line for a tone delta of 343 --
Tone delta Sub-dips
0 1 2 3
300 77.3 154.6 231.9 309.2
343 67.6 135.2 202.8 270.4
350 66.3 132.5 198.8 265.0
The line for the tone delta of 343 now needs to be expanded horizontally to accommodate ten sub-dips.
The entries on the line for the tone delta of 343 may be derived by simple linear programming. The general formula for a straight line is --
y = mx + c (1)
By inspection of the first four values on the line for the tone delta of 343 it can be seen that --
c = m (2)
and c = 67.6
By substituting equation (2) in to equation (1) we obtain --
y = m(x + 1) (3)
As there are twelve minima seen in gazaai's Hlog plot, we are interested in solving equation (3) for the case of m = 67.6 and x = 10
Substituting those values into equation (3) gives --
y = 67.6 (10 + 1)
= 743.6 metres
We now have a tentative length for the bridging tap -- approximately 744 metres.
Realistically, where could a bridging tap with a length of 744 metres be located? Where could such a tap of that length start? :-\
It would be very interesting to know the length of the E-side for gazaai's circuit. If the network records were to show that the E-side length is between 700 and 750 metres, then I would know exactly what to check . . . and where --
The relevant low pass filter for gazaai's circuit in the "fibre cabinet".
b*cat looks towards WWWombat and asks that he please review the above caterwauling. ;)
[Edited to include the last dip (the twelfth) that had been missed from the original calculations. Look closely at the Hlog plot, attached below.]
-
Wow very interesting, also what do you mean by e-side and do you really think there is a 600m bridge tap that seems a bit doubtful lol?
I really want to get an openreach engineer out here and see what his testing equipment shows. :)
-
First, just consider just the classic telephony circuit.
There is a pair which leaves the exchange building and, as part of a cable bundle, proceeds to the PCP. That is the E-side for your circuit. Let us call the physical length of your E-side LE.
In the PCP, the E-side is connected to the D-side of your circuit. Let us call the physical length of your D-side LD.
The total circuit length, from telephony equipment within the exchange building to the NTE5/A in your home, will therefore be the sum of the E-side length plus the sum of the D-side length plus the sum of the final drop (or service feed) into your home plus any internal wiring (on the Openreach side of the NTE5/A). Thus --
LTotal = LE + LD + LOther
where LOther is the sum of the final drop (or service feed) plus any internal wiring to the NTE5/A.
A Broadband Internet (VDSL2) service is now added to the above.
Within your home, let us assume that a centralised filter is fitted to the NTE5/A. The low frequencies (300 - 3400 Hz) now only reach the telephony socket and the higher frequencies (~26 kHz and upwards) only reach the modem (or modem/router). (See xDSL Frequency Plan for Annex A (https://en.wikipedia.org/wiki/Asymmetric_digital_subscriber_line#/media/File:ADSL_frequency_plan.svg).)
In the PCP, at the junction of the D- & E-side cables, the direct connection of those two parts of the circuit are severed. They are each connected to a tie cable pair to link the "fibre cabinet's" DSLAM into the circuit. Within the "fibre cabinet", those two pairs are connected to the same point -- the line card port of the DSLAM. In the case of the D-side pair, they are connected directly. In the case of the E-side pair, they are connected via a low pass filter.
The length of the metallic pathway for the Broadband Internet service is --
LOther + LD + LD-tie (1)
where LD-tie is the length of the D-side tie cable.
The length of the metallic pathway for the telephony service is thus lengthened to --
LOther + LD + LD-tie + LE-tie + LE (2)
where LE-tie is the length of the E-side tie cable.
In terms of the location, the low pass filter should "appear" between LD-tie + LE-tie, thus --
LOther + LD + LD-tie + Low Pass Filter + LE-tie + LE (3)
where I now make use of the formula that defines the telephony total circuit length as indicators of the wires of the circuit pair.
Consider the telephony circuit defined in equation (2); all is good the telephone operates satisfactorily.
Consider the telephony circuit defined in equation (3); all is good the telephone operates satisfactorily.
Equation (3) is the normal situation when a VDSL2 service is provisioned to share the pair (D-side + Other) to your home.
If the situation depicted by equation (2) becomes true (the low pass filter becomes faulty, falls out or has never been correctly inserted) then there is no effect on the telephony service.
However, for the VDSL2 service, which is normally depicted by equation (1) the situation becomes sub-optimal (or even disastrous). The VDSL2 service now "sees" the situation as depicted by equation (2). The E-side of the pair, which just brings the telephony service to the cabinet, has become a bridging tap of length LE-tie + LE.
It is my current speculation that LE-tie + LE is of the order of approximately 744 metres. The only cause for this defect would be a problem with the low pass filter within the "fibre cabinet".
[Edited to correct the approximate length, as a result of reworking my earlier calculations to include the last dip (the twelfth) that had been missed from the original calculations.]
-
Or to summarise, if your exchange is approximately 682 metres from your PCP, the hypothesis looks a good one.
-
The exchange may well be 600m away from the cabinet, here is the layout of my line here:
(https://i.gyazo.com/d613aa8c33d3c921c03e404677df6767.jpg)
-
Having "brought up" Carstairs [1] on Google Maps, it was asked to provide the distance between the PCP/Fibre Twin and the exchange building (image attached, below).
It came up with approximately 0.6 mile which, according to my arithmetic [2], is 960 metres.
[1] In the early 1970s, I lived in Carstairs Road, Liverpool. :)
[2] 0.6 x 8 x 1000 / 5 = 960
-
So what do you reckon then, do you think it could still be the cable from the exchange acting as a bridge tap?
-
If I may, on the back of all the great posts from the regulars ....... my educated guess would be that the 'Tap' is on the D-side. These kind of 'Taps will only occur (on both E and D sides) if the Cab has Quante or Krone connection strips.
The chances of accidentally connecting a 2nd D-side pair to the one the engineer is already working on, in a 'Crimp-only' Cab, is incredibly extreme.
-
Something odd is occurring with the circuit. :(
I have no definitive answer. All my calculations are "best effort", using approximations. :-\
Based on my calculations, if I had "the ways and means", I would inspect the terminations in the fibre cabinet and also give a critical examination to the low pass filter for the circuit. :-X
For Mr B*Sheep -- I use the terminology "bridging tap" in the correct sense of the phrase but, in the scenario described above, there is no abnormal wiring proposed as connected to the circuit. It is the speculated absence of the low pass filter or a speculated defective low pass filter for the circuit in question that makes the telephony E-side appear as a bridging tap across the VDSL2 circuit. ;)
[Couldn't you experiment on your own VDSL2 circuit? Nip down to the fibre cabinet, identify the relevant low pass filter, remove the same and then, back in the sheep-fold, check your circuit's behaviour with your JDSU HST-3000c? :D ]
-
Something odd is occurring with the circuit. :(
I have no definitive answer. All my calculations are "best effort", using approximations. :-\
Based on my calculations, if I had "the ways and means", I would inspect the terminations in the fibre cabinet and also give a critical examination to the low pass filter for the circuit. :-X
For Mr B*Sheep -- I use the terminology "bridging tap" in the correct sense of the phrase but, in the scenario described above, there is no abnormal wiring proposed as connected to the circuit. It is the speculated absence of the low pass filter or a speculated defective low pass filter for the circuit in question that makes the telephony E-side appear as a bridging tap across the VDSL2 circuit. ;)
[Couldn't you experiment on your own VDSL2 circuit? Nip down to the fibre cabinet, identify the relevant low pass filter, remove the same and then, back in the sheep-fold, check your circuit's behaviour with your JDSU HST-3000c? :D ]
Ha ha, alas ...... Openreach engineers have no access keys for the DSLAM cabs.
My apologies, I thought that there was an inference that there was some kind of 'Wired tap' ??. I know from personal experience that D-side 'Taps' can occur, especially when the Cab is a 'rats nest' and more often than not the terminating strips will be at low-level, making it difficult to notice if there is indeed another pair connected to the EU's circuit.
I'll bow out now as I seem to be muddying the waters. ;) :) :)
-
I'll bow out now as I seem to be muddying the waters. ;) :) :)
I will dispute that! You have made valid contributions, based on real life experiences. :thumbs:
-
Can see why BS calls it a rats nest
-
A lot of information in this topic I don't have much of a clue on haha
I am getting a call back from BT tomorrow to hopefully arrange an engineer visit, I think I might have to pay for it tho and its £130 :o
Although I really want to get his opinion, do you guys have any advice for me. And is it true that he doesn't have an access key to the cabinet. As that could be an issue would you not agree? as he probably wont bother to escalate it further as my line is performing fine.
-
> I'll bow out now as I seem to be muddying the waters. ;) :) :)
Even if that were true, you're still massively in credit anyway BlackSheep !
Your contributions are always essential reading.
-
> can see why BS calls it a rats' nest
Having seen a real rats' nest in my small shed some years ago, complete with rats, I appreciate how much it is a wonderful descriptive expression. How the buggers do seem to like metal cables, steel as well as copper! Why on earth is that?
-
And is it true that he doesn't have an access key to the cabinet.
Yes, it is true. Openreach engineers (or technicians, to use the correct description) are only responsible for the "last mile" . . . the (essentially) analogue access network via which we end users make our connection. The limits of the Openreach domain is the NTE5/A in the EUs' premises and the MDF in the serving telephone exchange. Everything deeper into the network is the domain of Operate and that is a world of (essentially) digital circuits (junction circuits, main core circuits, etc) be they over a metallic pathway or optical fibres. The "fibre" cabinets that we see out in the streets are part of Operate's domain and it is the Operate engineers (or technicians, to use the correct description) who maintain them.
If you were to look closely at the locks on a "fibre" cabinet, you will see three different types of lock on every cabinet. The standard GPO/POTel/BT/Openreach "triangle" lock, a "star" lock and a security lock. Operate engineers will have all three types of key. If an Operate engineer was to release the security lock, then an Openreach engineer could then access, with his "triangle" key, that part of the "fibre" cabinet into which the fibre-optic cable from the head-end exchange enters, the tie-cables are terminated and the low pass filters reside. The other section of the "fibre" cabinet, for which a "star" key is required to gain access, contains the DSLAM, power supply, backup batteries, etc.
-
Is it possible that Operate keep the cabinets security unlocked, as I seen Openreach at the cabinet about once every two weeks?
Oh I can see this being a waste of money then getting an engineer out, if he is just going to do a test within the home and detect nothing. I cant even get him to check the cabinet that's disappointing :-\
-
Is it possible that Operate keep the cabinets security unlocked, as I seen Openreach at the cabinet about once every two weeks?
Sorry, I am unable to answer that question. :no:
I will, however, ask if you are sure that it was the "fibre" cabinet, and not the PCP, at which you saw an Openreach technician? :-\
-
Oh you may be right, I haven't really cared to look into much detail but I see them parked next to the two cabinets. But I think it may well be the older ADSL cabinet then.
I know you probably can't answer this question but another opinion is good. So if an openreach technician came out with his HST device and found a bridge tap fault. He would then have to contact someone else who has access to the cabinet to deal with it?
Then it would seem openreach wouldn't really care as my speed is well within the acceptable range. I guess it may still be worth getting it checked and see where it leads. :)
-
Firstly, B*Cat/Weaver ..... cheers lads. :-[
Now then, back to gazaai ..... if you go back through Kitz forum over many threads, you will see how you are pretty much taking a gamble with an engineering visit !!.
Openreach's mandate is for the Broadband Engineer to perform 3 tests ....... a Pair Quality Test (PQT ..... does as it says on the tin, tests the quality of the pair of wires from your premises back to the Exchange), a VDSL Close-out test (This is a 5-minute test that logs onto the ISP server and basically transmits and receives data whilst looking for FEC/CRC), and finally an Eclipse Test (This is basically to test the low-frequency phone part of the circuit. However, the majority of Broadband faults will see the Eclipse test incorporate a secondary test called CIDT. This 'pings' the router at different frequencies and then gives a test result. The CIDT is great for a HR-type fault, but not 'Bridged Taps').
Alas, all 3 tests mentioned above are unlikely to show a 'Bridged tap'. As I've mentioned earlier, our WHOOSH GEA remote test-bed is very, very good at determining if there is a 'Tap' on a circuit. This same test will have been carried out when you raise a fault, and will be on the engineers notes to say whether one has been detected.
As I've also said many times previously, the tests we perform will identify 95% of fault conditions no problem, it's the other 5% that cause the most consternation.
Add to the mix the fact that you wont know what engineer you're going to get, experience really does count in bundles when dealing with broadband faults. Bearing in mind we are constantly under relentless pressure to 'move on', if the 3 tests outlined above all pass, and you are within the estimated speed bandwidths ........ then a large percentage of engineers would probably close the job off as 'No fault found', and you will be charged.
The only hope you've got is either the tests do show a fault, or you get an engineer who knows what a 'Bridged Tap' is and is willing to look at the Cabinet even if all tests do pass.
:)
-
On the phone with BT they have done tests on my line but have said it is performing fine. How do I know they are doing a "WHOOSH GEA" test and not just checking if I am connected?
Thanks
-
On the phone with BT they have done tests on my line but have said it is performing fine. How do I know they are doing a "WHOOSH GEA" test and not just checking if I am connected?
Thanks
I can't answer that, as I don't have anything to do with BT Retail.
-
So if an openreach technician came out with his HST device and found a bridge tap fault. He would then have to contact someone else who has access to the cabinet to deal with it?
If the former event came to pass then, yes, I would agree with your latter presumption.
On the phone with BT they have done tests on my line but have said it is performing fine. How do I know they are doing a "WHOOSH GEA" test . . .
There is no way of knowing. If you asked the question it is highly likely that the front desk person, with whom you would be communicating, would not have a clue. Everything is "scripted", with just "yes/no tick boxes". :-X
-
b*cat looks towards WWWombat and asks that he please review the above caterwauling. ;)
I'm not sure you should be converting from 68m to 680m.
But I could be entirely wrong, so I'll read the rest of the thread, then go back and read the PDF, and then research a little more...
-
I'll bow out now as I seem to be muddying the waters. ;) :) :)
I think the waters were muddy to start with.
However, you bring a wealth of practical knowledge, learnt/earned at great expense on real, live equipment. That's worth so much more than theory alone.
-
. . . I'll read the rest of the thread, then go back and read the PDF, and then research a little more...
Thank you. That would be appreciated. :)
-
I'll bow out now as I seem to be muddying the waters. ;) :) :)
I think the waters were muddy to start with.
However, you bring a wealth of practical knowledge, learnt/earned at great expense on real, live equipment. That's worth so much more than theory alone.
Very kind of you to say so W3. Asbokid said exactly the same a few years ago, and he is was the mutts nuts when it came down to technology in any form. his comments were along the lines of "I've probably read every technical paper there is to read, but never put it into practice in real-life".
Now, (as certain folk already know), I really am in awe of you guys who 'see' things that would take me a life-time to achieve. What I have learned from the guys (and gals ...... kitz ;) ;D ), has earned me a modicum of respect at my place of work. It had to be self-taught as out home-grown courses are p1ss-poor.
So, all-in-all ....... I think we make a helluva good team on here with my role as I see it, to a) add balance to the BT-hating debates, and b) give an insight as to how we are told to operate as engineers.
To quote Aristotle, "The whole is greater than the sum of its parts.” ...... which I think is very apt for this forum. Right, lets all fill our glasses and ......... well ....... get merry !! :drink: ;D ;D
-
. . . I'll read the rest of the thread, then go back and read the PDF, and then research a little more...
Thank you. That would be appreciated. :)
I found a different JDSU document that calculated differently, with this formula:
"160 ÷ Frequency in MHz = Tap Length in feet using the frequency in MHz at the point of the first null, or center frequency of the dip."
I'm on a tablet right now, and can't get the URL to link to. I'll add it later.
I also think the formula is more valid for US copper plant, but it is going to give us the right order of magnitude.
The first dip was around tone 164, or frequency 0.7MHz.
160 ÷ 0.7 = 228 feet, = 69 metres.
I'll go back and figure out how to explain the original document tomorrow.
-
his comments were along the lines of "I've probably read every technical paper there is to read, but never put it into practice in real-life".
Conversely, I've read a lot of technical spec's, usually layer 2 or layer 3 interface specs, and written software to implement them. That software is a bit like Frankenstein's Monster - I let it loose, it does what I tell it, based on what I interpret real life to be from those documents. But the monster can turn on you, because real life has a habit of not quite behaving like the documents say.
I've learnt that it pays to be able to log behaviour of the monster, and to interpret logs to be able to track where real life doesn't match my ideas. Insight into real life behaviour is invaluable.
What I have learned from the guys (and gals ...... kitz ;) ;D ), has earned me a modicum of respect at my place of work. It had to be self-taught as out home-grown courses are p1ss-poor.
Funny. I know this place works well at disseminating knowledge, but I don't tend to think it goes as far as others' workplaces. I'm not sure why that last connection doesn't happen - perhaps there are just too few people who could. But I should have seen it - especially as I'm trying to change direction from software to networking
Right, lets all fill our glasses and ......... well ....... get merry !! :drink: ;D ;D
Whoops. I took that bit too literally, and forgot to post this last night!
-
I'm not sure you should be converting from 68m to 680m.
My calculations have subsequently been revised to account for the twelfth dip that is present in gazaai's Hlog plot.
The two figures (corresponding to those above) are now seen to be 67.6 and 744 metres.
-
Here is the link to the alternative calculation method I mentioned in my earlier post:
http://www.elnex.pl/product/attachment/d096f15ee037f5f693e1f7867366a54a/pl_PL/Analiza-petli-abonenckiej-SmartClass-TPS.pdf
The description is on the bottom of page 1, and top of page 2.
-
Here is the link to the alternative calculation method I mentioned . . .
Thank you. I shall read it with interest.
-
Here is a link to *another* document which mentions bridge taps, but this one has a couple of decent examples:
https://www.broadband-forum.org/technical/download/TR-197.pdf
This document is TR-197 from the Broadband Forum, discussing DSL quality factors. The relevant section is on "dual-ended line tests" that are performed in some DSL modems.
Figure 10, page 51, shows the Hlog for a line in 3 states:
- Perfectly normal
- With a 30m bridge tap, first dip somewhere around tone 520. We get to see one further dip.
- With a 200m bridge tap, first dip somewhere around tone 55. We get to see 13 further dips.
Sanity check of the previous formula:
- Tone 520 = 2.25MHz. Tap length = (160 ÷ 2.25) ft = 71 ft = 22m.
- Tone 55 = 0.24MHz. Tap length = (160 ÷ 0.24) ft = 667 ft = 203m
The sanity check isn't far off, telling us the formula is a reasonable estimate. In that case, we just measure the first dip, and ignore all the rest.
With gazaai's first dip occuring at tone 164, I calculate:
- Tone 164 = 0.71MHz. Tap length = (160 ÷ 0.71) ft = 225 ft = 69m
I think that gives us the answer for the total tap length.
That backs up (nearly) just reading data from table 2 (in the original JDSU document) as the only step needed. I don't think you need to perform averages over the extra dips (except for the fact it might give you a better accuracy for where the first dip really was), nor to multiply by the number of visible dips (after all, in reality, those dips go on ad-infinitum).
I also think I know how to read the example in that 1st document better now ... but I'll have to do that in a separate post, likely tomorrow.
-
Having carefully re-read the original document (http://www.viavisolutions.com/sites/default/files/technical-library-files/sctpsbridgedtap_an_tfs_tm_ae.pdf), and with some help from WWWombat, I now can see that I was caterwauling nonsense. :-[
The first table shown in Reply #16 (http://forum.kitz.co.uk/index.php/topic,16536.msg305925.html#msg305925) is good. The nonsense follows on from that table.
I now present my correction by beginning with a reworking of the original good table --
Index Tones at Minima Use as Midpoint Delta from No. of Intervening
----- --------------- --------------- Index 1 Minima from Index 1
---------- -------------------
1 160 - 167 163.5 0 -
2 496 - 503 499.5 336 0
3 832 - 839 835.5 672 1
4 1144 - 1151 1147.5 984 2
5 1512 - 1519 1515.5 1352 3
6 1848 - 1855 1851.5 1688 4
7 2192 - 2207 2199.5 2036 5
8 2528 - 2535 2531.5 2368 6
9 2864 - 2887 2873.5 2710 7
10 3208 - 3215 3211.5 3048 8
11 3552 - 3567 3559.5 3396 9
12 3936 - 3943 3939.5 3776 10
We should now look at columns four and five of the above table and cross-reference the second, third and fourth entries with Table 2 (of the PDF document (http://www.viavisolutions.com/sites/default/files/technical-library-files/sctpsbridgedtap_an_tfs_tm_ae.pdf), as referenced in my initial post).
By simple algebra, we can see that the second, third and fourth entries of columns four and five of my table, immediately above, give values of 69.0 metres, 69.1 metres and 70.7 metres for the length of the bridging tap.
Taking the average of those three values gives 69.6 metres as the approximate length.
We are now left with just one unknown: the location of the start of the bridging tap with reference to a known point in the circuit. That can be determined by TDR measurements from the NTE5/A looking towards the PCP and also from the PCP looking towards the NTE5/A, as it is highly likely that the tap is somewhere within the D-side. (b*cat nods towards B*Sheep. ;) )
Team-work prevails, once again. :)
So that all the information is contained within one place, I attach two extracts, below, from the Broadband Forum's document TR-197 (https://www.broadband-forum.org/technical/download/TR-197.pdf) that WWWombat referenced in his preceding post.
-
Small update on this. An engineer was out on 31st of December, I told him about a possible bridge tap issue and showed him a few graphs etc. He told me he wasn't interested and looked straight into the wiring. He seemed pretty annoyed that I called an engineer out when I am receiving 65mb and wasn't in the best of mood to begin with lol.
He had a look at the line with his device and done several tests. On one test he told me there is some sort of issue with the line outside my house around 70 metres away. When I looked at the screen it seemed to be a small graph with a straight line then a spike in the centre, I didn't get a good enough look. So I don't know what this test actually shows.
He was surprised at the length of span between my house and the pole, with a guess I would say around 50 metres to 60 metres going by several houses and at one point it dips so low the neighbour can almost touch it while outside his back door.
Well he then went on to say it was too dark to do anything else at the time, it was 5pm and pitch black. So he said he would leave the case open and another engineer would come out possibly on the 2nd or 3rd to have a look at the cable. I'm not to sure what to think as on the BT Faults page it says my fault should be fixed and I haven't received any texts or calls from Openreach so I am wondering if the case has been closed.
Ill update further on this if an engineer comes out again.
-
Hmm . . . Interesting. :-\
Please do keep us updated.
-
I got in contact with the engineer again over the phone. He says it’s been cleared on his notes and the fault has been proven to be outside. He said there is no need for another engineer to come out to my home. He says an engineer will come out and fix the fault outside themselves. Does anyone have past experience with this as it will be 1 week tomorrow with nothing being done?
-
He says an engineer will come out and fix the fault outside themselves. Does anyone have past experience with this as it will be 1 week tomorrow with nothing being done?
You have to see this as good result a fault has been found on your circuit so it needs more man power to fix this dropwire issue if it is as low as you say then either a second distribution pole will need to be erected to combat the effects of gravity on the dropwire joints.
Though my dropwire cable is 41 meters in length so it's not that bad if i was an OR engineer i would go to the tension bar at the house and make adjustments until the dropwire is higher up in the air
-
For info: 68mtrs is the maximum span between poles, or pole to house, on non-aerial cable. The 'spike' he could see is most likely a HR fault.
Without pictures and true distances, the rest is guesswork. :)
-
. . . a second distribution pole will need to be erected . . .
[Terminology / Jargon}: The second pole in such a situation would be called a "carrier pole".
Our very own Bald Eagle1's aerial service feed begins at a pole-top DP on the far side of a major road. It crosses the road to a carrier pole (thus maintaining adequate clearance above the road's surface) and then drops down to the side of the building. :)
-
For info: 68mtrs is the maximum span between poles, or pole to house, on non-aerial cable.
Thank you. I knew that there is a defined maximum span length but I could not recall the actual value.
-
Well guys its been fixed :D and the issue was pretty simple yet out of my control. It turns out that the two pairs were joined together at the pole. Orange and white connected together with the green and black. The engineer said he hasn't seen that before.
Well you can see my before and after on MyDSLWebStats, username: GaZaai.
Thanks for your help :)
-
Result. :) :)
I have to say though, I'm incredibly impressed with W3 and B*Cats scientific approach and calculating the length of the bridged-tap .............. absolutely spot-on at 69/70mtrs from the NTE. :graduate:
-
Yeah that was great work, it was excellent help. Here is some before and after shots:
Attenuation:
(https://i.gyazo.com/0693a52a898a586f976a8f7fb1cdf5e6.png)
HLog:
(https://i.gyazo.com/e8c705ea80405977d1d8eca717cbe75b.png)
Sync Rate:
(https://i.gyazo.com/017a10bebde9bec785ac7c100a1dd4f1.png)
-
I'm really pleased to know of the successful result. :)
Many thanks are due to WWWombat for examining my initial attempt at the calculation and then pointing out my error, caused by my speed-reading of a document.
I must just clarify one point for B*Sheep -- the calculation provided an approximate length of the bridging tap (between 69.0 & 70.7 metres) and not the starting point of the tap with reference to a known location within the circuit. It just so happened that the cause of the tap, in this particular case, was also located (by virtue of the actual wiring mistake) at the tap's length from the NTE5/A.
b*cat goes to look at gazaai's Hlog plot, with the aid of MDWS.
-
He was surprised at the length of span between my house and the pole, with a guess I would say around 50 metres to 60 metres going by several houses and at one point it dips so low the neighbour can almost touch it while outside his back door.
As soon as I saw this bit of information, my immediate guess was that your problem was caused by including the second pair in the circuit - it just smacks of too much coincidence. And even though I was right, this time it was just a lucky guess, rather than an educated one.
I hadn't expected the improvement in attenuation. That helps some too.
Working out the tap length was 1 part applying a simple engineering rule to the Hlog graph, but 9 parts working out which rule to apply. I'm glad we worked out the right one :graduate:
What impressed me more was that you managed to get an engineer booked in the first place - and that the external engineer followed-up from the first grumpy one. Did they end up charging you for the visit? Or even threaten to in the first place? I know you were happy to pay if that is what it took.
After seeing the response you got on BT's forum, I hope you went back and told them that your suspicions were absolutely spot on. Mind you, they'd probably just turn on you because it "only" gained you around 3Mbps in each direction.
-
Yeah it would have been a good idea for me to check for dial tone on that second circuit and I would have found out what was wrong instantly, but oh well.
I was able to get an engineer out by telling them there was crackling on the phone, even though there was no crackles lol. It was around 3 weeks of phone calls with the broadband team and they would not send an engineer out, they just kept sending me replacement home hub 5s even though I said I did not want them. So in the end I just phoned the fault team saying the phone calls were crackling. And an engineer came out a few days later.
Once the first engineer arrived I could tell he was annoyed because there was nothing really wrong with my line and my speeds were 65mb, so I thought I would have gotten charged. Until he noticed the spike on the line graph, and instantly put the master socket back together and said he would get another engineer out in a few days.
The Second engineer arrived around 5 days later at around 8.30am with no phone call so was unexpected. He came inside done the line check like the first guy, seen the spike in the graph. Stuck an oscillator 87J on the line and went to pole. He disappeared for around an hour, came back and told me there was two faults on my circuit. One that affected my speed and one that did not. He told me there was the issue with the bridge tap at the pole with both pairs connected together, and another issue he couldn't explain that was from the exchange to my pair in the cabinet that is used for ADSL services. He plugged it all back in and left, there was no mention of a charge so I don't think ill have to pay a penny :)
-
. . . told me there was two faults on my circuit. One that affected my speed and one that did not. He told me there was the issue with the bridge tap at the pole with both pairs connected together, and another issue he couldn't explain that was from the exchange to my pair in the cabinet that is used for ADSL services.
Two physical faults were found and then corrected. Therefore Openreach should not invoice your CP/ISP and, in turn, your CP/ISP should not invoice you. If there is any attempt by your CP/ISP to charge you for the visits, reject it. Likewise your CP/ISP should reject any attempt by Openreach to charge them.