Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Ixel on June 21, 2018, 12:49:52 PM
-
Hi all,
Hope everyone's well. I need some advice from some of the experts here if I may.
Basically I've noticed a problem with one of my phone lines. I'm going to plug in an analogue phone to be sure but every time I answer a call or make a call my FTTC connection drops briefly and re-syncs (while the call is ongoing). I've done a PSTN line test on CIX's control panel and it's coming back as no fault found. I have the option of running the test automatically every 4 hours for up to 24 hours should I wish, in case it's intermittent. Now, I realise that answering and making phone calls shouldn't cause a brief disconnection, so I'm wondering what it could be that might not be registering as a fault on the line test? So far I've changed the wire connecting the phone to the master socket. The master socket is an NTE5c MK4 with no extension wiring at all.
Any ideas, comments or suggestions are appreciated. If you require a hlog/qln then I will temporarily return to using a HG612/ZyXeL VMG1312-B10A, as I'm currently using a DrayTek 2860Vac on the line which may have an issue of some type and prefer Infineon/Lantiq over the Broadcom chipset.
Thanks in advance.
EDIT: I forgot to mention that when I initially picked up the phone (DECT) I heard a bit of noise that gradually disappeared. I'm going to test it on the analogue phone shortly to be sure it's not something to do with the DECT phone. Shouldn't be however, they are Gigaset if anyone's wondering.
-
I've done a quiet line test with the analogue phone and sadly I can't hear any noise. Surely my Gigaset phones aren't causing it (perhaps they've developed a fault?). I'll try again with the Gigaset phones in a few moments, unless the fault is intermittent and for now it's cleared up. The FTTC connection didn't lose sync this time either.
EDIT: Did another test with the Gigaset phones and the noise returned as well as taking the broadband connection out for a moment. Interesting. I'll give it 30-45 minutes before I try again with the analogue phone, as I don't want to risk DLM banding me due to too many re-syncs in a short time.
-
Assuming your Gigaset set is similar to mine -put it on speaker and put the back of the phone to your ear. You’ll hear even tiny noises - make sure it’s away before the quiet line test announcement, as you’ll get deafened.
-
Assuming your Gigaset set is similar to mine -put it on speaker and put the back of the phone to your ear. You’ll hear even tiny noises - make sure it’s away before the quiet line test announcement, as you’ll get deafened.
Possibly, I have the N300A. I did do a test on the speakerphone at one point and still heard what I believe to be noise.
I've tested a few times with the analogue phone and no loss of broadband or noise on the line, so it's looking more likely there's a problem with my Gigaset's N300A base. I've had it for quite a few years so perhaps it's time to buy a new product :D.
EDIT: Final update to say that the line appears to be behaving fine with the analogue phone, so I'll buy a new DECT phone. At least it appears to be nothing serious, I'd rather it be a fault that I can identify with something such as my Gigaset N300A base station instead of it being an intermittent line fault. Perhaps that storm some weeks ago did something to the base station, or maybe it's simply a bit of wear and tear showing.
-
Personally I’d be reluctant to blame the DECT phone as the filter within the NTE would, if it were perfect, render the DSL side immune from phone faults, especially if the phone is basically working and not totally kaput. Filters are not perfect of course so it still might be the phone, just on balance of probability, I’d want pretty compelling evidence before splashing out on a new DECT phone.
With the analogue phone, have you tried an incoming call, leaving it ringing for a while, to see if that might have detrimental effect?
Another point, DECT phones often have rather noisy PSU bricks. I assume the wiring to the modem is well away from the phone’s power unit?
You can’t really rely on noise symptoms from a digital phone as it might be internally generated, but even so, noise that starts of loud and then fades, might be more suggestive of a line fault.
-
I will echo 7LM's reply and add that, quite often, the drop-out and re-synchronise of an xDSL service is found to be a joint that is showing HR or semi-conductive tendencies. However, in your case, I don't think that is what you are experiencing due to the absence of the fault when the analogue telephone is in use.
[for reference purposes]
The way I would check is to disconnect the lead-in from the NTE5, connect a TDR directly across the pair and display the resulting trace. Having a FTTC service, I would only be able to "see" as far as the low-pass filter in the "fibre" cabinet. Then from another telephone instigate a call to the number associated with the circuit being examined. If any of the (inevitable) blips present on the TDR trace "jumps around" or changes appearance in synchronism with the standard ringing current then that will most likely be the troublesome joint.
[/for reference purposes]
-
Hi all,
Just to offer an update and reply.
Personally I’d be reluctant to blame the DECT phone as the filter within the NTE would, if it were perfect, render the DSL side immune from phone faults, especially if the phone is basically working and not totally kaput. Filters are not perfect of course so it still might be the phone, just on balance of probability, I’d want pretty compelling evidence before splashing out on a new DECT phone.
With the analogue phone, have you tried an incoming call, leaving it ringing for a while, to see if that might have detrimental effect?
Another point, DECT phones often have rather noisy PSU bricks. I assume the wiring to the modem is well away from the phone’s power unit?
You can’t really rely on noise symptoms from a digital phone as it might be internally generated, but even so, noise that starts of loud and then fades, might be more suggestive of a line fault.
Yes I have tried what you suggested. I've tested the analogue phone for both incoming and outgoing calls this afternoon and this evening until the new phones/base arrived and I've had no further issues. I also tried double and triple filtering the Gigaset base when it was plugged in and that made no difference to the problem I was experiencing unfortunately. The wiring for the modems are well away from the DECT base and power cable.
I will echo 7LM's reply and add that, quite often, the drop-out and re-synchronise of an xDSL service is found to be a joint that is showing HR or semi-conductive tendencies. However, in your case, I don't think that is what you are experiencing due to the absence of the fault when the analogue telephone is in use.
[for reference purposes]
The way I would check is to disconnect the lead-in from the NTE5, connect a TDR directly across the pair and display the resulting trace. Having a FTTC service, I would only be able to "see" as far as the low-pass filter in the "fibre" cabinet. Then from another telephone instigate a call to the number associated with the circuit being examined. If any of the (inevitable) blips present on the TDR trace "jumps around" or changes appearance in synchronism with the standard ringing current then that will most likely be the troublesome joint.
[/for reference purposes]
I agree, at first I thought it might be a HR problem but given the analogue phone apparently behaved flawlessly I guess it wasn't. Since using the analogue phone and now a new base station and set of phones this evening which arrived I've not had further issues. It does really look like something was up with my Gigaset base station sadly, but I've had the N300A for quite a number of years so I've had a long run out of it. I will see if the problem occurs again and post here if it does, but hopefully it won't. I'm still attempting to get what appears to be some kind of bug/glitch sorted out on the 2862 with DrayTek (the interface freezes after a few days of apparently fetching DSL stats via my WIP program, while the 2860 is perfectly stable).
-
Another update, the problem has returned. Others in the house are reporting to me that sometimes they can hear some noise on the phone call (a bit of hissing or clicking). I've tried changing the filter so far, and of course the phone cable was changed when buying the new handsets and base station since it came with a new cable. Often when I make or receive a call it seems cause VDSL2 to lose sync. I've also tried double filtering.
The line is currently interleaved on both downstream and upstream presumably due to multiple re-syncs the other day (even though it was well under the believed limit of 20 per day, as well the ES being well under 2880, for DLM's 'speed' policy). Every so often I also notice blips in the attainable rate on upstream and downstream. For example, in one 15 minute sample the upstream attainable rate might be around 12 megabits, in the next 15 minute sample it might be around 10 megabits, then in the next 15 minute sample and many samples following that it'll stay around 13 megabits for a while. The phone calls can sometimes cause a small spike of ES/SES, even though I'm currently INP 4/3 and delay 8/8 a phone call a family member made this morning caused a re-sync as well as 12 ES and 6 SES on the downstream.
I've done a 'noisy' line test via CIX's control panel (who I have line rental with) and a minute or so later it results in 'Line test OK. Dial tone OK' from Openreach. I have the option of running this test automatically every 4 hours for 24 hours, so I may try that at some point. In the meantime I'm going to swap back to the analogue phone in a moment and switch the DrayTek 2860 with either the ZyXeL or HG612 so I can use DSLstats to fetch more stats such as Hlog and QLN and post those here.
(Watch this space)
Any suggestions in the meantime are welcome.
-
Did you say who your ISP is?
I would assume that you can report this as a PSTN fault, no? Because noise can be heard during phone calls. That is probably the good way to go.
How far have you got with it - reported it to your phone line service provider yet?
-
I haven't reported it yet because it warns me that I could be charged since no fault has been found when running the line test. My ISP is Andrews and Arnold while the line rental is with CIX (also known as ICUK). The noise isn't always there either which would make it harder for me to report it unfortunately, sods law the engineer turns up when the line is temporarily behaving.
-
Ensure you have a corded phone connected to test socket. Use mobile phone to record noise and clicks - note date/time. Have this setup when engineer visits.
Report fault making sure you say it is intermittent but you have recording of what it sounds like. I would argue that should be enough to cover you. By its nature it should be understood an intermittent fault is just that.
I did above with my fault several months ago but luckily when the engineer phoned me to say he was on his way the line went bat crp crazy so he had first hand knowledge of the problem :)
Bumpy ride as numerous issues found by several engineer follow ups but end result a very decent uplift in speeds.
Perhaps an engineer could give feedback on when you visit premises and decide to make a charge?
At end of day it is a gamble though as my provider gave me the same you will be charged speech. I made it clear I was not happy with the speech, I have a fault and the rep tried to calm me down. Just be prepared to fight the charge if one is applied.
-
I see, well I'll try my corded phone directly into the test socket later today (don't want to further upset DLM potentially :P) and see what result I get and record any noise if I hear it.
In the meantime I've connected the ZyXeL VMG1312-B10A and have DSLstatsw monitoring it. Maybe something will show up when I get another loss of sync due to a phone call either being made or received :). I've got the Hlog, QLN and bitloading/SNR graphs but I believe I can't see anything odd on the Hlog. QLN has some spikes but that's just crosstalk I guess, otherwise it looks reasonable I believe.
https://imgur.com/a/a669ftK
-
Doh. I forgot you were an AA customer. Have you run the usual clueless.aa.net.uk tests: “copper line test" and so forth ? What are the other ones that are relevant here - “KBD Diagnostics” and “Run PSTN Test”.
Might as well get AA in on the job then because they will take you seriously, of course, and will actually get things rolling. I don’t think there is any need to be concerned about PSTN vs DSL fault given that it is AA. And after all, we know that a line fault is a line fault - it was just some stuff and nonsense made up to try and make the whole split of POTS vs DSL providers thing make some kind of sense.
-
Doh. I forgot you were an AA customer. Have you run the usual clueless.aa.net.uk tests: “copper line test" and so forth ? What are the other ones that are relevant here - “KBD Diagnostics” and “Run PSTN Test”.
Might as well get AA in on the job then because they will take you seriously, of course, and will actually get things rolling. I don’t think there is any need to be concerned about PSTN vs DSL fault given that it is AA. And after all, we know that a line fault is a line fault - it was just some stuff and nonsense made up to try and make the whole split of POTS vs DSL providers thing make some kind of sense.
Haha yeah, but unfortunately the line rental isn't with AAISP for the troublesome line so I can't run a PSTN test from AAISP's control panel. I ran a test from CIX's control panel though, who I have the line rental with, and it came back as no fault found. I have the option of running an intermittent test every 4 hours automatically for 24 hours which I may well try. I've got the corded phone plugged in at the moment just to try and identify any unusual noise and then record it to help prove there's a problem if an engineer needs to come out with 'no fault found' on the standard line test. On AAISP's control panel I can 'issue service test'. I guess worst case I could contact AAISP about what is happening and see what they advise next.
I've done 'issue service test'.
Test ... Test Description = GEA service test completed and no fault found .
Diagnostic Code = GTC_FTTC_SERVICE_0000, Sync Status = In Sync, NTE Power Status = PowerOn
Down Sync = 57Mbps, Up Sync = 13Mbps
REIN = Not Detected, Bridge Tap = Not Detected
Test Outcome = Pass, Main Fault Location = OK
-
I didn't realise that the appearance of clueless is different if your line rental payments are to someone other than AA. Makes sense of course, if any of this ever does. (In fact, no, it all descended into madness when DSL was first invented.)
When I moved to AA some years ago I moved my line rental from BT to AA just so that there would be no possibility of two companies passing the buck back and forth, indeed I would always be certain that ‘the buck’ would stop at AA. (What is a buck anyway? ???)
-
I've done a 'noisy' line test via CIX's control panel (who I have line rental with) and a minute or so later it results in 'Line test OK. Dial tone OK' from Openreach. I have the option of running this test automatically every 4 hours for 24 hours, so I may try that at some point. In the meantime I'm going to swap back to the analogue phone in a moment and switch the DrayTek 2860 with either the ZyXeL or HG612 so I can use DSLstats to fetch more stats such as Hlog and QLN and post those here.
(Watch this space)
Any suggestions in the meantime are welcome.
It does sound like there is an external line fault, and there is nothing you can do about it, other than ask your CP to fix it.
Meanwhile, I’d not swap any phones, or filters, or modems, just leave it all alone, and report that there is audible noise on the phone line (if there is). If external, it is not a problem that you can fix. But by continuously swapping appuratus you may be confusing the symptoms, maybe giving the impression it is broadband fault rather than a line fault, and making it harder to get agreement that the line itself is faulty.
-
It does sound like there is an external line fault, and there is nothing you can do about it, other than ask your CP to fix it.
Meanwhile, I’d not swap any phones, or filters, or modems, just leave it all alone, and report that there is audible noise on the phone line (if there is). If external, it is not a problem that you can fix. But by continuously swapping appuratus you may be confusing the symptoms, maybe giving the impression it is broadband fault rather than a line fault, and making it harder to get agreement that the line itself is faulty.
Sorry for the late reply. Indeed, it does sounds like it but sadly the test refuses to pick up a problem. I've started an 'extended line test' from CIX's control panel which will run a line test every 4 hours for 24 hours, but I highly doubt it'll find a problem still. DLM intervened last night and has relaxed the error correction on the upstream (from INP 4 delay 8 to fastpath). Downstream is still interleaved but hopefully that'll go back to fastpath within the next few days. The connection is capped slightly in order to try and help encourage DLM to switch everything back to fastpath possibly a little quicker.
At the moment I can't hear any noticeable noise on the phone calls and nobody here is reporting any unusual noise, but at least 50% or more of the time I make or receive a phone call I usually encounter a drop in SNR (especially for the U1 band). I can't imagine this is normal, but at the same time I don't imagine it's something that'll convince Openreach that something isn't right.
See the images at https://imgur.com/a/b2XVGoh - Comments from anyone are welcome. I will contact AAISP next week and see what they suggest too, hopefully by then the downstream will be back on fastpath again and so it should then be easier to see errors on Yukon in the event that I might get plenty of errors. The blips in SNR shown on the graphs are when someone made a call this morning and the most recent one was when I received a brief call.
Also one other thing maybe worth mentioning, the downstream FEC errors have been constantly at the rate shown in the above URL since around 11pm last night, prior to that it was just the odd blips of up to 1500 ish but most of the time just a handful to a few hundred downstream FEC errors.
I've not changed the filter or cables for the last two days or so, the DECT phones (recently purchased BT Advanced Phone Z) are also connected. One last thing I tried recently was to reposition some of the equipment inside my server cabinet in case something was causing some kind of interference. Sadly it hasn't made any difference.
-
Just another update, and probably the final one for today, to say that the FEC errors on the downstream have returned to reasonable levels and there's no more CRC error blips on the downstream at the moment since then. The underlying problem however is still there, whatever that might be.
FEC errors graph: https://i.imgur.com/SGDi3SR.png
I just did a quiet line test on my BT Advanced Z DECT phone and rarely I thought I heard a crackle or hiss (unusual noise pretty much) over about two minutes. Another odd thing was when I first tried to dial 17070 I got no dial tone, but I can't be 100% sure if that was just me having a strange moment with my handset or whether it was indeed no dial tone. SNR did the same thing as before as shown on the graph link to imgur on the post above this one. I will attempt to record the crackle/hiss sound with my mobile phone next as proof and then contact AAISP on Monday to also see what they suggest doing regarding this anomaly. Most likely I guess I'll have to submit a noise fault via CIX's control panel and then hope the Openreach engineer notices something either on their own test(s) or that they also notice potential crackling/hissing or some other unusual noise after a while (assuming they will also do a QLT).
EDIT: I thought I'd see what happens on the Hlog while I'm on the phone doing a quiet line test, U1 band becomes slightly less smooth and I also notice a faint sound of the modem synchronising (is that normal?).
Hlog graph: https://i.imgur.com/spDIGTs.png
-
EDIT: I thought I'd see what happens on the Hlog while I'm on the phone doing a quiet line test, U1 band becomes slightly less smooth and I also notice a faint sound of the modem synchronising (is that normal?).
Hlog graph: https://i.imgur.com/spDIGTs.png
Everything you have described points towards a joint that is showing slight HR or semi-conductive tendencies. The problem will be in locating the joint in question. Often such a joint can be near impossible to find . . . until it goes "hard" and fails completely.
-
Is this Hlog characteristic of HR joint ?
-
Is this Hlog characteristic of HR joint ?
Nothing is ever that "clear cut".
You will, I'm sure, agree that the US1 band shows an abnormal response. Past empirical observations have shown that disturbances in the US bands, often US1, will be present when a circuit contains a non-linear (i.e. semi-conductive) component. The dipping of the observed SNRM whilst a telephone call is in progress (i.e. the result of applying a resistive-inductive load to the pair), along with the observation of "modem-like" audible noises within the audible (telephony) pass-band, are further suggestions.
In this particular case, I am fairly confident that the faulty joint is more semi-conductive than HR. But that may change, with time, as the fault "ripens".
-
The SNRM is high, at 7dB or even 10dB [!]
-
Thanks all for your replies and comments :).
Everything you have described points towards a joint that is showing slight HR or semi-conductive tendencies. The problem will be in locating the joint in question. Often such a joint can be near impossible to find . . . until it goes "hard" and fails completely.
Figured as much, how frustrating lol.
I have recorded some unusual noise, see this audio file (http://bs12.uk/2018-07-01-10_16_54.mp4) (spectrogram of audio file (http://bs12.uk/2018-07-01-10_16_54.mp4.png), for amusement ;)), some crackling noise starts from nearer to 1 minute and occurs more near the end of the call. I will do another recording a bit later today in a quieter room as some traffic may be heard on that recording (assuming the downstream FEC errors remain continuous at around 3k to 10k+ per minute, as that's when the noise is more likely to be heard). This was done on the DECT handsets I recently bought (BT Advanced Z) but to eliminate all doubt I will use the analogue phone for another recording too. I highly doubt the noise is specific to just using the DECT handset, seeing as how the phone call impacts my upstream SNR and causes errors. Each time I made that call the upstream encountered an SNR loss of about 1 to 1.5 dB, along with around a dozen errored seconds and some FEC errors. Interestingly the ZyXeL doesn't lose sync so maybe it can handle the issue better than the DrayTek can. However, I may have to accept there's an issue but can't really report it until it gets worse.
The SNRM is high, at 7dB or even 10dB [!]
The default target SNRM is 6 dB on FTTC/VDSL2, and as I'm unfortunately connected to an ECI DSLAM I don't have much hope of a lower target SNRM being applied by DLM or even G.INP :P.
-
I thought while I had a device with Broadcom chipset connected to the line that's showing an early indication of a fault that I'd try out this Broadcom DSL Diagnostics program. It's interesting.
Here's something that I noticed though: https://i.imgur.com/2dfuf6a.png
It's an SNR graph, however see the tones/bins up to just after the downstream PSD shaping ends (power cutback to co-exist with ADSLx connections). The 'min' is what happens when I use the phone, the 'max' or 'SNR' are when I don't use the phone. Tones after the downstream PSD shaping appear to be unaffected, although I can't see the upstream SNR on that graph sadly and I know it gets a small drop. I don't know if that really helps me any further in identifying where the fault might be however. The unwanted noise so far seems to become noticeable when the temperature cools down (late evening/night, overnight and early to mid morning), as do the continuous downstream FEC errors of around 3k+ per minute.
I wonder if anyone else has really explored the settings or such in the Broadcom DSL Diagnostics program. I tried to use this on the ZyXeL VMG1312-B10A but I had issues doing so, even with supervisor access, so I swapped to a spare HG612 and found it easy to enable on that.
-
I thought while I had a device with Broadcom chipset connected to the line that's showing an early indication of a fault that I'd try out this Broadcom DSL Diagnostics program. It's interesting.
Did you intend the phrase "this Broadcom DSL Diagnostics program" to be a left-clickable link? It seems to imply that I should be able to find/access it somewhere . . . but where, I know not. :-\
-
Did you intend the phrase "this Broadcom DSL Diagnostics program" to be a left-clickable link? It seems to imply that I should be able to find/access it somewhere . . . but where, I know not. :-\
I didn't mean for it to be a clickable link, just the way I worded it as I assumed some people here were aware of such a program. I'm using version 1.43. If someone here doesn't have it then I'll post a link to it.
I'm currently waiting for downstream to return to fastpath, upstream is fastpath. I've capped the speed a bit more to hopefully help encourage it.
-
I didn't mean for it to be a clickable link, just the way I worded it as I assumed some people here were aware of such a program. I'm using version 1.43. If someone here doesn't have it then I'll post a link to it.
The grumpy old kuro neko must have been napping, for I am totally unaware of such code.
Sudden thought . . . Is it something that only runs on BGW (Billy Gates Ware)? If yes, that my be why I have no recollection of such a utility.
-
The grumpy old kuro neko must have been napping, for I am totally unaware of such code.
Sudden thought . . . Is it something that only runs on BGW (Billy Gates Ware)? If yes, that my be why I have no recollection of such a utility.
Yes it's a program which runs on Windows.
https://forum.kitz.co.uk/index.php?topic=16507.0
Also DrayTek have returned my Vigor 2862 which is currently with DPD due for delivery tomorrow morning. Unfortunately the email doesn't say much (e.g. if they found a problem or actually did anything to correct my original problem), but I'm half expecting it to be returned with them unable to identify the problem even though I explained in writing how to replicate the problem and the possible memory leak that it's causing. Hopefully my prediction is wrong. Hopefully they've identified the problem and have corrected it, I'll know tomorrow.
-
Yes it's a program which runs on Windows.
https://forum.kitz.co.uk/index.php?topic=16507.0
Thank you.
Also DrayTek have returned my Vigor 2862 which is currently with DPD due for delivery tomorrow morning. Unfortunately the email doesn't say much (e.g. if they found a problem or actually did anything to correct my original problem), but I'm half expecting it to be returned with them unable to identify the problem even though I explained in writing how to replicate the problem and the possible memory leak that it's causing. Hopefully my prediction is wrong. Hopefully they've identified the problem and have corrected it, I'll know tomorrow.
I await your update, with interest . . .
-
Vigor 2862 was delivered about 30 minutes ago. The serial number matches the one I had originally sent for RMA. There was a sticker on the bubble wrap which said:
Reported Problem Verified: No
Item/Component Replaced: Yes
Product/Firmware Reset/Reflashed: Yes
Tested Okay Before Return: Yes
Notes: -
I guess I'll see what happens in about three days from now. If the original problem occurs again then my only option is to do a temporary workaround to make it so the router reboots every two days and then hope at a later date that a firmware update inadvertently fixes the problem. Fingers crossed the original problem doesn't occur again. I've got it connected to the line which is showing early signs of a fault forming, replacing the ZyXeL and HG612 that I had temporarily been using on that line.
-
@Ixel, I've been playing with the Broadcom tool and there's something may help see the missing part of the SNR effects (on shaping), but you'd need to put the HG612 back on the line.
Put the modem in L3 state (not connected) then if you open the QLN view, then run the QLN monitoring it gives a min and max view of that too.
And if you could run the AFE hybrid response test too, I'd be interested to see the result (your fault behaves similarly to mine, except rain sets mine off)… I really don't understand the output as it says HLog and looks very strange - I just attached it too, rather than describe it.
-
boozy: Could you paste adslctl info --Hlog result?
-
@konrado5: My HLog is fine, but I’m not sure what the graph with HLog marked on it is actually showing. I have an inclination that it’s showing a problem with a joint/cable, just because I can see some of it reflected in the SNRM. I think Ixel may see something similar. If so, that utility is a cool toy :).
-
I'll try this in the next few days. I want to try and encourage DLM to put downstream back on fastpath if possible in the meantime. I also want to see if the Vigor 2862 freezes again.
-
boozy: I'd like to see your Hlog on first 512 tones. My is unusual.
-
boozy: I'd like to see your Hlog on first 512 tones. My is unusual.
30 seconds of searching his previous posts.
https://forum.kitz.co.uk/index.php/topic,21615.msg373514.html#msg373514
-
Beat me to it
-
Unfortunately the DrayTek Vigor 2862 web interface/telnet interface still freezes after a few days of querying DSL statistics, which would likely indicate that there's a memory leak in the firmware. I doubt however I'll get anywhere in being able to prove this to them (I've already tried to explain and prove this with the memory usage stats) so I may as well just accept it as it is and instead have the router reboot automatically every two days. Maybe one day they'll notice the bug by some other means and resolve it. At least the DrayTek Vigor 2860Vac doesn't do something similar.
DLM hasn't restored fastpath on the downstream yet, but I'm wondering if that's because that line is getting a fair number of FEC errors. I can try increasing the target SNRM offset further to try and encourage it to restore fastpath. Before I try what boozy mentioned with the HG612 and then posting some screenshots here I would like fastpath to be restored for the downstream first. If it hasn't returned in a few more days then I'll try that and post some screenshots of the graphs.
-
I'm not 100% sure , but the QLN monitoring one, which may show where the noise from the phone calls affects your line, seems to sync just afterwards with no input or warning - so you may want to bear that in mind, to keep fastpath (assuming you get it back).
-
I'm not 100% sure , but the QLN monitoring one, which may show where the noise from the phone calls affects your line, seems to sync just afterwards with no input or warning - so you may want to bear that in mind, to keep fastpath (assuming you get it back).
There may be a possible solution to that, to either set the allowed profile to one it can't sync with (such as 8c or something) or disable VDSL2 from the allowed modulations.
-
I thought things were stabilising so I reconnected my second line this morning. Sadly in the last hour I've lost sync several times and re-synced. At one point my 'troublesome' connection actually synced at approximately 9M/2M for moment ::) :D. Sadly the line test on the CIX control panel is still coming back as negative and I fear DLM will send its wrath my way overnight due to the number of re-syncs in a short timeframe :P. At the moment my DrayTek Vigor 2862 is connected to my 'troublesome' line, so I can't get a QLN or Hlog to see if much has changed to clearly indicate a problem (though I expect they'd still be alright as I think this is intermittent). However, this is the worst I've had it so far, so I think the fault is slowly developing which is good news I guess as eventually it should show up as a problem that I can report with some certainty of it being found by an engineer.
EDIT: BINGO! Fault detected, 'dis one leg in network' - access not required. Good news? Also syncing at 8141 again.
EDIT 2: Hmm, the trouble report just got rejected... it said: "Trouble Report Rejected - Care level is Total Care, 24Hr access is not provided OR 24Hr access value is 'N' and earliest available and latest available times are not provided." yet it didn't give me an option to specify that. Now I've done a line test again and it's coming back as 'PASS' :(. Re-synced again at 38889 with the phone working normally. Previously there was crackling on a phone call and then nothing at all for a while, now it appears to sound normal and is working again. What shall I do?
EDIT 3: Just wondering if I should call CIX and tell them about the trouble report being rejected due to something regarding 24 hour access not being provided. My line isn't total care either, it's high care, so I find that puzzling. I assume the original trouble report will have notes of some type about the original fault.
EDIT 4: After checking the notes on CIX's control panel, I see it mentions fault location as 'CE' (customer equipment?) which I didn't notice before even though it said fault report advised as 'yes' and that it was in the network. Looking that up I notice CE is the bit between the DP and the NTE, so I'm wondering if it could perhaps be a loose wire behind the master socket causing me this. However, I face a small problem if I'm right... doesn't Openreach charge a hefty fee if it turns out to be something within the boundary of the property (including something as simple as a loose wire behind the test socket faceplate for example)? I know I'm not allowed to touch the wiring behind the test socket faceplate, or so I believe anyway. Possibly a blessing in disguise that the trouble report was rejected if it turns out it's actually something at the master socket.
EDIT 5: After much consideration I decided to take a quick look at the wiring just to see if I could spot any possible issue, knowing I would be charged by the engineer if it happened to be wiring within the premises. I found a wire making and breaking which may well have been the culprit, so redid it and so far all is fine. I did a quiet line test as I opened the box and crackling started immediately, so I think it's fairly certain that it was the cause of the problem. When I redid the wire and put the box back the QLT was quiet, as it should be. If the line appears to be behaving over the next day or two then and DLM takes negative action overnight then I'll attempt to request a DLM reset for the line which was troublesome instead of waiting an eternity for fastpath to be restored.
-
EDIT 5: After much consideration I decided to take a quick look at the wiring just to see if I could spot any possible issue, knowing I would be charged by the engineer if it happened to be wiring within the premises. I found a wire making and breaking which may well have been the culprit, so redid it and so far all is fine.
IDC or screw terminal?
I did a quiet line test as I opened the box and crackling started immediately, so I think it's fairly certain that it was the cause of the problem. When I redid the wire and put the box back the QLT was quiet, as it should be.
Congratulations on achieving a successful outcome. :)
-
IDC or screw terminal?
Congratulations on achieving a successful outcome. :)
The troublesome line uses an NTE5C so it's IDC, just glad that it appears I found the problem and appear to have resolved it. Just need to wait to see what DLM has in store for me tonight :P.
-
The troublesome line uses an NTE5C so it's IDC, just glad that it appears I found the problem and appear to have resolved it. Just need to wait to see what DLM has in store for me tonight :P.
Did you use a proper IDC tool? The screwdriver jimmy is always tempting but it never seats properly.
-
Did you use a proper IDC tool? The screwdriver jimmy is always tempting but it never seats properly.
The NTE5C has cam locks so you don't need an IDC tool or alternatively a screwdriver, it's a tool-less design :). I do have a proper IDC tool to hand though, should I need to use one.
-
Ugh, I thought the problem was gone but I had a couple of loss of syncs this afternoon again, not too long after emailing AAISP to request a DLM reset from TTB (which is pointless if there's still a fault). At one point my connection synced with normal downstream speed but only 0.5mbps upstream. I've changed the modem cable from a 'high quality' cable to a cheapy spare flat RJ11 cable, but I highly doubt that's the reason.
Prior to that I did a line test on CIX twice, first time it came back 'Test Inconclusive - Further Diagnostics Required - raise Trouble Report with OR' with a fault location 'DT' and asking me to do another test. Second time it says 'Line test OK. Dial tone OK'. I'm not sure what I can do at this point as I fear this is an intermittent fault that's just playing tricks with me. I'm waiting to see what AA suggest next.
This is what my connection looked like when it resynced during the problem again, until I resynced it with a change of RJ11 cable:
https://imgur.com/a/sKhShb9
This is what my connection looked like after I resynced it again with a change of RJ11 cable, and generally what it looks like prior to the problem occurring (other than DLM banding and interleaving):
https://imgur.com/a/IQke66h
Line test results:
(https://i.imgur.com/PYCuWRd.png)
On one final note, I did notice last night that my BT handsets lit up and for a second said "line cord error" (aka no phone line) then went back to normal. Broadband however seemed unaffected by that brief blip.
I hope this fault isn't going to be a complicated one to fix.
EDIT: AAISP have got back to me and said it does look like there's a fault on the copper side, and could try forcing an engineer out. I don't know if this would be an SFI engineer but I assume it may well be. I'm waiting to hear for an appointment. Fingers crossed they will find something conclusive and it won't require multiple engineer callouts before something is eventually found (like before at my old address).
This reminds me of my old address all over again :D, just perhaps in a bit of a different way this time.
-
An engineer is coming out tomorrow afternoon, presumably an SFI engineer as AAISP requested it via TTB and only the FTTC is with them (not the line rental). Fingers crossed they can identify a fault and not leave it as "right when tested". Others in the house keep telling me every so often that some phone calls appear to be doing some unusual things (crackling or periodic faint/disappearing audio) and it seems to happen more so in the afternoon apparently. Oddly I don't notice it most times when trying the QLT.
DLM also intervened again today by what looks like increasing the INP/delay to possibly INP 8 / 16ms on the downstream while maintaining the upstream at INP 4 / delay 8ms. SNRM/attainable rate decreases a little whenever a phone call is made or received, approximately 0.5Mbps downstream and 1.0Mbps upstream is lost until the phone call has ended.
Going by my current DSL estimate I'm now also below the impacted low estimate for the downstream by a few megabits and very close to the impacted handback threshold. Upstream is also below the impacted low estimate by roughly a megabit.
I'll have biscuits and a cappuccino on standby (proper coffee beans as I have a superb coffee machine hehe, just like it's made at a coffee shop) :).
-
Assuming anyone's keeping up with the thread, just posting an update.
An SFI engineer visited last Friday, it's one I met last year (the first one). He found a HR fault on his TDR, which he showed me, over a fairly short distance which he resolved. He preferred not to reset DLM and would rather allow DLM to slowly increase the banding etc. I thought the problem was resolved, but apparently there's still something strange happening intermittently.
See https://imgur.com/a/4dTJvxX - A graph of my downstream errored seconds and a spectrogram of the audio file I recorded, however not during when I was getting these errored seconds. Next time I will record one if I catch the downstream errored seconds jumping upwards all of a sudden again. I've put some descriptions below the images there.
As far as I know the downstream's true INP and delay is 6 / 16ms, although the DrayTek reports it as 3 / 9ms. I've known the DrayTek to for some reason display the downstream INP incorrectly (half what it really is). This is possibly something to do with DrayTek modems I guess.
Audio file I recorded: https://drive.google.com/file/d/1wqPv9In2GyJ7QCOhZMQx-8hexJM_q8fq/view?usp=sharing
AAISP are still monitoring the line. The rapid re-syncs aren't occurring at the moment at least. I also had a sudden drop in the attainable rate for downstream and upstream during one 15 minute sample.
Any opinions welcome, e.g. on the audio file or graphs.
-
He preferred not to reset DLM and would rather allow DLM to slowly increase the banding etc.
He would have been told to shove that suggestion where the sun don't shine.
Never in a million years would I smile and nod at the suggestion from an engineer that they are leaving me banded after fixing a fault on their side of the NTE5.
You're more patient/polite than me that's for sure.
-
Bingo. I'm waiting to see what they say but it appears AAISP's test ran by one of the staff has caught the fault red handed.
Test Description = Copper fault found possibly affecting GEA services. Continue submitting trouble report.
Diagnostic Code = GTC_FTTC_SERVICE_1503, Sync Status = Out Of Sync, NTE Power Status = Unknown
Down Sync = 0Mbps, Up Sync = 0Mbps
REIN = Not Detected, Bridge Tap = Not Detected
Test Outcome = Fail, Main Fault Location = LN
Fault Report Advised = Y, Appointment Required = N
My own test via CIX however, for the line rental, indicated fault code 'CE' as 'dis one leg in network'.
I've also recorded the noise on the phone while it occurred, during an unsuccessful attempt to dial 17070 for a QLT. I think I now have a good amount of proof that there's an intermittent problem :).
Audio recording: https://drive.google.com/open?id=1ioCajLMmh2Au7gsSmyF6qKWLnkKmad3y
---
He would have been told to shove that suggestion where the sun don't shine.
Never in a million years would I smile and nod at the suggestion from an engineer that they are leaving me banded after fixing a fault on their side of the NTE5.
You're more patient/polite than me that's for sure.
Next time I will be more forceful hehe.
---
EDIT: I've been advised by AAISP to report it via CIX. This means a line engineer will no doubt come out, test it and probably leave as RWT if the fault isn't present at the time (then a fee?). Ugh.
EDIT 2: Predictable. I raised the fault but got this response back: "Trouble Report is being progressed as a CDTA case". I imagine that means if they find nothing wrong with the QLT and whatever other basic tests they perform on the day then I'll get a 'right when tested' type of charge.
-
Assuming anyone's keeping up with the thread, just posting an update.
Yes, your updates are being read (& considered). :)
-
Yes, your updates are being read (& considered). :)
:)
I'm honestly tempted to cancel the trouble report at the moment because it's a 'CDTA', but I guess I shouldn't as AAISP asked me to report it to the phone line provider (CIX). I believe it went to 'CDTA' because when I made the trouble report the fault no longer registered. The phone sounds normal at the moment and broadband for the moment on the troublesome line is behaving. I have a big fear that the engineer will turn up tomorrow morning, run a QLT and a pair quality test and find nothing wrong and then leave with me incurring a hefty charge.
I have an audio recording and other test results from both AAISP and CIX, as well as an Openreach reference number of the fault test from CIX, which both indicate there was a problem however, so maybe I can somehow convince the engineer. If I end up getting charged with no fault fixed on this occasion then I guess I might just have to wait until the fault significantly develops so that it's not intermittent, I'm certainly not going to risk two or more charges :P.
-
I imported your above sound file into audacity and then played it. I had to set the output to 100% but after a visual and audible review, I am convinced that the recording has not captured any by-product of the defect.
Perhaps leaving it to "ripen" for another month or two might be the best course of action. It also might be worthwhile keeping A&A updated, especially the CDTA status . . . as they suggested that you make the report.
-
I imported your above sound file into audacity and then played it. I had to set the output to 100% but after a visual and audible review, I am convinced that the recording has not captured any by-product of the defect.
Perhaps leaving it to "ripen" for another month or two might be the best course of action. It also might be worthwhile keeping A&A updated, especially the CDTA status . . . as they suggested that you make the report.
Which sound file did you try? The first one sounds relatively normal, not really anything distinguishable. I posted a second one earlier today however which you can't even hear the dial tone properly or the automated voice from 17070, just some strange buzzing and such.
https://drive.google.com/open?id=1ioCajLMmh2Au7gsSmyF6qKWLnkKmad3y - Happened today when the fault initially was identified both by AAISP's GEA FTTC test and CIX's PSTN test.
True. I guess I'll leave the trouble report open as AAISP did advise I report it, and hope it doesn't involve around 150 pounds. If it does then I'll just have to wait until the problem gets worse until one day the line will eventually stop working indefinitely.
EDIT: After much consideration I've decided I'm going to cancel the trouble report. I will wait for the fault to occur again as I'm sure it will at some point and then report it in the hope that the trouble report's own test will also register a fault and as such not submit it as a CDTA with the risk of a hefty charge if no fault is found by the engineer. I know this is probably not what AAISP wants me to do but I'm simply not prepared to take such a gamble. There's a chance the fault should re-occur within the next couple of days again if it follows a similar occurring pattern somewhat.
-
I posted a second one earlier today however which you can't even hear the dial tone properly or the automated voice from 17070, just some strange buzzing and such.
https://drive.google.com/open?id=1ioCajLMmh2Au7gsSmyF6qKWLnkKmad3y - Happened today when the fault initially was identified both by AAISP's GEA FTTC test and CIX's PSTN test.
Ah, I missed that one. :-[ I hear the sounds of an intermittent earth contact fault, coupled with that of an HR or semi-conductive fault. From your description, along with what I do not hear, it appears that the above fault is also coupled with significant loop loss.
I am convinced that there is an intermittent fault but would not like to be the person tasked to find and fix it. :no:
-
Ah, I missed that one. :-[ I hear the sounds of an intermittent earth contact fault, coupled with that of an HR or semi-conductive fault. From your description, along with what I do not hear, it appears that the above fault is also coupled with significant loop loss.
I am convinced that there is an intermittent fault but would not like to be the person tasked to find and fix it. :no:
I seem to be the bearer of difficult phone line faults :D. Indeed I wouldn't want to be the engineer either! I've told AAISP of my intentions and hopefully they will understand my reasoning behind cancelling the trouble report with CIX. I've configured my AAISP account to email and text me regarding line up/down events, so I'll hopefully be alerted when there's potentially a problem again and then hopefully act quick enough to get the trouble report to also successfully identify a fault as part of its notes.
-
If I remember correctly, you can get AA to arrange for their staff to pick up line-down events, with certain conditions presumably, and act on them. I can not for the life of me remember where I saw thus mentioned though.
-
If I remember correctly, you can get AA to arrange for their staff to pick up line-down events, with certain conditions presumably, and act on them. I can not for the life of me remember where I saw thus mentioned though.
Indeed, and this would probably be helpful if the line rental is with them but sadly it's not :(. I can't have the line rental with them as it means the landline phone calls would have to be VoIP and some people here (not myself) prefer having a landline the traditional/common way ::). I have however setup the account to notify me via email and SMS as to when the line goes down and up, which is handy.
Sadly this fault is a tricky beast to catch. The last two occasions where there's been instability the PSTN line test via CIX's control panel has come back as 'LTOK', which I guess means the fault wasn't bad enough on those occasions to be picked up by that test. I have two Openreach reference numbers of past tests which have failed, stating the fault location as CE and the reason as 'dis one leg in network'. AAISP's GEA FTTC test, which they ran on one occasion when they saw re-syncing happening, also indicated a fault, however that said fault location as LN.
Fun times with an intermittent fault ???. Maybe if this continues for much longer and remains as difficult to catch then they may send another engineer, presumably SFI, as an escalated case. I'm not so confident they will do so (understandably) as this was identified on two occasions as a voice fault and not specific to broadband. My line is currently heavily interleaved (possibly D/U INP8/delay16 / INP4/delay8), still re-syncing a few times usually daily, getting some ES or possibly even SES sometimes, is almost under the handback threshold for the current 'impacted' estimate and finally is under the 'low' estimates for 'impacted'.
-
No significant progress sadly, AAISP are now closing the fault their side which is understandable since it's a matter between me and the line rental provider. Unfortunately the line test results are coming up as LTOK at the moment, despite the FTTC/VDSL2 connection remaining heavily interleaved (D/U INP8/delay16 INP4/delay8) and now also under the impacted low estimates. It is still re-syncing at least once, or sometimes a few times, every morning between 8am and 10am. I imagine this is due to the outside temperature rising.
If I've not had much luck getting this resolved in a few weeks from now then I might consider cancelling the broadband on the intermittently faulty line as it's somewhat underperforming (high latency and a fair drop in speed).
I had the idea of ordering a new line but that brings a few issues:
- My current drop wire from the pole only has two pairs which are both in use
- I don't want a third master socket on my wall
My other idea was to transfer the PSTN line rental to AAISP and if possible convert my current landline into a number over their VoIP service, then AAISP are responsible for getting the line fault fixed instead of CIX. Some people here prefer the traditional way of making and receiving calls however, not over VoIP, so it might take a bit of convincing even if that's a worthwhile option to consider.
Any thoughts?
-
I ported my BT number over to AAISP and the process went very smoothly although it took some time. Before I started the transfer I took a VoIP number from them to "experiment" with the setup etc. so the reconfiguration at my end was easy, no surprises on the day. I use a Gigaset N300A, so the AAISP line could be selected instead of the Fixed Line when making calls. At the end of the day there is no perceived difference between the two services in terms of making a call with the N300.
-
I ported my BT number over to AAISP and the process went very smoothly although it took some time. Before I started the transfer I took a VoIP number from them to "experiment" with the setup etc. so the reconfiguration at my end was easy, no surprises on the day. I use a Gigaset N300A, so the AAISP line could be selected instead of the Fixed Line when making calls. At the end of the day there is no perceived difference between the two services in terms of making a call with the N300.
I see, excellent. Well I've started the PSTN takeover process via CHAOS. Expected date is August 7th. I'll configure my DrayTek Vigor 2860Vac for handling the VoIP prior to that however so it's ready. I've used AAISP's VoIP service in the past but never for transferring a landline number to their VoIP service, so that's new to me. Hopefully once the line rental is in their hands then they'll help tackle the intermittent fault my line is suffering with :).
-
Realised I didn't update this since getting the line rental switched weeks ago.
This will likely be a final update as I'm exploring the option of FTTPoD now. I had a desktop quote of around 6,500 GBP + VAT passing 22 premises if I recall correctly. Actual survey quotes so far appear to be around half desktop quote usually so I've gone ahead and paid for a survey to be done :). If it's around 2k to 3k then I'll go ahead (via Cerberus Networks) and cancel my AAISP lines. One of my lines still has an intermittent fault which I can't currently report sadly.
If anyone's interested I'll post my experience of FTTPoD.
-
If anyone's interested I'll post my experience of FTTPoD.
Most certainly, yes, please. :)