In reply to a post by MHC:

Can you also get a text/screen grab from DSL Stats of the pbParams page especially the section which says:

Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 80000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)

Do one BEFORE you disconnect and one once you have reconnected.

Unfortunately, I didn't see this response before I disconnected so only have the data from post re-connect,

adsl info --pbParams
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 9807 Kbps, Downstream rate = 59618 Kbps
Bearer: 0, Upstream rate = 9807 Kbps, Downstream rate = 55000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2144)
DS: (33,859) (1216,1961) (2793,3813)

The US sync recovered post re-connect (coincidence?!), with US power now at 3.8dBM and some but not all of the U2 tones are now showing in the linked chart.

I performed a quiet line test and there was a distinct hum on the line but oddly, there was also a distant and faint alarm, like when the phone is left of the hook. This has all been reported to IDNet now and an engineer is booked for Monday. They'll be visiting the premises as well apparently.

Paul

In reply to a post by Zarjaz:

If it tests battery, then they should just raise it as an issue with Openreach ... why are they dragging their heels ?

Do you get your voice services from them too ?

Yes, IDNet also provide the voice service (that we don't use). They seemed to be hung up on plugging an actual phone in and testing the line. Like you, I can't fathom why if they've proved there's a demonstrable fault on the line.

Paul

Just to update this one:

A very helpful OR engineer arrived promptly yesterday morning and got straight to work, first testing from the NTE out. I got a little nervous at this point as he couldn't find an issue. That didn't seem to deter him though. Leaving the CPE un-connected, he first re-terminated where the wire from the pole connected to the house wiring. The went off up the road to take a look at the cab. Around 3 hours later he came back and was confident he'd traced the issue to a footway box just down from our house, where an aluminium cable (eek) connected 2 poles.
Apparently when he got to the cab, he plugged in his 'new' tester and it didn't register anything. He then plugged in his 'old' tester that he trusted more and it spiked up to a 10v contact detection, then dropped back and went back up and dropped back and so on. So the fault was intermittent, but frequent.

This is his transcript:
=== === QBC Summary Start ===I completed the ring ahead with the end customer xxxxxxxx and progressed to their premises.End customer advised there is a broadband issue.The line was noise free.I have not identified any issue in exchange or DSLAM.No number porting issue is identified.DeltaR / Autoprotective PQT test performed at NTE back plate.The test failed due to resistance outside permissible range for voice on 08/01/2018.Unable to complete TDR.I have resolved the fault located at the D-side including aerial cables and lead-in / block terminal.There was a fault outside the end customer's curtilage caused by general wear and tear.The fault was fixed by clearing in joint.No additional work was carried out on the end customer's wiring / equipment beyond the NTE at their request and within TRC banding.Final DeltaR / Autoprotective PQT performed at the NTE back plate.The test passed with resistance within permissible range for voice on 08/01/2018.Final PQT performed at the NTE back plate.The test passed on 08/01/2018.Final FastTest completed.The test passed on 08/01/2018 10:27:57.=== QBC Summary End ===.

Admittedly, due to the intermittent nature of the fault, I've not seen a real difference in my connection but maybe DLM has a part to play in that. Will leave all alone for a week or so and see if anything happens.
Now to fix my BQM that is reporting 100% packet loss!

Paul

�They� say that QBC (question based closure) provides clear and easily understood notes for the service providers and their customers ....

And there you go, proving that to be utter nonsense.... it says a lot, but tells you nothing ...

Progress (sigh)

There's also some fabrication in there too. He didn't call ahead for example and the part where it states "there was no additional work carried out on the customers wiring/ equipment at their request", I didn't request anything, neither additional work nor not to do additional work. He just stated it was fixed, grabbed a cup of tea for the road, and left. These are both very minor observations though as I worked from home especially because of the OR visit and had a time slot when they would be there and I didn't need anything other than the fault rectifying.

That aside, when the OR engineer arrived and we begun chatting, he stated that the call was a XXXX (four letter acronym that I forget) which made it sound as though I had insisted on an engineer coming to my house, via the ISP, to look for a possible fault. Not that a fault was found by the ISP and they'd requested his attendance to fix it.

All in all, this has been yet another experience to the detriment of IDNet. They just seem to be a bunch of amateurs who don't communicate amongst themselves, which leads to the customer being badgered for information they've already given.

Paul

In reply to a post by youngsyp:

. . . he stated that the call was a XXXX (four letter acronym that I forget) . . .

Possibly an SFI2, maybe?

That�s the issue with QBC as I see it ... when closing tasks you are offered a choice of pre-populated answers .. none exactly fit the bill.

I suspect the XXXX you mention was a CDTA, conscious decision to appoint... so the service provider can detect no fault on remote testing, yet their customer insists there is one. So I wonder why they ignored the original battery contact they thought they detected ?

It�s all a bleedin� game these days .... and the only folk who suffer in the end is Joe Punter.

Errrm, he said a four letter acronym ?

SFI2 would be three letters and a number

Big sigh!

Edited by burakkucat (Tue 09-Jan-18 18:21:35)

In reply to a post by Zarjaz:

That�s the issue with QBC as I see it ... when closing tasks you are offered a choice of pre-populated answers .. none exactly fit the bill.

I suspect the XXXX you mention was a CDTA, conscious decision to appoint... so the service provider can detect no fault on remote testing, yet their customer insists there is one. So I wonder why they ignored the original battery contact they thought they detected ?

It�s all a bleedin� game these days .... and the only folk who suffer in the end is Joe Punter.

That's the one - CDTA. As to why the fault, observed under two discreet tests, was ignored, I can only put that down to IDNet being inept. I'm just glad the OR engineer was so determined to find and fix a fault otherwise I suspect I would have been charged.

ETA: Cycling the 'Block WAN IP' setting on my Billion seems to have fixed the issue I was having with BQM. The Billion seems to be quite temperamental around that area when the sync is removed and reinstated. At least the method above is simple to work through.

Paul

Edited by deleted (Wed 10-Jan-18 13:19:19)