Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: eliw on May 15, 2012, 04:43:04 PM
-
Had my FTTC installed 12 days ago - the sync speeds have been disappointing since day one - but to add insult to injury the DLM rerated me down about 10mbits (from 58mbits down to 48mbits) for a reason that escapes me since the modem has been in synch for 12 solid days without a single dropout.
First let me explain that I think there is an issue with my line - 2 years ago, after some heavy snowfalls, we had to have our line replaced because a tree branch fell on it and snapped the cable... we were then on BE ADSL - before the line change our sync was roughly around 22mbit/s on Annex M or around 23mbit/s on annex A, after the line was changed this dropped to around 18 mbit/s on annex M and around 19 mbit/s on annex A - I remember the engineer who replaced the line struggling for a good hour or so after he connected the new cable to get a dial tone... anyway despite the drop in download sync I didnt bother do anything and the connection stayed like that ever since... rock solid connection on 3db not a single resynch in years albeit with a couple of mbits less.
Anyway now that I upgraded to FTTC I believe that fatal line change is affecting my line more than it did on ADSL - BT estimate that my line capable of 55 down and 13 up (as you know this is always conservative) but I am synching at 58 / 8 - I am only around 300 meters from the cabinet and I reckon I should get more - the annoying thing is that I am paying the full wack for this line (business + multiple IPs) and what's more anoying is that the DLM thing has decided to drop me down to 48mbit/s despite no reconnections whatsoever. The pings are also not superb.. ping to my direct BT side gateway (217.32.147.7) is around 16ms when in all fairness it should average the 5ms levels (I attached below a traceroute to the BBC as well).
I will be ever so greatful to anyone here who could explain to me the best course of action to have my line tested (full tests) to determine if there is a fault that is causing these abnormally low figures especially on the upload side when considering that I am no more than 300m from the cabinet.
Please have a look at my stats below from the hacked HG612 modem :
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 8836 Kbps, Downstream rate = 58488 Kbps
Path: 0, Upstream rate = 8869 Kbps, Downstream rate = 48677 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 8836 kbps 58488 kbps
Actual Aggregate Tx Power: 3.8 dBm 12.3 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 6.9 35.9 53.6 N/A 17.1 44.7 66.2
Signal Attenuation(dB): 10.3 35.1 51.4 N/A 17.1 44.7 N/A
SNR Margin(dB): 6.2 6.1 6.1 N/A 6.4 6.7 N/A
TX Power(dBm): -4.3 -7.1 2.5 N/A 10.5 7.6 N/A
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 8847 Kbps, Downstream rate = 58488 Kbps
Path: 0, Upstream rate = 8869 Kbps, Downstream rate = 48677 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.6 6.1
Attn(dB): 0.0 0.0
Pwr(dBm): 12.3 3.8
VDSL2 framing
Path 0
B: 34 237
M: 1 1
T: 64 38
R: 8 16
S: 0.0229 0.8523
L: 15036 2384
D: 1427 1
I: 43 127
N: 43 254
Counters
Path 0
OHF: 21770716 1785459
OHFErr: 112 27
RS: 4065084502 1903483
RSCorr: 244508 55
RSUnCorr: 10130 0
Path 0
HEC: 1756 0
OCD: 0 0
LCD: 0 0
Total Cells: 198558905 0
Data Cells: 123318744 0
Drop Cells: 0
Bit Errors: 0 0
ES: 12 27
SES: 0 0
UAS: 15 15
AS: 48005
Path 0
INP: 3.00 0.00
PER: 2.19 8.09
delay: 8.00 0.00
OR: 87.41 31.61
Bitswap: 8325 358
Tracing route to bbc.co.uk [212.58.241.131]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 13 ms 13 ms 16 ms 217.32.147.7
3 16 ms 15 ms 15 ms 217.32.147.46
4 17 ms 16 ms 16 ms 213.120.177.74
5 16 ms 16 ms 16 ms 217.41.168.213
6 17 ms 17 ms 17 ms 217.41.168.109
7 16 ms 16 ms 17 ms acc2-10GigE-0-0-0-5.l-far.21cn-ipp.bt.net [109.159.249.206]
8 23 ms 23 ms 23 ms core2-te0-15-0-5.faraday.ukcore.bt.net [109.159.249.155]
9 19 ms 19 ms 19 ms 213.131.193.78
10 17 ms 18 ms 18 ms peer2-xe9-1-0.telehouse.ukcore.bt.net [109.159.254.114]
11 18 ms 18 ms 18 ms 194.74.65.42
12 * * * Request timed out.
13 18 ms 18 ms 18 ms ae1.er01.rbsov.bbc.co.uk [132.185.254.46]
14 17 ms 18 ms 18 ms 132.185.255.134
15 18 ms 17 ms 18 ms 212.58.241.131
Trace complete.
Thanks for reading.
E
-
Hi eliw & welcome to the Kitz forum.
This shouldn't take long to sort out ;) :lol:.
I first reported my FTTC issues last July after a solid month's connection & am currently awaiting confirmation of yet another engineer's visit.
Firstly, for only 300m from the cabinet, your DS Attainable Rates of only 58488k & US of only 8836k look abysmal.
Are you 100% sure you are connected to the cab at 300m distance?
Some users have found they are not actually connected to the nearest cab at all.
Also, your attenuation looks too high to even achieve anything from the higher frequency band plan.
It is discovered, but not actually in use:-
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) - only the lower frequency tones in use.
This suggests to me a major physical line problem, or that your line really is a lot more than 300m in total length.
EDIT:
DLM can completely knacker up your sync speeds, but should NOT really affect your attainable rates at all
-
I live in a small town - the only cabinets are clearly out there on the one and only main road in the area - the closest one is at about 300m and some other ones are along the road, one at roughly 500m and one about the same distance the other way..
Is there anything I can do to find out to which cab im connected to, and what the actual line length is ?
How do I go about getting an engineer round ? I am just worried that BT will give me an answer along the lines of "your performance is decent enough - we can't help you" - I have a business contract with BT with the "assured rate" service level - anyone have any number I should call to get to some decent CS team for this type of service level ?
Is 16ms to the first hop normal on FTTC ?
Thanks again for your help.
-
If you are willing to extend a degree of trust, please send me a PM with your postcode and your exchange code (there is no need form me to know your full telephone number). With that information, I will see what I can determine with respect to your PCP/FTTC cabinet number.
-
I am willing to extend everything - a degree of trust is certainly not an issue :)
PM sent
-
Looks quite similar to my aluminium D side line.
-
I am willing to extend everything - a degree of trust is certainly not an issue :)
PM sent
Thank you. :)
On searching the Postcode to PCP database, I have found the matching record and the relevant portion of the line reads --
{THC}{P51},0,100%,2.32,5a,Yes,FTTC
This tells us that your business line is connected via P51. So the next step would be to find its location . . . I tried with Google Maps Streetview but because of your location, the relevant section of P* Avenue was un-photographed.
I have found P27 at the junction of B*dale Road and N* Avenue, so that is an example of for what you should be looking. The only suggestion I can make is to have a walk around the area -- weather permitting -- keeping a look-out for P51. When you find it, the corresponding FTTC should be in close proximity.
With regards to support, are you with BT Retail for your telephone and broadband service? If so, there is a U.K. based customer support centre available to you. I think the number you need to call, for BT Infinity for Business support, is 0800 169 3809. There is also a URL for dedicated business support pages -- www.bt.com/business/help/fibre.
I hope the above will help. Please keep us updated with the progress.
-
Thank you.
I have seen P27 before and it does not have an FTTC cabinet near it... as for the cabinet that I suspect being the one I am connected to (with an FTTC cabinet near it) - it has no numbers on it at least on the front and the exposed side. May need to go and look at the other side or back (hopefully won't be suspected of vandalism).
There are a lot of cabinets here with SCC and a 4 digit number after that - similar to SCC1050 ect.. what are these for ? Virgin ?
-
as for the cabinet that I suspect being the one I am connected to (with an FTTC cabinet near it) - it has no numbers on it at least on the front and the exposed side. May need to go and look at the other side or back (hopefully won't be suspected of vandalism).
If anyone should question you, just say that the burakkucat told you to make a careful external examination! Also, if you can do so, a photograph of both cabinets and details of their location would be appreciated, please. (Feline curiosity, as I'm sure you've guessed.)
There are a lot of cabinets here with SCC and a 4 digit number after that - similar to SCC1050 ect.. what are these for ? Virgin ?
Yes, Virgin Media would the at the head of my list of suspects. ;) I wonder if Walter would care to comment, as we are discussing cabinets in a Guildford postcode area? :-\
-
Checked the cabinet that I thought was ours and it is indeed ours PCP51, so good news there as it is the closest one to us and is about 350 - 400 meters or so from us.
I called the BT business broadband help line (0800 169 3809) and explained the problem, they ran "tests" and checked my profile and as expected said that there was nothing wrong and that they can't help me despite me explaining that the cabinet (and even the exchange) arent far away from us .. she said the speed test is within their range..
What are my options now ? How can I get an engineer (who knows about brodband) to come check the line ?
I feel this is the beginning of a long battle :(
-
So there is some good and some not so good news.
I'm pleased to know that you have located the PCP/FTTC pair, designated as P5, which serves your business. Would you be willing to disclose their location, please? (Road name?)
At that sort of distance, a good line should be capable of achieving 39.9 Mbps DS when capped to 40/10 whilst on profile 17a. A montage of the line statistics (400 metres to the cabinets) is attached, below. I do not have any corresponding data for that line (my neighbour's) without the 40/10 cap . . .
As for long battles over poorly performing lines, I think Bald_Eagle1 will be your best advisor/confidant and as for poorly maintained BT infrastructure, Walter will always have something to type. ::)
-
I called the BT business broadband help line (0800 169 3809) and explained the problem, they ran "tests" and checked my profile and as expected said that there was nothing wrong and that they can't help me despite me explaining that the cabinet (and even the exchange) arent far away from us .. she said the speed test is within their range..
I have heard/read comments very similar to those a number of times :(
What are my options now ? How can I get an engineer (who knows about brodband) to come check the line ?
That's the hardest part.
The onus of proof that something is "wrong" appears to be on the end user.
That's not particularly easy when supplied with locked down equipment either.
However, where there is the will, there is usually a way ;)
If you have a strong enough will, we may be able to assist with the way.
I feel this is the beginning of a long battle :(
I suspect you may well be right there ::)
Firstly, to prove a fault(s), you need to record your connection stats, both as snapshots in time & as ongoing records that may highlight gradual/sudden changes, dropped connections, events at particular times of day or night etc. etc. etc.
MY connection has required that many engineer visits that I have genuinely lost count now.
However, each time, some "repair" work has been carried out & I haven't been charged a penny to date.
I am currently awaiting confirmation of the date of the next engineer's visit for which I again will not expect to be charged as I have undeniable proof of an intermittent fault that surfaces when using the phone during warm & dry weather.
The engineer's visit will be programmed according to weather forecasts, probably during next week.
If you are a Windows user, my scripts can be used for the above mentioned data collection & graphing.
I have also maintained an ongoing log of my IP Profiles from which the attached graph has been plotted (I am a few days behind with updating that log, but my other ongoing logs contain sufficient data to easily update it in a day or so).
Columns & columns & rows & rows of stats are required, but they do need to be graphed for the maximum effect that makes people take notice.
These various graphs have been the only evidence that has disproved my ISP's & BT's comments that my connection is performing within acceptable limits.
We'll be here for the long slog with you, if that's what it takes.
Good luck :)
-
What would be most useful is a TDR plot of the line. It doesn't have to be an Openreach engineer that obtains one but if one could be bribed (tea. coffee, biscuits [chocolate], bacon sandwiches, etc) to assist, that would be the simplest way.
Of those of us who do have the appropriate equipment Bald_Eagle1, Asbokid and myself all live too far away. The one other person, Surrey based, with a Guildford area postcode, capable of obtaining a TDR plot is Walter. Obviously he would need to consider the distance and whether it would be a viable day out. (Perhaps, as part of a day-trip out in the car for Mrs Walter, Walter could say "Oh look, were at X. I'm sure you won't mind me popping in to see Eli for half-an-hour, will you dearest?" :-X )
-
Thanks for that both of you.
I have the will it is just that my issue is not as clear cut as yours Baldeagle. There is a form on the BT site somewhere where you can request an engineer visit (chargeable at £99 if the fault is on your side or no fault) t but I would like to make sure that the guy they send has the right equipment/knowledge and most importantly the open mind to pursue a genuine investigation. The lad they sent to change our phone line last year gave the impression of someone who has never used the internet.
As for the information you requested Burakkucat, I went back to the cabinet and used my mobile GPS to measure the exact distance from there to the Master socket :) - and the distance is slightly longer than I expected (480m) ..
PCP 51 is at the corner of Park Road (main road) and Heatherdale Avenue. Streetview doesnt show the new cab yet even though it was installed around Jan 2011
Here is a pic of PCP 51:
(http://www.smalldrives.com/download/oldcab.jpg)
This is the FTTC Cab:
(http://www.smalldrives.com/download/newcab.jpg)
And here you can see them both:
(http://www.smalldrives.com/download/bothcabs.jpg)
(http://www.smalldrives.com/download/1.jpg)
Regards
E
-
It sounds like you've measured the loop length pretty precisely, to have arrived at a figure of 480 metres. If you're still doubtful, maybe you could double check the length using a map. Some local authorities grant online access to the Definitive Map for their administrative area. From what Walter has said, Surrey CC is one of those authorities. Otherwise, there is a Measuring Tool feature in Google Maps that can also be used. It has to be enabled first via Google Labs, though.
You've unlocked the Huawei, so maybe get the line performance stats out of it now, using Paul's (BaldEagle) scripts. These will allow you to study the line performance in the frequency domain. They may help you to identify the nature of the fault - assuming there is one.
cheers, a
-
PCP 51 is at the corner of Park Road (main road) and Heatherdale Avenue.
That satisfies the inquisitive cat. Thank you.
There is one option you could consider. Downgrade your package to 40/10. You would be paying out less per month and would probably obtain a throughput of 38/9 Mbps DS/US.
As you say in the subject header: "possible line fault". So far, you have not presented any concrete evidence -- only anecdotal memories. However, with a D-side pair length in the order of 450 - 500 metres, I would expect you achieve a better throughput than current. Hence I will agree that there may be a possibility to improve the pair's characteristics. :(
-
I've just read this news item (http://www.thinkbroadband.com/news/5241-openreach-fibre-to-the-premises-80-meg-service-special-offer.html) at ThinkBroadBand concerning the Openreach special offer of 80/20 FTTP being available in FTTC enabled areas.
My understanding is that a fibre is run from a fibre-splitter at the FTTC to the user's premises, thus doing away with the VDSL2 copper pair.
As a business user, perhaps that option may be worth considering? (If available in your area.)
-
That would be brilliant !
How can I find out if this available here ? The checker does not mention fttp at all.
Wouldn't that involve running a fiber line all the way up to us, thus digging up the road for just one customer ?
-
The best way would be to register your interest in the "on demand FTTP product, in FTTC enabled areas" (which is how, I believe, it is currently known within the BT Group).
As for physically getting the fibre feed to the premises, there are three main ways. Using existing underground ducting. Microtrenching a new underground feed. Using existing poles for an aerial feed. Every location will be different and the technique used would depend upon a site survey.
-
Btw I have decided to log a phone line fault on the BT site - not expecting much, I was very suprised to see a fault job number appear once I pressed "check my line" - I proceeded to check the progress of the fault on the site, the following messages are now displayed (I have since then received an SMS stating the date of the engineer visit to the exchange/cabinet and that it may require a visit to my property as well)
(http://www.smalldrives.com/download/fault.jpg)
Is this encouraging ? or is it just standard procedure ?
-
Well not having actually been an employee of the BT Group nor a Business customer of BT Retail, I would be somewhat encouraged by that. At least you do have a job reference number linked to your line and, if needs be, you can use that reference number to haunt the "Evil Empire of Newgate Street". :D
Perhaps Bald_Eagle1 will be able to advise you of the information that would be helpful to present to the attending engineer . . . :-\
-
Perhaps Bald_Eagle1 will be able to advise you of the information that would be helpful to present to the attending engineer . . . :-\
If you have been saving any terminal data logs, we might be able to put together a series of graphs that MAY highlight changes in conditions such as attenuation (Hlog), SNR, QLN, bit-loading.
Also, If you had enabled it via Maintenance, Log, Displaying Log, you might be able to report all the re-syncs that are probably NOT shown in any ISP logs:-
2012-3-25 9:31:7 Notice 104500 DSL activate succeed
2012-3-25 9:30:45 Notice 104500 DSL deactivate
2012-3-25 9:30:7 Notice 104500 DSL activate succeed
2012-3-25 9:29:11 Notice 104500 DSL deactivate
2012-3-25 9:27:9 Notice 104500 DSL activate succeed
2012-3-25 9:26:47 Notice 104500 DSL deactivate
2012-3-25 9:24:28 Notice 104500 DSL activate succeed
2012-3-25 9:24:12 Notice 104500 DSL deactivate
The best option is to use a combination of "snapshot" graphs & the 24/7 logging graphs as any changes can be seen graphically.
Engineers aren't allowed much time for each job so they wouldn't spend time looking at tables of data, but a picture is worth thousands of words/rows of data.
I would ask to see BT's Network Records that may identify sections of aluminium and the actual route to the actual cabinet.
It waould also be good to ask the engineer for the line length as reported from his JDSU or Exfo tester.
If it is reported as a lot more than the physical length, that would indicate "too much" attenuation.
Finally, depending on the type of engineer, it would be worth asking for a TDR test that should identify issues such as high resistance, tapped bridges, open circuit joints etc.
If this ends up being the first of a number of visits, you could always prepare "evidence" for the next visit.
Without "evidence" it may be difficult to force any furher action if nothing is found at the first visit.
EDIT:
My attached example graph set of a 30 day window is the only sort of hard evidence that is keeping my ISP in the loop after 10 months of ongoing intermittent issues.
I really have lost count of the number of times I have been told LTOK & "operating within acceptable limits".
I do have to thank Plusnet for not giving up on this.
It is just frustrating that it is impossible to get an engineer on site just when the "issues" are at their worst.
BTW, I have not been charged for any of the numerous engineer visits.
Let's hope that your issue can be clearly identified & rectified at the first visit.
From what you have reported here, it would appear that if there is indeed a "fixable" issue, evidence of it is present 24/7.
-
Thank you BaldEagle.
I don't suffer from any resyncs at all - in fact in the first 12 days (the modem was left on and untouched) there was not a single resync - and the Profile was pretty much at the top of the sync speed. It is when the IP profile was lowered that I started to get a bit inquisitive.
I have enabled the log feature on the modem (debugging mode) from day one and the only resyncs so far are when I rebooted it manually.
My only complaint is the fact that my sync speeds are low: 54 DS and 7 US, and maybe that my download profile is 10mbs lower than the sync speed which effectively gives me an up to 40 FTTC service for the price of the up to 80 service. The upload speed on my line, should be around 14mbs. All this of course considering that my line is less than 500 meters long.
-
. . . my line is less than 500 meters long.
Knowing both locations, I asked Google Maps to give me an estimate of the distance involved. Its response was ~0.4 mile.
-
I used a GPS plotter using my mobile phone (android app) while walking up the road from the PCP to my house. The distance was exactly 483m, you can't get more accurate than that. You basically press start measuring at the origin (the PCP) and then press end at the destination (my house) and you get the exact distance you walked +/- 10m for GPS approximation :)
... Maybe you are using the middle of the road. I'm at the closest end. Google maps showing 0.3mile for me.
-
... Maybe you are using the middle of the road. I'm at the closest end.
Indeed, I was. I just used the location Google Maps put the marker for the "GUnn nxyz" postcode. ;)
Now based on your very accurate measurement, one needs to add on a few metres for every underground joint chamber through which the pair passes and also if the line is finally delivered from an overhead DP, extra distance should be added for the climb "up the pole".
So perhaps we should say the pair length ~= 483 + 10 + (n x 2.5) + (p x 11) metres. [Where "n" is the number of joint chambers along the route and "p" is the number of poles involved.]
It would be very interesting to know what the pair length is determined to be when measured electrically with a JDSU, EXFO, Hawk or Mole and how it compares to the estimate, above. :)
-
Yes indeed - really curious to find that out as well.
I recall calling a a special BT number (17070 ?) a few years back and it returned the length of the line (to the exchange) - does that number not apply to FTTC lines ? (oops just tried and it asked me for some authorisation number)
-
As you have discovered, the menu for the "magic" number (17070) has now been changed. The only option now open to normal mortals is number two, the Quiet Line Test.
Apparently the system was being heavily abused by certain sections of the public . . . The fools spoilt things for the considerate, occasional, users. >:(
I have re-measured the approximate route (Google Maps) using the latest information you have provided and it now reports 0.3 mile / 480 metres. Looking somewhat more closely at your end of the D-side cable, I see it travels up a pole on the north side of the road junction to reach the pole at the end of your road. So we definitely need to add about 11 metres . . . If you look at the pole on the north side of the junction, you should see the height cut into the wood. I will expect it to be 10, 11 or 12 metres. You will also need to walk the route and make a count of the joint chambers. as I can't do that from Street View. :no:
I suspect the grand total will be around 550 metres. :-\
-
Ok had a visit from the engineer today (Sunday) - out of the blue... I was suffering from a major hangover but still managed to show a little bit of cognitive attributes..
Anyway he was here in his telephony guise and as such was not gonna help me at all with the broadband side of things, but said that he did some broadband installs around here and he had certainly seen much higher DS/US from people with longer lines than mine, at which point I asked him if he could check what my line length was, but unfortunaly said he could not... :(
He described the fault as generated by the online fault system as being a "a battery" on the line.. around 15V, so he went out to the pole just outside our house and started digging hammering and doing all sorts of noisy things... during all this time our line was down. It took him a good hour or so of intensive labour after which he walked back in and said that the fault was a lot more than the battery thing, he said he found the "joint" drenched in a pool of water so he replaced it (I think) and also put a new thing along the pole, some sort of a long black plastic box about 10 inches from the ground which looks a lot like an all weather junction box.
He then left to reconnect the line at the exchange (or the PCP) and came back within 10 minutes to test the line - first thing he said was that the line was perfect now as the resistances were equal on both wires, then he used a gizmo which he hooked up to the socket but unfortunately he could not run the tests as they were all coming back as failures despite him being sure that nothing was wrong anymore !? he insisted that his machine was knackered and that we could safely ignore it... he then left after telling me that I should get in touch with BT retail again and ask them to send a broadband boost engineer now that the line according to him was ok.
I reconnected the modem and the stats were still as before - no difference whatsoever. But just checked now a good 10 hours after the guy left and the attainable rate on the upload side has gone up by a good 1.2 megs (never moved from 8800 before today) but download attainable seems to have dropped by 1.5 megs tho lol
Now I am confused :)
Here are the new stats to compare with the ones I posted in my original message.
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 10450 Kbps, Downstream rate = 57032 Kbps
Path: 0, Upstream rate = 10000 Kbps, Downstream rate = 48007 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 6.6
Attn(dB): 0.0 0.0
Pwr(dBm): 12.1 5.0
VDSL2 framing
Path 0
B: 34 118
M: 1 2
T: 64 48
R: 8 16
S: 0.0232 0.7545
L: 14829 2693
D: 1407 1
I: 43 127
N: 43 254
Counters
Path 0
OHF: 108880 26880
OHFErr: 0 0
RS: 41907013 1289653
RSCorr: 188 0
RSUnCorr: 0 0
Path 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 22525411 0
Data Cells: 1136910 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 15 15
AS: 245
Path 0
INP: 3.00 0.00
PER: 2.22 9.05
delay: 8.00 0.00
OR: 86.21 54.77
Bitswap: 70 23
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 10454 Kbps, Downstream rate = 56900 Kbps
Path: 0, Upstream rate = 10000 Kbps, Downstream rate = 48007 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 10454 kbps 56900 kbps
Actual Aggregate Tx Power: 5.0 dBm 12.1 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 6.9 35.9 54.0 N/A 17.1 44.6 66.2
Signal Attenuation(dB): 8.9 35.2 51.8 N/A 17.1 44.6 N/A
SNR Margin(dB): 6.7 6.6 6.5 N/A 6.3 6.2 N/A
TX Power(dBm): -4.0 -6.9 4.1 N/A 10.2 7.8 N/A
-
Ok had a visit from the engineer today (Sunday) - out of the blue... I was suffering from a major hangover but still managed to show a little bit of cognitive attributes..
Anyway he was here in his telephony guise and as such was not gonna help me at all with the broadband side of things, but said that he did some broadband installs around here and he had certainly seen much higher DS/US from people with longer lines than mine, at which point I asked him if he could check what my line length was, but unfortunaly said he could not... :(
He described the fault as generated by the online fault system as being a "a battery" on the line.. around 15V, so he went out to the pole just outside our house and started digging hammering and doing all sorts of noisy things... during all this time our line was down. It took him a good hour or so of intensive labour after which he walked back in and said that the fault was a lot more than the battery thing, he said he found the "joint" drenched in a pool of water so he replaced it (I think) and also put a new thing along the pole, some sort of a long black plastic box about 10 inches from the ground which looks a lot like an all weather junction box.
He then left to reconnect the line at the exchange (or the PCP) and came back within 10 minutes to test the line - first thing he said was that the line was perfect now as the resistances were equal on both wires, then he used a gizmo which he hooked up to the socket but unfortunately he could not run the tests as they were all coming back as failures despite him being sure that nothing was wrong anymore !? he insisted that his machine was knackered and that we could safely ignore it... he then left after telling me that I should get in touch with BT retail again and ask them to send a broadband boost engineer now that the line according to him was ok.
I reconnected the modem and the stats were still as before - no difference whatsoever. But just checked now a good 10 hours after the guy left and the attainable rate on the upload side has gone up by a good 1.2 megs (never moved from 8800 before today) but download attainable seems to have dropped by 1.5 megs tho lol
Now I am confused :)
Here are the new stats to compare with the ones I posted in my original message.
New pbParams:-
Max: Upstream rate = 10454 Kbps, Downstream rate = 56900 Kbps
Path: 0, Upstream rate = 10000 Kbps, Downstream rate = 48007 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 10454 kbps 56900 kbps
Actual Aggregate Tx Power: 5.0 dBm 12.1 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 6.9 35.9 54.0 N/A 17.1 44.6 66.2
Signal Attenuation(dB): 8.9 35.2 51.8 N/A 17.1 44.6 N/A
SNR Margin(dB): 6.7 6.6 6.5 N/A 6.3 6.2 N/A
TX Power(dBm): -4.0 -6.9 4.1 N/A 10.2 7.8 N/A
I see there is a little improvement on signal attenuation across upstream band U0. Hence the higher US sync speed.
It looks like you are now in sync at the capped 10Mb upstream.
Nothing else stands out as having improved any.
Downstream Attenuation still looks "fairly" high for a line of relatively short length.
Also Downstream SNRM has no real "spare" capacity obove the target 6dB, so it looks like your connection is currently achieving more or less the maximum for the current physical line conditions.
This all suggests that there is possibly some high resistance, causing higher than "normal" attenuation levels.
Or, the line could actually take a longer route than both you & the engineer perceive at this stage.
Did the engineer mention aluminium cabling at all?
Finally, I suppose you could have a connection that is affected by noise interference, either permanently or in bursts of interference.
Maybe DLM has seen this & lowered your achievable sync speed profile (not IP Profile) to compensate.
Previous pbParams:-
Max: Upstream rate = 8836 Kbps, Downstream rate = 58488 Kbps
Path: 0, Upstream rate = 8869 Kbps, Downstream rate = 48677 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 8836 kbps 58488 kbps
Actual Aggregate Tx Power: 3.8 dBm 12.3 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 6.9 35.9 53.6 N/A 17.1 44.7 66.2
Signal Attenuation(dB): 10.3 35.1 51.4 N/A 17.1 44.7 N/A
SNR Margin(dB): 6.2 6.1 6.1 N/A 6.4 6.7 N/A
TX Power(dBm): -4.3 -7.1 2.5 N/A 10.5 7.6 N/A
If you could combine these into a single output file, or at a pinch into separate files, we could graph a snapshot of your connection that might give us all a clearer insight to its condition & comparison against other users' connections:-
xdslcmd info --pbParams
xdslcmd info --Bits
xdslcmd info --linediag
xdslcmd info --show
xdslcmd info --stats
The file(s) would be too large to upload to kitz unless you zipped it/them down to a smaller compressed size.
Just for future reference against a not so good connection, I have attached my graphs from when I rebooted the modem a few days ago.
-
Further to Bald_Eagle1's analysis, I would suggest that you access the on-line fault service and let it re-check your line.
If that automatic test then returns a LTOK (which it should, if the network [POTS] engineer has done a good job), I would urge you to do as he suggested and request a visit from a Broadband Boost Engineer.
That engineer will perform various tests and make any relevant optimisations. The last thing s/he should do would be to make a call to the appropriate department to have your line's profile reset. As for the latter, Baldy_bird can tell you all about it -- having had previous experience of profile resets of the line into "The Aerie". ;)
-
Just to add my two cents FWIW.
I had a visit recently from a very helpful OR broadband engineer who diagnosed my issue as aluminium cabling - sync speed was down from 35+ to 25. On making the aforementioned call my line magically jumped back to 35meg sync for 30 minutes or so as the engineer did some more tests. The 'helpful' BTOR helpdesk that he was on the phone to, then decided that they would re-instate the DLM cap as 'this is all the line can handle'......Err, no, its just been running at 35meg so clearly it can !!
OR fed this back to my ISP (talktalk) who responded saying the sync was still too low, please reset the line. OR engineer turns up following day to see if its worked. No, it hasn't so he goes off to the cab and doesn't return. Two hours later, the line drops and comes back at the full 40Mbps (40/2 line). After a couple of days I decided that the throughput was a little (actually a lot) low because of errors as interleaving was off. Dropped my line a couple of times on purpose to get DLM interested. Its now synced at 37660, which is faster than the original install and appears to be stable, at least so far.
So, its well worth following b*cat's advice, especially if you have your ISP on side.
-
Dropped my line a couple of times on purpose to get DLM interested. Its now synced at 37660, which is faster than the original install and appears to be stable, at least so far.
Just curious; did that turn interleaving, INP and delay on?
Also, are you able to post your continuous stats from before, during & after?
Either the graphs or the log files will do for me.
-
Just curious; did that turn interleaving, INP and delay on?
Also, are you able to post your continuous stats from before, during & after?
Either the graphs or the log files will do for me.
Interleaving definitely, but I knew I needed it on, so that was fine. Pings rose from 24ms to 30ms to bbc.co.uk. T'others I'm not sure :-[
Have attached some stuff for your perusal Paul.
-
Let's hope you are able to maintain the speed of around 38Mb.
It looks like no physical works have been carried out as apart from SNRM levels lowering with the higher speeds, not much else looks to have changed in pbParams.
I'm sure you will keep us posted regarding your connection's stability over the next few weeks or so.
I for one will be very interested to see how it all pans out, as I'm sure, so will eliw.
-
Here are my stats :) - please tell me what you make of them. Notice that SNRM has been steadily dropping since yesterday to around 5.4 today (from around 6.6) and in the process shaving another meg or so from my DS attainable.
Btw the scripts did not work until I replaced the IP address of the router on the batch files from the default to whatever I have..(I changed mine cause I needed to keep it on the network at all times)
I have also managed to bribe BT to send us a Fibre Engineer (will be here this wednesday morning) - If you can give me a bullet of points about the tests and checks he should do, I will write them down and present them to him when he arrives :D
-
Here are my stats :) - please tell me what you make of them. Notice that SNRM has been steadily dropping since yesterday to around 5.4 today (from around 6.6) and in the process shaving another meg or so from my DS attainable.
Well, the shape of the graphs is roughly in line with what I would expect from your previously posted pbParams values.
I'd be happy with 5.4dB SNRM. Mine's currently at only 2.3dB & I wouldn't be at all surprised if my connection re-synced overnight, at a much lower speed.
Earlier, I think you mentioned the appearance of the QLN graph.
If you were referring to all the red areas, that's how we first plotted QLN (& Hlog).
The attached GRAPH6.BAT is the current version (not uploaded to the public download site yet).
You could replace the existing version of GRAPH6.BAT with the new version & either re-run TestStats2.BAT to generate a new graph set, or drag the Plink log from your original graphs & drop it onto the new GRAPH6.BAT to generate graphs with the same appearance as my attached set.
The new graphs will be generated in the same folder as the Plink log, so would overwrite the existing graphs (unless you saved a copy of the Plink log into a different folder & dragged & dropped it from there).
Btw the scripts did not work until I replaced the IP address of the router on the batch files from the default to whatever I have..(I changed mine cause I needed to keep it on the network at all times)
The batch files use the modem's default address of 192.168.1.1 which works well with my network. My router is 192.168.1.254 & any other dynamically allocated devices fit nicely between the wide address range.
Quite a few users change the modem's default IP address & others change the router's IP address.
Same thing done differently I suppose.
I have also managed to bribe BT to send us a Fibre Engineer (will be here this wednesday morning) - If you can give me a bullet of points about the tests and checks he should do, I will write them down and present them to him when he arrives :D
He/she should carry out all the standard tests as a matter of course (Pair Quality Test, Eclipse Test etc.).
If at all possible, try convincing the engineer to run a TDR test.
This could/should highlight any sections of cable between you and the cabinet that have issues such as High Resistance, Open Circuit, Bridged taps etc. All of which could/would have a negative effect upon your attenuation levels & therefore sync speeds.
Bit-loading tends to tail off when attenuation over frequency from the Hlog graph gets to around -70dB or so.
I see that SOME of your third (highest frequency) DS band (D3) appears to possibly have capacity for SOME bit-loading & therefore speed.
I wonder if DLM has already capped your sync speed to counter any "noise" induced instability.
I see your Interleaving depth (D:) is fairly high, a value of 1 being OFF.
I imagine INP (Impulse Noise Protection) & delay could have reasonably high values too.
These can be found lower down the Plink.log in the "xdslcmd info --stats" section.
Various error counts & errored seconds can also have a part to play.
You would need to monitor these over a period of time.
Now you have the tools, you could do that if another engineer visit may be required in say a few weeks time.
Ultimately, it could just be that the condition & materials (possibly ally) of your D-side cabling cannot be economically improved, but your speeds do seem low(ish) for 550m or so from the cabinet.
The "special" broadband engineer should be able to at least tell you what his JDSU, EXFO or any other tester reports as the "electrically" measured line length.
These are early days & you may need to gather a lot more statistical history before trying to push things along (unless it gets sorted during Wednesday's visit).
The engineer should also be able to report the single attenuation values for upstream & downstream, unlike the split attenuation values as reported via the HG612 modem.
We have recently got quite close, but have not yet finalised a formula to convert the HG612's split attenuation values into corresponding single values.
This makes it quite difficult to easily guesstimate/calculate theoretical speeds for given line length/attenuation values.
Good luck :)
-
Thank you Sir.
I will do my best to get the TDR test done as I believe that is the key test for my particular case.
-
And here is a tip that Black Sheep (a serving Openreach engineer) recommends --
If there is a suspicious region of the TDR graph (when measuring from your end of the pair toward the FTTC DSLAM and, thus, the exchange battery), it is often helpful to call the line (from a mobile phone) whilst keeping careful watch on the TDR trace. The superimposition of the AC "ringing" voltage on top of the exchange battery's constant DC bias will often cause an "iffy" joint to become quite apparent. :)
-
And here is a tip that Black Sheep (a serving Openreach engineer) recommends --
If there is a suspicious region of the TDR graph (when measuring from your end of the pair toward the FTTC DSLAM and, thus, the exchange battery), it is often helpful to call the line (from a mobile phone) whilst keeping careful watch on the TDR trace. The superimposition of the AC "ringing" voltage on top of the exchange battery's constant DC bias will often cause an "iffy" joint to become quite apparent. :)
That is exactly what I hope Friday's engineer will do when he visits me (some engineers do appear to need prompting a little though).
FYI, my connection did re-sync at only 22677k, but not until 07:28 this morning.
SNRM started off at 8dB, went to 10.3dB, back down to 5.3dB & back up to 10.4dB within 15 minutes.
I am already late for a work appointment so unfortunately don't have time this morning to try my own TDR test.
I will do so tonight if the issue is still present though.
-
Bald_eagle
You say :
I wonder if DLM has already capped your sync speed to counter any "noise" induced instability.
I am a bit confused by this comment .. I thought DLM was only there to set a profile for your line and had nothing to do with Sync Speeds - which are fixed to the characteristics of your line at any moment in time - i.e sync speeds = attainable rates...
... and IP profile = line rate - which is obviously capped as it is at 46mbits as opposed to the sync speed which is 57mbits.
:-\
-
Bald_eagle
You say :
I wonder if DLM has already capped your sync speed to counter any "noise" induced instability.
I am a bit confused by this comment .. I thought DLM was only there to set a profile for your line and had nothing to do with Sync Speeds - which are fixed to the characteristics of your line at any moment in time - i.e sync speeds = attainable rates...
... and IP profile = line rate - which is obviously capped as it is at 46mbits as opposed to the sync speed which is 57mbits.
:-\
Attainable Rate as shown in the modem's GUI is also reported as Max in pbParams & other places.
This is the theoretical best rate that your connection could achieve based on current conditions.
Line Rate as shown in the modem's GUI is also reported as Path in pbParams.
This is the actual Sync speed.
IP Profile a.k.a. BRAS Rate (not reported anywhere by the modem) is always approximately 96.79% of sync speed for UK VDSL2 services.
When DLM encounters a "problematic" line, exhibiting a history of noise, high attenuation issues, high error rates etc. it takes action to provide stability in preference to speed.
DLM then sets a sync speed cap which is maintained until conditions improve for a sufficiently long enough period of stability combined with higher attainable rates for DLM to re-sync your connection at a higher speed (in theory).
In practice, we have seen DLM to be very intolerant of "problems" & quite aggressive & quick to take remedial action.
However, it can take many days or even weeks before DLM deigns to allow a higher speed.
Occasionally, DLM needs to be reset as it "sticks" at a permanently low speed.
My connection has required engineer initiated DLM resets when sync speeds have been "stuck" at values such as 24999k, 14999k, 12999k etc.
The engineer doesn't physically reset DLM, but requests the remote control centre to reset it back to a wide open profile.
The remote control centre agent once REFUSED to reset DLM as my connection was achieving 24999k & records confirmed it could not physically achieve any more than that!
This was despite the engineer having fixed a definite cabling problem & holding printouts in his hand of my speed tests (including BT's own test) where actual throughput speed was in excess of 32Mb.
I had weeks of battle to eventually get DLM reset following that refusal.
e.g. I have a problematic line. Hopefully Friday's engineer visit will fix it once & for all.
My line's problems have been intermittent which has made it difficult for emgineers to actually find the problem(s) & has a really negative effect upon DLM's decision making regarding my sync speeds.
My current Attainable Rate is 32896k. It has on occasions been higher than 36000k.
My current Sync speed is only 21167k following a re-sync caused by using the phone this morning.
Dialling in temporarily "fixes" the problem & currently I can use the phone again with no drops in SNRM, so I know a TDR test would NOT clearly identify the issue.
I also suspect that the electrical pulse from a TDR tester would also temporarily "fix" this particular fault, hence it never being picked up when engineers have run TDR tests.
I can & have run my own TDR tests & nothing obvious has been seen, even during aperiod of disconnections.
As soon as the modem is reconnected, the line remains stable for sometimes days at a time.
From my TRD traces, we do suspect an intermittently dodgy joint at the DP at the top of the pole across the road from my house.
The engineer Black Sheep has also confirmed the typical "unreliability" of this type of push fit connection, known as a coffin lid DP by engineers due to its coffin shape.
Apparently the connections need thicker wire to make a reliable connection.
His colleages crimp a short length of thicker guage cable to the thinner guage feed cable to ensure a snug fit.
I mentioned this to the latest visiting engineer, but his jumper recabling work inside the PCP genuinely appeared to have resolved all the issues, giving me one of the highest sync speeds I had seen for 8 months (following his requested DLM reset).
This unfortunately only lasted for a few days of stable, low error counts & higher speeds.
MY IP Profile/BRAS Rate is currently 20.49Mb (96.79% of Sync speed).
My SNRM is 11.8dB. Hence an Attainable Rate which is much higher than my sync speed.
No doubt a modem reboot would provide a higher sync speed, but too many reboots also has a negative effect upon DLM & I could end up with a stuck low sync profile & associated even lower IP Profile, despite having a high Attainable Rate.
Very occasionally, Attainable rates can be less than current sync speed. eg. the connection may have synced really close to its attainable rate when conditions were really good.
As conditions have gradually deteriorated, SNRM will have lowered, but not by enough to cause a re-sync & thus Attainable rate is less than sync speed.
Some users living close to the cabinet see Attainable Rates well above 100000k.
On a capped 40 Mb sync speed service their SNRM value is higher than 30dB.
When switching to the 80Mb service, Attainable rates stay roughly the same, but SNRM is reduced to much lower levels.
So, DLM actually sets the Sync rate, with everything else calculated from that.
The attached example is not the quietest line we have ever seen, but it is less than 100m from the cabinet, so signal to noise ratio is still really high, giving Attainable rates of 130Mb DS & 41Mb US against the service capped 40Mb & 10Mb Sync speeds.
-
Thanks for that Baldeagle.
Engineer been around this morning - not a "boost" engineer but just a normal telephony one ??? although he was here to look at our broadband. Anyway hooked up his unit and done all the tests - would not do the TDR ... found another fault on the line which he described as another "battery".. so he went out to fix it.
He got the profile reset - which I thought was strange after reading all the reports from others saying how hard it was to get one.
Anyway at the moment my sync is 53/10 which is better than before - interleave is 1/1 now so pings are very low and so far after a 2 hours sync and quite a lot of net activity not a single CRC error 0-0 (but a few FEC and HEC), the SNRM is a bit higher as well... but DS attainable rates are like 3 or 4 megs lower now ?!!??! why oh why !
Latest stats :
-
Anyway at the moment my sync is 53/10 which is better than before - interleave is 1/1 now so pings are very low and so far after a 2 hours sync and quite a lot of net activity not a single CRC error 0-0 (but a few FEC and HEC), the SNRM is a bit higher as well... but DS attainable rates are like 3 or 4 megs lower now ?!!??! why oh why !
If you are getting the FEC, CRC & HEC errror count from the Hg612's GUI, be mindful that they are incorrect/mixed up.
With Interleaving at 1/1 (i.e. OFF) you shouldn't really see any FEC errors.
The better (more accurate/correct) details are RSCorr, RSunCorr etc. as stored in the Plink log in the xdslcmd info --stats section (near the bottom of the log).
-
I also suspect that the electrical pulse from a TDR tester would also temporarily "fix" this particular fault, hence it never being picked up when engineers have run TDR tests.
Bald_Eagle1,
I would like to use you in a "thought experiment" to show that your above suspicion is invalid.
For our experiment we shall require a battery of twenty five 2V lead-acid cells connected in series, an ex-GPO ringing converter capable of producing an output of 120V AC at 25 Hz, two reels of CW1308 cable and an ex-BT 301C Tester.
Prepare the two cables by stripping the insulation of each end of the (say) blue pair and connect the two cables together with a pair of twisted joints. Do not insulate those twisted joints, they need to be accessible.
At one end of that double length cable, connect the battery of cells to provide 50V DC -- thus mimicking the exchange battery. At the other end of that double length cable, connect the Tester 301C but do not turn it on.
Go to the mid-point of that double length cable, take hold of one twisted joint in one hand and touch the other twisted joint with a finger of the other hand. Feel anything? No, I didn't think you would. So you now grasp the second twisted joint with the second hand and confirm . . . nothing.
Having let go of those joints, now turn on the Tester 301C and try to if the twisted joints show up in the TDR trace. (It's not important if you can the presence of the joints, we just need the 301C powered on and connected to the cable.) Go back to those twisted joints and repeat the cautious "touch" testing. Feel anything? I very much doubt it.
Finally, connect the ex-GPO ringing converter in parallel with the battery of cells and turn it on. Look at the TDR trace. Repeat the cautious "touch" testing. I guess your feathers (those you have left) stood on end! :lol:
It is the alternating "kick" of the ringing voltage that will "punch through" the corrosion / oxidation / minute air gap of a "manky" joint not the RF signal from a TDR tester.
-
It is the alternating "kick" of the ringing voltage that will "punch through" the corrosion / oxidation / minute air gap of a "manky" joint not the RF signal from a TDR tester.
Ouch!
That gave me quite a bang :wall:
I wish I could explain then why the 301C sees no differences when my line is O.K. & when it is playing up like this.
Maybe all will be revealed on Friday :-\
-
I wish I could explain then why the 301C sees no differences when my line is O.K. & when it is playing up like this.
I wish I could have paws-on experience of your line. Only having remote feed-back is not conducive to good fault-finding. :(
Maybe all will be revealed on Friday :-\
For your sanity, that would be good. :)
:hmm: Hmm . . . not quite the first anniversary of the installation. ::)
-
:hmm: Hmm . . . not quite the first anniversary of the installation. ::)
Nearly, 24th June will be its birthday.
It still all points back to whatever was done to restore my 4 day loss of service last July.
Everything seemed pretty much purrfect until then.
Just think how much grief, time & therefore cost could have been saved if the "right" job(s) had been carried out at the outset.
Mind you, we wouldn't have needed to develop any graphing scripts between us if that had been the case :lol:.
-
Mind you, we wouldn't have needed to develop any graphing scripts between us if that had been the case :lol:.
I see you've found the "silver lining"!
Without the problems currently present with your line, you would not be a Kitz forum member regular and thus posting here. :)
-
Without the problems currently present with your line, you would not be a Kitz forum member regular and thus posting here. :)
True, but my house refurb would have been finished months ago & I would now be able to relax on the patio with a nice cold lager or 3 after a tough day at the office :(
-
Since the engineer visit our service has degraded significantly... and strangely we can't run the BT online check on the line anymore (we get a message saying "Sorry, we are not able to test or provide an update on this line.") and if you try and do the check via 150 it fails as well.
Our attainable rates have gone from 58mb to around 50mb now .. and SNRM will now drop gradually until the modem resyncs (will take around 10 hours for this) with everytime a little drop in the IP profile... we have never had a single resync for the 14 days prior to the engineer visit and SNRM was always stable around 6.2...
A new thing = When we pick up the phone now we lose sync ... when we put the phone down we lose sync .. and during the call it resyncs and the SNRM goes to around 7.6db from around 6db - and I can certainly hear some noise on the line now when on calls ---> :lol:
Have we been screwed ?
==============================
Right some progress ..
I removed the new openreach FTTC faceplate, and plugged the modem straight into the master socket - and the connection is back to some kinda normality (attainable rate back up to 55mb and sync rate is highest Ive ever seen at 54mb SNRM around 6.4db)
Reconnect the face plate and only connect the modem - same as above good connection.
Connect the phone no problem .. but make a phone call and hell breaks loose (lose sync ect..) Used a different hand set and still same thing. Now the modem reconnects at much lower rates and attainable and SNMR are silly low.
Only way to fix it again is to remove face plate and do the same again.
Is it a case of a bad filter on this face plate ???? Why does it have to be removed before the line is back to normal after a phone call is made ?
I'd love to be doing something else at midnight :'(
================
Update ... 2 hours after last forced resync
Have not made a phone call .. SNRM not dropping anymore like it used - solid around 6.2db - no resync. CRC count is 3000 (only 1 up) HEC is 250 (0 up) - is this considered a high CRC count ?
Safe to think the faceplate filter is dodgy ? or is there something else thats causing the resyncs when phone is used ? (remember after using the phone only removing the faceplate would bring the connection to a decent state).
-
All the symptoms point to the filter faceplate. Have you got any extension wiring off it though?
A decent ADSL filter should work perfectly well with VDSL so you could try a known good dangly filter with your telephone (If really concerned you could 'double filter' the phone).
-
Thanks for the answer.
I did use another filter and even double filtered to no avail...
What's disturbing is that even with the phone unplugged and the modem connected straight into the test socket (we do not have any extensions connected to this line), the connection will receive a huge amount of CRCs (millions) when I call myself with say a mobile... If left to ring long enough it will occasionally force a disconnect.
We have another BT line here using the other 2 wires from the same cable (going to another NTE5 socket), no broadband on this line. If I call my broadband line using the phone connected to this second line, the modem will drop sync fairly quickly (CRCs through the roof), again with the modem still connected to the test socket...
I informed BT business today and at the moment all they was that openreach are investigating. They will call me back tomorrow with an update - needless to say as a business we receive a lot of calls on the broadband line which has resulted in a large drop of the IP profile to around 44 now and interleaving has also been turned on. Ping to BBC.com around 28ms from an avg of 7ms just yesterday :(
-
When you mention connecting the modem straight into the master socket & straight into the test socket, do you mean via a dangly filter or are you using a cable with a standard UK telephone type plug on it?
-
Hi Eagle
I did it with a telephone cable into the test socket (tried a couple of cables)
I even tried the modem cable into a microfilter (again tried a few) and into the test socket.
Pick up the phone or receive a call and poof no sync !
But while no calls are on it is solid now no more SNRM gradual drops.
-
@ eliw,
Back in November, my drop wire from the pole mounted DP was replaced & rerouted directly to a whole new master socket & faceplates.
See the attached photos of the master socket/faceplate components that were originally installed last June.
The new drop wire etc. seemed to fix things (but only for a short while).
Since then there have been other issues, not least caused by dialling in and/or out.
Usually, receiving a call fixes things, but again for only a few days.
More recently, these issues have definitely been linked to warm & dry weather.
During wet & cold weather, use of the phone has not caused more than 0.2dB drop in SNRM & has not caused any disconnections.
In early April, an engineer replaced the cabinet jumper wires & replaced the VDSL faceplate.
Well, I think he replaced the faceplate while I went to make a brew, he said he was replacing it.
As DLM had been "stuck" at some low speed for quite a few days again, the engineer got it reset & again, everything looked to be fixed.
Unfortunately, this only lasted for a few days before the phone issue started again, disappearing again for the remainder of April (the coldest & wettest on record).
I have now seen a few posts in various forums describing similar issues, particularly when the weather becomes warm & dry.
b*cat has just pointed out yet another one to me.
Like you, I am now wondering if the service specific VDSL2 filter faceplates are indeed the link here.
Maybe the phone issue is something like a capacitance issue caused by the filter components that is more evident in warmer temperatures?
I have done this all this previously (but not since the ssfp was supposedly replaced in April), but your description of removing faceplates etc. prompted me to remove both the VDSL2 & telephone faceplates & connect the modem & a telephone into the test socket via a dangly splitter/filter again.
Until doing this, there had been a number of re-syncs today, with SNRM levels all over the place (see attached graph).
After doing it, lo & behold, no re-syncs & only a miniscule drop in SNRM when dialling out or in.
I will leave things this set up like this overnight, just to see if SNRM lowers to really low levels again & use of the phone again causes disconnections tomorrow morning.
If it doesn't, I'll reconnect the filtered faceplate & try again.
The forecast is still for very warm & dry weather, so it should be a good test.
Incidentally, my own TDR tests have not identified anything on my connection right back to the cabinet that wasn't already there in April.
An engineer should have visited today who would have checked all this (I was going to ask him about the filtered faceplate anyway), but the visit was cancelled in Plusnet's system just 2 hours after they confirmed the visit to me.
As nobody bothered to tell me it was cancelled I sat around all morning in anticipation of getting my broadband service permanently fixed.
Plusnet were supposed to contact me this afternoon confriming whether or not an engineer visit could be arranged for tomorrow.
Guess what. They didn't bother confirming one way or the other.
So I can now sit around waiting for an engineer who doesn't show again tomorrow, or take the risk of getting on with things, missing the engineer & being charged for that privilege into the bargain.
Have dodgy VDSL2 filters been to blame all along for a number of us users?
EDIT:
FWIW, I have attached a photo of the 1st filter (from behind the test socket).
@b*cat,
I did email a photo of the VDSL2 filtering once over.
I can't find the photo now, do you still have it?
I don't really want to strip down the ssfp even though it is a spare one, as I don't want to risk damaging it, just in case I need to use it again.
2nd EDIT:
I found the photo of the VDSL2 ssfp filter.
It is rather blurred, but I have attached it anyway.
-
Sorry Mr Eagle but the b*cat has developed a "thumping, stormy, headache" which, I'm sure, is weather related.
I attach a somewhat better photograph of the internals of a SSFP (no camera shake, higher resolution). :)
What you call "the 1st filter (from behind the test socket)" is not a filter at all. It is just the capacitor and resistor that are (series) connected across the incoming pair. They ensure that the pair are correctly terminated and provide the "bell" wire, from the junction of the capacitor & resistor.
-
From my photographs it can be seen that the "back plate" that includes the test socket (2nd photo from the left) has 4 terminals in the test socket.
These 4 terminals have arrived at this point after applying the bell wire circuitry from the only 2 available terminals (A & B) on the reverse side, to which the drop wire is directly connected.
Into this test socket is plugged the VDSL2 SSFP.
The male plug on the reverse of the SSFP contains only 2 terminals (the outer pair).
However, we can see from your clearer photo that 8 terminals are present at the VDSL2 socket & 4 terminals are present at its "extension" socket into which plugs the telephone faceplate, also containing 4 terminals.
The telephones in use at my home only have 2 wires in their leads (the middle pair of the 4).
The lead supplied with the HG612 modem also only contains 2 wires which conect to the middle 2 terminals of its plugs.
My findings from the experiment of removing the SSFP & using a dangly filter plugged into the test socket, with the modem & 1 telephone plugged ito the dangly filter are as follows:-
- SNRM has hardly fluctuated at all overnight.
- At 09:00 this morning, using the phone causes SNRM to drop by only 0.2dB & it certainly does not cause a disconnection.
- Output power levels have remained perfectly flat. b*cat may recall I have previously queried my fluctuating output power levels.
- The connection re-synced at 05:51 this morning. I believe this was DLM's attempt to provide a higher speed based upon the previous 13 hours or so of stability.
However, DLM is curently "stuck" at a sync speed of only 19999k due no doubt to all the disconnections during this week's spell of warm & dry weather.
- There have only been 13 DS & 6 US Error Seconds since using the dangly filter & all other error counts are very low (for my connection).
All error counts (apart from RSCorr errors due to Interleaving still being switched on) are completely non-existant sine the early morning re-sync.
I will continue using the dangly filter setup for the rest of what promises to be a very warm & dry day before retesting with the VDSL2 SSFP.
If returning to the VDSL2 SSFP also produces such clean results, I will have no idea whatsoever as to what is/has been causing these recent issues.
I wonder if OR secretly found & fixed something while I just happened to be on the phone to Plusnet, complaining that the engineer hadn't turned up for the specially arranged appointment. ;)
So, to summarise, things do appear to be pointing toward a faulty VDSL2 SSFP being the culprit.
This is not identical to eliw's issue, but is very similar indeed.
Thanks eliw for mentioning your experimentation & prompting me to start all over again, despite my SSFP supposedly only being replaced in April.
If this is indeed the cause of my more recent issues, the lesson learned has to be "NEVER, NEVER, NEVER IGNORE THE BASICS JUST BECAUSE SOMETHING IS "SUPPOSEDLY" FIXED.
For the first time ever since being able to graph my connection's stats I am able to present a completely clean bill of health.
It does only cover 200 minutes hours, but it is indeed a FIRST! ;D
-
Good result BE. I can 100% confirm that we do have issues with some VDSL frontplates. I wouldn't say it's in the extreme, but maybe one every 2-3 weeks when working on ADSL/VDSL faults, will require swopping out.
-
Hi Eagle
I did it with a telephone cable into the test socket (tried a couple of cables)
I even tried the modem cable into a microfilter (again tried a few) and into the test socket.
Pick up the phone or receive a call and poof no sync !
But while no calls are on it is solid now no more SNRM gradual drops.
Just to confirm, you do actually mean the "test" socket with the VDSL2 SSFP already removed, don't you?
Also, just to mention (possibly mentioned previously), CRC, FEC & HEC errors (as reported in the HG612 modem's GUI) are NOT to be trusted as they do not match the more detailed (& probably more realistic) RSCorr, RSUnCorr errors etc from xdslcmd info --stats.
-
hmmm, I had a SSFP fitted with my new line, I think I will revert back to my NTE-2000 FFP (which is made by asme company 'Pressac' and uses same filters, I think anyway)
but since it was installed I have had sync problem relating to bad rain making it better??
glad I read this BE, thanks for pointing me to the thread, I will remove mine and see if it makes any difference to at least the evening increase in noise (doubt it but who knows) the SSFP certainly isnt the cause of my problem...but I have had some funny things happen since it was installed
sky have posted me out another filter ...lol...
what is the BEST filter one can get?
possibly try the router directly into the test socket too... the modem has a High Pass filter built in so removes everything 4kHz and below, i have heard of some people doing this who dont use phones...may be worth testing it
-
Snadge,
Thank you for your explanation of the ISAM / MSAN.
possibly try the router directly into the test socket too... the modem has a High Pass filter built in so removes everything 4kHz and below, i have heard of some people doing this who dont use phones...may be worth testing it
I would agree with you. That is the "cleanest" experiment possible. It will be interesting to know the result.
what is the BEST filter one can get?
I always recommend the Pressac manufactured device, as illustrated on the Clarity site (http://www.clarity.it/xcart/product.php?productid=16134&cat=0&page=1&featured). I have had one fitted for a number of years and have never had any problem with it.
-
what is the BEST filter one can get?
I never had any problems with my adslnation XTE-2005 (http://www.adslnation.com/products/xte2005.php) front plate. In fact, I've still got it. If you PM me your address Snadge, I will post it to you ;D
-
Update to my own issues here:-
http://forum.kitz.co.uk/index.php/topic,9726.msg217596.html#msg217596
@eliw, thanks again for reporting your experiment with faceplate removal/dangly filters etc.
You can now have your somewhat hijacked thread back again ;D
-
BE you are welcome mate.
I have tried all sorts of combinations of filters but none helped. When I get a phone call or make one the connections drops, I even tried an ADSL nation faceplate which I have used for years with ADSL2+ and it made no difference .. simple ... nothing I can do on my side. It is a BT issue that has only cropped up since the last engineer visit.
In fact they agree and were supposed to send a guy today (specialist engineer they call him... wonder what that makes the other ones), but I was at a BBQ enjoying the sunshine and the bevvies... so they re-arranged it for tomorrow morning. Seems like they are very responsive to us on a business line but then again I pay £60 a month for a simple FTTC connection (albeit with a 16 IPs allocation).
My connection has been up for nearly 14 Hours now and despite a half a Db drop in SNRM (it is at 5.7 now) it will gradually get back to 6.2 or thereabout by midday tomorrow, this of course if I don't receive any phone calls or make ones myself. Error count at the moment is near 200 which compared to other days is very minute indeed.
-
In fact they agree and were supposed to send a guy today (specialist engineer they call him... wonder what that makes the other ones), but I was at a BBQ enjoying the sunshine and the bevvies... so they re-arranged it for tomorrow morning. Seems like they are very responsive to us on a business line but then again I pay £60 a month for a simple FTTC connection (albeit with a 16 IPs allocation).
That is the advantage of being a business rather than a domestic user. As to the engineer who will be calling, the THC exchange is not in Black Sheep's area (Lancashire and Cumbria) -- so it won't be him, unfortunately. If you have the services of a BS clone, then things should go well.
-
Bless you B*Cat. :-[
There are lots of great engineers out there, just a lot of crap ones as well. The latter tend to get rewarded for great productivity ???? Damned madness !!
-
@ BlackEagle - thanks for the offer of the XTE-2005 , but I have a decent FFP that Black Sheep sent me many moons ago, it gave me increased speed (300k) just from the filter (no internal wires) - I wonder who makes te filter in those?
@ eliw - I may be wrong , but the "specialist" Engineer might be a Broadband Engineer? - infact sky have just been on blower to me today to tell me they would like to try another BTo Broadband Engineer before sending out a Sky Network Engineer with a BT Broadband Engineer...because the last one did not do the broadband diagnostics (as he had to repair phone line then left) and he said a lot of the time when they send out a Sky Network Engineer it turns out to be something on BT's loop and sky have to charge BT for the call out and work... he said if this happens with me then BTo may refuse to pay on the grounds they werent given a chance to fix it...even if the first Broadband Engineer left without diagnosing he says BTo will just say that sky should have said so and BTo would have sent another one out...so fair do's... anyway, best of luck tomozza
-
I have a decent FFP that Black Sheep sent me many moons ago, it gave me increased speed (300k) just from the filter (no internal wires) - I wonder who makes te filter in those?
If it is marked with Openreach's name, then it will have undoubtedly been manufactured by Pressac. [1]
[1] http://www.slowinternet.co.uk/products/bt-premium-centralised-filter
-
Well engineer came on Sunday - he did a TDR without me asking him ... used two types of machines one with knobs (which he called old school) and an exfo - both showed a huge spike at around 65m .. He went out to fix then returned saying that instead of fixing it he gave us a new line ??
Phone now does not interrupt internet - and I am connected at highest sync since fttc install 54DS 10US - and in 30 hours of connection he are the error counts in --stats .. please tell me what you think:
# xdslcmd info --stats
/bin/sh: xdslcmd: not found
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 10023 Kbps, Downstream rate = 54996 Kbps
Path: 0, Upstream rate = 10000 Kbps, Downstream rate = 54481 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 6.2
Attn(dB): 0.0 0.0
Pwr(dBm): 12.3 4.6
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 64 43
R: 0 16
S: 0.1402 0.7562
L: 13695 2687
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 14597088 1980086
OHFErr: 2611 37
RS: 0 2067398
RSCorr: 0 140
RSUnCorr: 0 0
Path 0
HEC: 3500 0
OCD: 0 0
LCD: 0 0
Total Cells: 3442055853 0
Data Cells: 25220232 0
Drop Cells: 0
Bit Errors: 0 0
ES: 399 28
SES: 22 0
UAS: 31 31
AS: 32874
-
Seems like I still have another problem now .. SNRM starts to drop from around 6pm ... about 0.2/0.3 every hour... so by the morning it will resync if nothing is done.
Any clues ?
-
I wouldn't worry about it too much just yet, the chances are that it won't re-sync. I've attached a graph of my SNR covering a 24hr period clearly showing my SNR dropping to almost 4dB. Current DSL uptime though is over 150 hrs ;)
-
Ok - will not reboot and see how low it gets overnight.
It has already reached 5.3 (funny thing the US just like yours in your graph does not seem to be affected).
I'm just worried about DLM.. do they monitor SNR as well ?
-
Seems like my SNR does not recover after that night's drop ... was stuck all day at 5.1 today .. so rebooted the bloody router - back to 6.4 now
-
Seems like my SNR does not recover after that night's drop ... was stuck all day at 5.1 today .. so rebooted the bloody router - back to 6.4 now
did it affect your sync rate at all? if not I wouldnt be too concerned about it, its normal (well, it is on ADSL) to get small noise increase during evening when more electronic devices are turned on and street lights come on etc. as long as its all working just fine, no major error problems and no drop in sync rate... :)
-
True but had i left it at 5.1 it would have dropped by another db today then another the day after and a resync would have occured... a few of these and ip profile is affected (IMHO).
Can't wait for March 2013
-
True but had i left it at 5.1 it would have dropped by another db today then another the day after and a resync would have occured... a few of these and ip profile is affected (IMHO).
But wouldn't a prolonged test such as that actually confirm beyond any doubt that there is still an ongoing issue/fault that experienced engineers would be able to easily diagnose & hopefully repair?
Such similar symptoms as SNRM graudually dropping over a number of days, disconnections when using the phone etc. were resolved on my connection via a combination of replacing the SSFP (my own test with a dangly filter identified that it was faulty) & remaking a connection in the DP at the top of the pole across the road from my house.
TBH, I believe replacing the SSFP had the greater instant impact & remaking the DP connection has hopefully finally cured my connection's general, but ongoing intermittent instability issues.
Gradually dropping SNRM suggests (to me) that resistance is gradually building over a number of days, only being "released" by physically rebooting/disconnecting & reconnecting the modem.
My SNRM used to immediately increase by quite a few dB when whatever was causing the issue was "released" by the telephone ringing pulses when dialling in.
Sometimes this would also cause an immediate connection drop, with things returning to normal for a few hours at a time.
FWIW, see my attached 8 day graphs.
The before & after conditions are clear to see.
There has only been one connection resynsc that was not initiated by me.
That was when DLM decided that my connection is now sufficiently stable to turn off Interleaving, INP & delay (unless it is just lulling me into its regular false sense of security that it has had so much fun with over the last few months.
DS error seconds have increased (to be expected I suppose, due to Interleaving being turned off)
DS Output is also fluctuating more than what I would class as "normal".
Other than those, it all looks quite promising.
If my connection is indeed now permanently fixed (a couple of weeks monitoring will confirm one way or the other), it will just show how inadequete the fault finding efforts of the previous visiting engineers have been.
Have you tried the ongoing graphing scripts yet?
They can be a lot more revealing (& useful when trying to "prove" that fault conditions still exist than trying to study numbers in a chart/list.
-
@ eliw - have you had this problem ongoing where the SNRM dips continually by say 1db per day too the point it drops a 3-4-5 days later? ,
- if not then I think you will find if it dropped to 5.1db that it would probably stay 'about' there OR/THEN eventually climb back up... but then again Iam unfamiliar to what has been going on in your case, so I apologise in advance if this is whats been happening in your case...
but normally, just because it dipped by say 1db one night from 6db to 5db... does not mean it will drop from 5db to 4db the next, then 4db to 3db the night after that etc..and continue to do so , this just means you have an average noise increase to force a 1db reduction in the SNRM - now you have rebooted and forced the SNRM back up then its likely that it may drop back down to 5db again, when the evening comes around the noise on the line increases and so the margin dips slightly, it is supposed to go back up but if it hasnt then it means the noise is still there at that amount OR it is simply 'stuck' - my SNRM seems to do it AND Bit-Loading seems to, I will have lots of tones missing in the Bit-Loading Map and my SNRM maybe 1-2db lower than default...when i reboot I get the tones back but the speed remains about the same because the SNRM is forced back up to 7db - later on it will drop back down to 5-6db , but it wont go any lower if I left it.
I would have left it... not rebooted, and see if it dropped further tonight, and again the next night... it will now that you have re-set it
p.s. I took out my SSFP and put in the FFP (made by same company) and results are the same for me, I will try a sky filter tomorrow
-
Cheers for the advice guys.
I have completely removed the SSFP and conected the router straight into test socket without any filter or phone - who needs customers... !! :'(
It is now back down to 5.3 and will most probably end up around 5.1 by the morning and stay there. And I agree I should have left it there to see if it will drop any lower the next day/evening.
Baldeagle- Yes I have started collecting continuous stats - have a look below. I am nearly convinced that the problem is at the top of the pole now .. if you read my first message in this thread you will see that I thought that was the case when the line was changed about 2 years ago now.
ABout the continous stats ... for some reason the max I can do is 20h even though I know I have about 26h or so of logged data.. but if I try anything above 20h I get : line 0: illegal day of month (I have deffo set the date and not rebooted at least around 27h ago, maybe I have an old version of the scripts ?). As you can see in the graphs I forced resync today around 15.30 - and the other thing is the higher than normal error count this evening ... quiet all day then suddenly a rush of errors (it was not the case yesterday)
I should have started to log the stats when I started this thread :)
-
ABout the continous stats ... for some reason the max I can do is 20h even though I know I have about 26h or so of logged data.. but if I try anything above 20h I get : line 0: illegal day of month (I have deffo set the date and not rebooted at least around 27h ago, maybe I have an old version of the scripts ?).
I will shortly be releasing updated versions (still tweaking them).
The illegal date message is usually only seen when there is insufficient data for the period requested.
If you wanted to post a copy of modem_stats.log (maybe zip it or rename it to a compatible format first), I'll have a look at my end for you.
-
I am nearly convinced that the problem is at the top of the pole now .. if you read my first message in this thread you will see that I thought that was the case when the line was changed about 2 years ago now.
@eliw -- Will you confirm the route of the last few lengths of your D-side pair for me, please? It appears from below ground to climb a pole on the north side of H . . . Road, as an aerial cable it crosses H . . . Road and enters P . . . Avenue to a pole top on the western side of the Avenue. All of the previous is quite clear. What follows is uncertain. Are you fed by a drop cable from a DP at the top of the second pole? Or does the cable climb down the pole to return underground and then is distributed radially from a DP in a joint chamber?
I'm trying to understand which cable was brought down by the falling bough from a tree . . . your individual drop cable, after the DP or the aerial D-side bundle linking the two pole tops.
-
Yes it goes underground between the second pole on P... avenue and the 3rd pole (our pole) then distributed radially from that 3rd pole ... the cable that was brought down is the cable that goes from the top of that pole to our property.. only our cable was brought down.
Our pole is at the intersection between our road (P... avenue) and Park Avenue.
-
Ah, I see. Got it. :thumbs: So we need to factor-in the average height of three poles when calculating the length of your D-side pair.
did a TDR without me asking him ... used two types of machines one with knobs (which he called old school) and an exfo - both showed a huge spike at around 65m
I've been trying to judge where 65 metres from your NTE5/A would be. :-\ Not too relevant -- just interesting to an inquisitive feline.
The "doings" with the knobs on must have been a Tester 301C . . . Yay! . . . 'cause Walter, Bald_Eagle1 and b*cat each possess one. Asbokid, being nonconformist, has something completely different. :D
-
BT Openreach engineers don't know how lucky they've got it with their dainty little test kits. The Mole, the Hawk and the JDSU are all light enough that even a bantum-weight engineer can haul them about and, when called upon, could shimmy up a pole with them, too.
Unlike their colleagues in America who always go for the larger things in life. Double BigMacs with extra fries and relish, seven liter V8 Humvees, 84 inch plasma TVs to show Michael Moore in ultra widescreen, etc..
If it's big and if it's fat - it's American.
It's just the same when it comes to American telecoms test kit. Until recently, the standard issue TDR tester supplied to AT&T linesmen was about as portable as a large car battery. Which is no exaggeration since the AT&T tester is actually powered by a heavy lead acid battery. The nylon carrying strap behaves like cheesewire on the shoulderblades ;)
cheers, a
-
what are the purposes of these:
The Mole, the Hawk
i found this video about the JDSU, good for someone like me who knows nothing about it :)
http://article.wn.com/view/2010/01/27/JDSU_Selected_by_BT_to_Provide_HST3000_Broadband_Access_Test/
the JDSU is just like a massive SKY+ remote hehe
-
Ah, I see. Got it. :thumbs: So we need to factor-in the average height of three poles when calculating the length of your D-side pair.
did a TDR without me asking him ... used two types of machines one with knobs (which he called old school) and an exfo - both showed a huge spike at around 65m
I've been trying to judge where 65 metres from your NTE5/A would be. :-\ Not too relevant -- just interesting to an inquisitive feline.
The "doings" with the knobs on must have been a Tester 301C . . . Yay! . . . 'cause Walter, Bald_Eagle1 and b*cat each possess one. Asbokid, being nonconformist, has something completely different. :D
Just to clarify B*Cat, the 'twisting of knobs' (O-err missus) will not be done on a 301C Meter. It could have either been the old Ohmeter 18C, or the even older oscilloscope's we used to use ........ the latter pinpointing the smallest of an HR every time !!
-
BT Openreach engineers don't know how lucky they've got it with their dainty little test kits. The Mole, the Hawk and the JDSU are all light enough that even a bantum-weight engineer can haul them about and, when called upon, could shimmy up a pole with them, too.
Unlike their colleagues in America who always go for the larger things in life. Double BigMacs with extra fries and relish, seven liter V8 Humvees, 84 inch plasma TVs to show Michael Moore in ultra widescreen, etc..
If it's big and if it's fat - it's American.
It's just the same when it comes to American telecoms test kit. Until recently, the standard issue TDR tester supplied to AT&T linesmen was about as portable as a large car battery. Which is no exaggeration since the AT&T tester is actually powered by a heavy lead acid battery. The nylon carrying strap behaves like cheesewire on the shoulderblades ;)
cheers, a
Asbo, haven't got the time to 'Google', but isn't the JDSU an Americanised bit of kit ?? Seems odd that they're shuffling around with large wardrobes, for testers when they have these on their doorsteps ??
The only reason I have for believing they're American, is that all our literature regarding the testers talks about "Tip to Ring". This is a Yankeeeee term for our A and B wires. ;D ;D
-
BT Openreach engineers don't know how lucky they've got it with their dainty little test kits. The Mole, the Hawk and the JDSU are all light enough that even a bantum-weight engineer can haul them about and, when called upon, could shimmy up a pole with them, too.
Unlike their colleagues in America who always go for the larger things in life. Double BigMacs with extra fries and relish, seven liter V8 Humvees, 84 inch plasma TVs to show Michael Moore in ultra widescreen, etc..
If it's big and if it's fat - it's American.
It's just the same when it comes to American telecoms test kit. Until recently, the standard issue TDR tester supplied to AT&T linesmen was about as portable as a large car battery. Which is no exaggeration since the AT&T tester is actually powered by a heavy lead acid battery. The nylon carrying strap behaves like cheesewire on the shoulderblades ;)
cheers, a
Asbo, haven't got the time to 'Google', but isn't the JDSU an Americanised bit of kit ?? Seems odd that they're shuffling around with large wardrobes, for testers when they have these on their doorsteps ??
The only reason I have for believing they're American, is that all our literature regarding the testers talks about "Tip to Ring". This is a Yankeeeee term for our A and B wires. ;D ;D
I was thinking that myself, having searched ebay for them they are all mostly American auctions
-
Asbo, haven't got the time to 'Google', but isn't the JDSU an Americanised bit of kit ?? Seems odd that they're shuffling around with large wardrobes, for testers when they have these on their doorsteps ??
The only reason I have for believing they're American, is that all our literature regarding the testers talks about "Tip to Ring". This is a Yankeeeee term for our A and B wires. ;D ;D
Stop spoiling the story, Black Sheep!
-
Asbo, haven't got the time to 'Google', but isn't the JDSU an Americanised bit of kit ?? Seems odd that they're shuffling around with large wardrobes, for testers when they have these on their doorsteps ??
The only reason I have for believing they're American, is that all our literature regarding the testers talks about "Tip to Ring". This is a Yankeeeee term for our A and B wires. ;D ;D
Stop spoiling the story, Black Sheep!
Whoops ..... :lol: :lol: I'll go back to my grazing. ;D
-
Whoops ..... :lol: :lol: I'll go back to my grazing. ;D
And when you have finished doing that, check in the early GPO documents. There you will find usage of Tip, Ring and Sleeve relating to the three segments of the jack plug, as used at the operator's position of a manual switchboard. :P :oldman:
Granted, modern day usage of those descriptors tends to be American. (http://www.centos.toracat.org/ajb/tmp/flag_us.gif)
-
Just to clarify B*Cat, the 'twisting of knobs' (O-err missus) will not be done on a 301C Meter. It could have either been the old Ohmeter 18C, or the even older oscilloscope's we used to use ........ the latter pinpointing the smallest of an HR every time !!
As eliw stated that both of the engineer's thingies showed a big peak at about 65 metres, I discounted the idea of an Ohmmeter 18C (or 18B) although I must admit they do have nice knobs to twiddle. (As I have both devices in The Cattery, once I get around to it, I shall be sending the 18B to Walter -- so that he has a fully equipped Wheelbarrow. (Walter's Wheelbarrow has legendary status in Ewhurstshire -- it resolves the issues that the BT Group ignore. :D )) I wonder if the engineer might have been using a Tester 301B . . . that's a chunky thing with whatsits to twiddle. :-\
-
what are the purposes of these:
The Mole, the Hawk
i found this video about the JDSU, good for someone like me who knows nothing about it :)
http://article.wn.com/view/2010/01/27/JDSU_Selected_by_BT_to_Provide_HST3000_Broadband_Access_Test/
the JDSU is just like a massive SKY+ remote hehe
@snadge -- With regards to the JDSU HST-3000c, you might like to watch the product tour (http://www.jdsu.com/specials/hst/pages/default.aspx) for a good overview of the device.
@Black Sheep -- What SIM is normally fitted to the Openreach issued HST-3000c, please? The copper test SIM?
(Apologies to eliw for hijacking this thread, once again. ;) )
-
Apologies for my ignorance, B*Cat, what do you mean by SIM ?? Where do I find that info ?? :)
-
Apologies for my ignorance, B*Cat, what do you mean by SIM ?? Where do I find that info ?? :)
To quote from the JDS Uniphase HST-3000 Platform Overview Brochure (http://www.jdsu.com/ProductLiterature/hst_bro_0608.pdf) --
. . . field-swappable service interface modules (SIMs) . . .
If you turn your HST-3000 over, you will see a screw in the upper segment of the back which (with a quarter of a turn) will allow the SIM to be removed. Above that turn-fastener there should be a label which identifies the SIM in words and with its part number. (Image attached, below.)
I have a number of documents, downloaded from the JDS Uniphase Corporation's website. If you are interested, please send me a PM with your e-mail address and they will be dispatched in a north-westerly direction. (That offer is also available to other forum members . . . ) :)
-
Ah, I see. I have to admit, I didn't read your initial query correctly. For some reason, my brain omitted to see the "Copper test SIM". ::) :-[
In answer to your question, it all depends on your role within BT. Openreach guys (who make up the vast majority of engineers) will have the copper SIM installed. The BT Operate guys actually have 3-4 different SIMS to use, dependant on their task. Most of them haven't a clue how the copper SIM works, and 99% of the time, request an 'assist' from us.
I too have a great 'User guide' for both the JDSU and EXFO. Extremely hard to come by as well, for some reason !!! ???
-
PM'd ya mate. :)
-
me too..
@ BS - who are BToperate and what do they do? i have googled it but sounds like they are same as Openreach?
p.s. my visit did not go down to well today , had a right attitude on him, the sky engineer called ahead of him to give me a 'heads up' that he may be problematic as he had just been arguing on phone with him - I will update my thread on the subject so im not spamming this one ;)
-
They're just another branch of BT ........ certainly not Openreach though.
If theirs any faults with Exchange Equipment (Which includes FTTC cabs), they have ownership of this.
-
Just to clarify B*Cat, the 'twisting of knobs' (O-err missus) will not be done on a 301C Meter. It could have either been the old Ohmeter 18C, or the even older oscilloscope's we used to use ........ the latter pinpointing the smallest of an HR every time !!
@eliw -- Purely for interest (yet again!) but would you please take a look at the two attached images, below. Would one of those devices be what the engineer used, along with his Exfo?
-
Actually it looked more like your picture of the Tester 301C - but the one he had was grey with knobs below the digital screen
-
Thank you for the description. It does sound as if it could have been one of the "o'silly-scopes". :-\
-
Aaaah, the Ohm18B ......... I love you. ;D
I'm not sure I could remember how to use the meter, if asked to ?? :-[
-
BToperate, BTopenreach, Exchange Engineers (MPF ISP's and BTo's), Line Engineers, Broadband Engineers, ISPs -> no wonder it can so bloody difficult to get a fault repaired lol
-
Ha ha .... it can seem like a crazy mess. At the minute, Exchange Engineers belong to BT Openreach, however thay are to move to BT Operate in the very near future.
Openreach engineer skilling is rather more frustrating.
Frames: The most very basic of the skill-sets. The job entails 'Running jumper wire' between pre-determined points on the Main Distribution Frame (MDF). An incredibly easy job to learn.
CAL/OMI (Customer Apparatus & Line .... One Man Installer): They sort of work from the DP to the premises. If there's a faulty E/D side, they will do a change of pair, rather than 'Fault to fix' ..... ie-find the actual cause.
UG (Underground): As it says on the tin ....... these guys only work on UG plant. Far more complicated than the CAL/OMI skill.
Hot-site engineer: Accredited to work in and around HV plant, ie- Electricity Generating Stations, Wind farms etc. The safety aspect is severe, whereby the Local Earth (At the premises) and the Remote Earth (At the Exchange) could have a potential difference of a few thousand volts.
Multi-skilled engineer: Has the minmum of Frame, CAL/OMI and UG skills.
Broadband engineer: Not a stand-alone skill. The original protocol was that only Multi-skilled engineers would be asked to become Broadband trained. However, there are as many CAL/OMI engineers trained up as well.
** My main gripe is that as an engineer with all the above skills, I still get the same remuneration as a 'Frames only' engineer ??? Absolute madness **
There are other skills that don't get a mention as they are not customer facing, such as the Second Stage Repair (SSR) lads, who tend to do the bigger cable change-overs. Then there's the 'Pressure' engineers, who are responsible for maintaining the E-side network is correctly pressurised. There's also the Cable Gangs, Survey Officers and Planners.
At the top of the food chain (IMO) are the Precision Test Officers (PTO's). These guys are who we call in when we are stumped. Doesn't happen often, but it's good to know they are there if needed. Mainly utilised on REIN jobs that can't be remedied locally.
They main issue we tend to find is that the task we recieve has been sent to the wrong engineer, or has been built incorrectly. By that, I mean the remote test result which is carried out every time an EU reports a fault, could show a 'Dis' at lets say, 94% of the entire cable length. this obviously means the fault is at the far-end near to the EU's premises. Now, if not actioned properly, this can sometimes go to a Frames Engineer who has to then 'Further' the task etc etc.
The same test result could see the job being built for a CAL/OMI engineer, and the EU's premises could be a UG estate. Again resulting in the engineer having to 'Further' his task.
The key is to give as much information as possible and hope and prey the ISP's front-desk is manned by someone with an ounce of common-sense. Having said that, they have systems that 'suggest' where the fault should be sent and which skill should be applied to it.
The most common reason for 'Furthers' is the EU reporting a noisy line which remotely tests OK, and a CAL/OMI engineer being despatched. Upon arrival the EU states its actually the Broadband that is suffering, not the phone. This results in a TRC (Time Related Charge) being raised, the engineer has to complete his task due to it being raised as a telephony fault, and the EU has to start the merry-go-round that is raising a Broadband fault.
It's a far from ideal situation, and I have every sympathy for the EU's. Believe me when I say they are sometimes very irate by the time I end up knocking on their door. Only had one who started to turn violent though. ::)
-
Sorry for another hijack!!!! BlackSheep, are some OpenReach Broadband (?) engineers trained on routers like the BT Home Hub? Because, I had an engineer who visited me who recommended a replacement Home Hub, if he wasn't trained on it, I presume he wouldn't have cared?
Hijack over.
-
It's a far from ideal situation, and I have every sympathy for the EU's. Believe me when I say they are sometimes very irate by the time I end up knocking on their door. Only had one who started to turn violent though. ::)
Ah. That would have been my son, Hairy_Eagle1.
It runs in the family you know :angel:
-
:lol: :lol: :lol: BE. Made me chuckle.
-
Sorry for another hijack!!!! BlackSheep, are some OpenReach Broadband (?) engineers trained on routers like the BT Home Hub? Because, I had an engineer who visited me who recommended a replacement Home Hub, if he wasn't trained on it, I presume he wouldn't have cared?
Hijack over.
Hmm, we're not specifically 'Trained' on the Home Hub, or any router for that matter. There was a BT run course, (that got scrapped in it's infancy), that I did attend which went into detail mainly around the BT 2-wire router. It was designed to show the different levels of access that can be achieved and so on. I ended up getting a piece of software called a 'Hub Migration Tool', that basically scrapes the settings from the old router, then re-applies it to the new router.
Apart from that, there's really not much we need to know about the EU's kit. Our remit is to prove the MPF (wiring from Exchange to premises) is fault free and capable of carrying Broadband. One of the higher-level repair products on offer, is a 'Boost' engineering visit. This simply allows us to change a Hub/Router if its blindingly obvious the original is faulty.
I'm not 100% sure what or why the engineer would suggest this ?? Was he a BB trained engineer ?? Did you ask him for his thoughts about the Hub ?? Was he visiting on a BB fault or just a Network fault ??
-
hey BS - mucho thanko for the big description of the BT Staff.. I have bookmarked it into my ADSL bookmark folder hehe - which I have running via Xmarks so is available on any browser I use at any internet connected PC...safe & secure backup!! ;)
thanks for that, always willing to learn.. this time next year I will be able to present my skill set to BTo in hope they sign me up as a 'real' broadband engineer HA HA HA... I WIIISHH!!!
so because your classed as a FRAMES ENGINEER but do the work of other skill sets - does this mean your pay also suffers in similar manner to your job title? ...hope not!!
-
Sorry for another hijack!!!! BlackSheep, are some OpenReach Broadband (?) engineers trained on routers like the BT Home Hub? Because, I had an engineer who visited me who recommended a replacement Home Hub, if he wasn't trained on it, I presume he wouldn't have cared?
Hijack over.
Hmm, we're not specifically 'Trained' on the Home Hub, or any router for that matter. There was a BT run course, (that got scrapped in it's infancy), that I did attend which went into detail mainly around the BT 2-wire router. It was designed to show the different levels of access that can be achieved and so on. I ended up getting a piece of software called a 'Hub Migration Tool', that basically scrapes the settings from the old router, then re-applies it to the new router.
Apart from that, there's really not much we need to know about the EU's kit. Our remit is to prove the MPF (wiring from Exchange to premises) is fault free and capable of carrying Broadband. One of the higher-level repair products on offer, is a 'Boost' engineering visit. This simply allows us to change a Hub/Router if its blindingly obvious the original is faulty.
I'm not 100% sure what or why the engineer would suggest this ?? Was he a BB trained engineer ?? Did you ask him for his thoughts about the Hub ?? Was he visiting on a BB fault or just a Network fault ??
He was visting on a broadband fault and when I showed him the SNRM margin of 18dB, he said the Home Hub was faulty because it was impossible to have a margin that high. Now I know it is!!! It was a few years ago though.
-
arobertson .... you have been visited by one of our, 'Haven't got a clue what I'm doing' engineers. They are exalted by our upper echelon, because they 'clear' 5-8 jobs daily. In reality, they do sweet FA, and eventually a 'real' engineer will pick up the pieces.
It's just a case of awaiting a proper engineer to adorn your premises.
-
arobertson .... you have been visited by one of our, 'Haven't got a clue what I'm doing' engineers. They are exalted by our upper echelon, because they 'clear' 5-8 jobs daily. In reality, they do sweet FA, and eventually a 'real' engineer will pick up the pieces.
It's just a case of awaiting a proper engineer to adorn your premises.
I don't have the issue anymore. In my experience, it is usually the "older" (e.g. 40+) engineers who seem to actually care.
-
arobertson .... you have been visited by one of our, 'Haven't got a clue what I'm doing' engineers. They are exalted by our upper echelon, because they 'clear' 5-8 jobs daily. In reality, they do sweet FA, and eventually a 'real' engineer will pick up the pieces.
It's just a case of awaiting a proper engineer to adorn your premises.
I don't have the issue anymore. In my experience, it is usually the "older" (e.g. 40+) engineers who seem to actually care.
Being in that bracket, I feel obliged to agree. ;) ;D ;D
TBH, there are some really good 'up & coming' engineers. It's as I always state, there's them that can, and them that can't in all industries. Them that can't seem to blossom in a company like ours. ???
-
arobertson .... you have been visited by one of our, 'Haven't got a clue what I'm doing' engineers. They are exalted by our upper echelon, because they 'clear' 5-8 jobs daily. In reality, they do sweet FA, and eventually a 'real' engineer will pick up the pieces.
It's just a case of awaiting a proper engineer to adorn your premises.
I don't have the issue anymore. In my experience, it is usually the "older" (e.g. 40+) engineers who seem to actually care.
Being in that bracket, I feel obliged to agree. ;) ;D ;D
TBH, there are some really good 'up & coming' engineers. It's as I always state, there's them that can, and them that can't in all industries. Them that can't seem to blossom in a company like ours. ???
:) . For example, I had an "older" (40-50 I would guess) engineer come to my house a couple of years ago. He could have just checked the master socket and left, but he took the trouble to look at the extension wiring to make sure it was working and that is wasn't affecting my broadband. I didn't even get charged.
I remember him telling me about the old speed tester he was using; it was a device that had a needle on it that basically showed what speed I was getting at the time. He said that often the newer engineers just bring ToughBooks, etc and they don't always give you the full picture. The engineers also don't have the experience.
Do you have any experience of the device?
-
Wow ..... I think that was the simple tester that was supposed to be kept in the Exchange. It's name escapes me at the minute ??
If it is the device I'm thinking about, it was brought into being so that the Exchange Frames guys could verify if their was active DSL leaving the Exchange on the Bar/Pair fuses. It really was only a very simple indicative tool, nothing like the what the JDSU/EXFO testers of today are like. Plus we have access to WHOOSH for BT BB faulting, which gives such a wide spectrum of metrics, it's untrue !!!!!!!!
As with all things technical, development tends to progress quite rapidly. :)
-
Wow ..... I think that was the simple tester that was supposed to be kept in the Exchange. It's name escapes me at the minute ??
If it is the device I'm thinking about, it was brought into being so that the Exchange Frames guys could verify if their was active DSL leaving the Exchange on the Bar/Pair fuses. It really was only a very simple indicative tool, nothing like the what the JDSU/EXFO testers of today are like. Plus we have access to WHOOSH for BT BB faulting, which gives such a wide spectrum of metrics, it's untrue !!!!!!!!
As with all things technical, development tends to progress quite rapidly. :)
Was it yellow?
-
No, it's a grey'ish colour.
I'm beginning to think you're describing the Meter SA9083. This is a 'Moving coil' meter, thus incorporating a 'needle' that moves across the scale.
This however, can not tell anyone the broadband speed of a circuit ............. ever !!
-
Did it look like this ?? Best picture I can find atm.
-
On the right hand of the scale, it definitely had "8M".
-
Did it look like this ?? Best picture I can find atm.
No. It was much smaller and it was yellow.
-
??? Have to admit, I don't think I've ever seen one of those that you mention then. B*Cat will probably have one in his Cattery though ?? ;)
-
what is difference between EXFO and JDSU
what is WOOOOOSHHHH!! (I heard one of the lads mention it to me when I explained about DMT Tool showing the SNR & BitLoading spectrum)
BS you should start your own BTo training academy lol :D
-
Latest forced resync - as SNRM dropped to around 4.0 and would not move from thee for 2 days ... DS is kinda normal but out put power on US has now dropped to around 3.4 (from 4.7) which is resulting in US attainable rates of around 8mb instead of the previous 10mb..
Anyone care to comment about why the sudden drop in US ?
-
Latest forced resync - as SNRM dropped to around 4.0 and would not move from thee for 2 days ... DS is kinda normal but out put power on US has now dropped to around 3.4 (from 4.7) which is resulting in US attainable rates of around 8mb instead of the previous 10mb..
Anyone care to comment about why the sudden drop in US ?
someone better than me will reply soon.... BUT, it could be spectral shaping due to line conditions, i.e. the Dslam is detecting a build up of crosstalk and therefore reduces output power across the related pairs in an attempt to keep stability and fair speed for all?? just a guess...im not that familiar with mode of operation with FTTC
-
Anyone care to comment about why the sudden drop in US ?
A comparison of your before & after pbParams data may give some indication.
My DS band plan has changed slightly, quite recently, which does appear to have coincided exactly with a large increase (20dB or so) of US attenuation on the higher US band plan.
I can't use any of the higher band plan frequencies anyway due to general attenuation values, but this recent change does appear to have hit both DS & US sync speeds.
-
Seems like att and everything else is the same .. a lot less errors today tho.
All the resyncs during the past week (I think 5) were done by myself...
-
I can't see anything obvious from your graphs.
Your latest resync was in the early hours though, when SNR would be at its lowest.
Things may improve (speed-wise) if you forced a resync/reboot at say between noon & 14:00.
Unfortunately, unlike ECI DSLAMs, the Huawei DSLAMS don't appear to report graphable US SNR, QLN & Hlog data, so we are unable to see if there have been any negatively impacting US changes.
(Although pbParams suggests that not much has changed).
Your SNRM tailing off & staying low still seems very much akin to what I was seeing on my connection, right up until the SSFP was replaced & the connection between the underground feed cable & DP was repaired.
-
Ok check this out now ... I have not done anything since the last resync...
Just have a look at my US SNRM ... baffling crap all this.
And how about this for a ping with Interleave turned off ! :)
Pinging bbc.com [212.58.241.131] with 32 bytes of data:
Reply from 212.58.241.131: bytes=32 time=72ms TTL=239
Reply from 212.58.241.131: bytes=32 time=75ms TTL=239
Reply from 212.58.241.131: bytes=32 time=75ms TTL=239
Reply from 212.58.241.131: bytes=32 time=75ms TTL=239
Ping statistics for 212.58.241.131:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 72ms, Maximum = 75ms, Average = 74ms
I'm turning the router and modem off and leaving them off for a good hour.
-
US Attainable Rate is back up to more or less 10Mb too.
It does seem like quite a noisy line/duff filter issue (going off my not identical, but very similar recent experience).
-
BE I have actually noticed that restarting my modem when the SNRM has rockbottomed ie - sometime around midnight is the best to achieve the highest sync rate (no clue why but empirically correct), I did it a couple of time around 1-2pm and it was 2 megs lower on average.
Anyway here are my stats just after restart (for some reason started with 4000 CRCs - which normally is the 24h count). Very entertaining watching your modem stats all day LOL
Ping to BBC back to 10ms
Can't wait till FTTP on demand...
-
All very strange.
Do you see much difference in your QLN & Hlog graphs depending on what time of day or night the connection resyncs or you reboot the modem etc?
These only ever change during the training phase of a resync & the data remains until the next retrain.
Noisy daytime business machinery interference, or milking machines etc. if rurally located?
-
??? Have to admit, I don't think I've ever seen one of those that you mention then. B*Cat will probably have one in his Cattery though ?? ;)
Attached is a poorly focused picture of a SA9083. I'll have to try to capture a better image of the one I have in my grotto (at The Cattery) via my flat-bed scanner. :)
They definitely do not have an 8M marked at the right-hand end of the scale. :-\
I don't recognise the description of the device in question. :no:
-
what is difference between EXFO and JDSU
what is WOOOOOSHHHH!! (I heard one of the lads mention it to me when I explained about DMT Tool showing the SNR & BitLoading spectrum)
BS you should start your own BTo training academy lol :D
The 2 HHT's (EXFO & JDSU) are very, very similar in what they do, it's just the way in which the data/results are presented that is different. We (BT) use two different manufacturers, in order that there is no monopolising and susbsequent price-hike in spare parts.
WHOOSH is a remote monitoring tool of BT DSL circuits (Not LLU's). It is a great bit of kit, especially when diagnosing REIN faults. I would be on here all night if I was to explain all its metrics, suffice to say its probably the best tool we have to view a circuits history, and when used in conjunction with a HHT at the EU's premises.
-
Whoops, missed a bit ............ WHOOSH can not show 'bit-loading'. That has to be done in a 'live' situation, not historically.
-
After accepting that my router would have to be rebooted every 3 days due to the gradual dropping of SNRM to silly levels without ever recovering, I decided to try one more desperate trick to see if I can stop this issue... I removed the BT Infinity faceplate then removed the box behind it and switched the 2 wires around...
Guess what... I did this yesterday and as I type this my SNRM is at 6.3 - normally it would be around 4.4 or so by now..
From my understanding switching those wires has no bearing whatsoever on anything, but the result is clear here no more dropping SNRM it seems ... I checked the wires before switching them and they were connected properly so can rule out any installation problem. The infinity faceplate is the same as well.
Can anyone explain this at all ?
-
Can anyone explain this at all ?
Perhaps explained not by the polarity swap, but by the re-making of the connections?
cheers, a
-
Concur with Asbo. That's the more likely reason.
-
SNRM still holding as normal no more drops it seems.
I checked the connection before I remade it andit was as good as can be though.
-
I checked the connection before I remade it andit was as good as can be though.
A simple query, please -- IDCs or screw terminals? ???
-
Screw terminals (I take it they are not good ?)
Would the dropping SNRM suggest that the wire wasnt 100% touching the terminal then ?
-
b*cat nods, not just to the first question but to both of them.
Strange as it may seem, an IDC is a more efficient joint than the classic screw terminal. :)
-
b*cat nods, not just to the first question but to both of them.
Strange as it may seem, an IDC is a more efficient joint than the classic screw terminal. :)
Possibly the first time I may have to disagree with you B*Cat. :'( ;) ;D
We tend to find more 'HRs' on IDC connections, than anything 'screw fix'. Especially the Krone and BICC strips in the PCP's whereby the 'Jointer' will have formed, split and fed the 100pr cable loosely onto the strips. He will then in rapid succession, work across and down 'podging' (terminating) all the wires on. It only takes the IDC connector tool to be worn, or off-centre to result in a poorly made connection.
The only down side to 'screw fix' IMO, is the elements and onset of verdigris/corrosion.
-
Possibly the first time I may have to disagree with you B*Cat. :'( ;) ;D
:cry2:
We tend to find more 'HRs' on IDC connections, than anything 'screw fix'. Especially the Krone and BICC strips in the PCP's whereby the 'Jointer' will have formed, split and fed the 100pr cable loosely onto the strips. He will then in rapid succession, work across and down 'podging' (terminating) all the wires on. It only takes the IDC connector tool to be worn, or off-centre to result in a poorly made connection.
Our difference of opinion arises as a result of b*cat accepting the theoretical design principle and B*Sheep having witnessed, first hand, the end result of poor deployment of the method. :friends:
In theory, a properly made IDC joint is superior. In practice, as we have just been educated, defective usage of the tool can create good looking but poor joints.
The only down side to 'screw fix' IMO, is the elements and onset of verdigris/corrosion.
The screw head shearing off (unless a torque screwdriver is used), the metallic core being "nicked" when stripping off the insulation, if the wire being terminated is placed under the screw head rather than under a washer the tightening motion can cause microscopic fractures in the wire (all ready to go "ping" and break lose), etc. :o