Thanks again for the input everyone.

the "freed-up" ADSLx equipment is being used?

Interesting thought but it's definitely ADSL2+. I removed the secondary DP cover and the Quinn engineer had left it in a state - plenty of loose bare wires and bundles of cables. I tidied up and the modem resync'd at 12mbit, presumably due to lower noise.

You mention primary and secondary DPs - are they fully linked and documented?

Good question, I believe neither fully linked or well documented beyond the diagram on the inside of the secondary DP. The engineer claimed he found a spare pair that went straight to the cab, but this seems unlikely in a secondary DP.

Why would a supplier get the exchange links in place for ADSL if they were to be immediately superceded by FTTC/VDSL.

Makes no sense but that is how it seems to be.

Completely agree. Waste of both ours and OR's time.

Regards the modem and line stats:
Model HG533 using TalkTalk customised firmware.
Upstream SNR 11.7/Downstream SNR 11.1.
Upstream attenuation 19.3/Downstream attenuation 36.

Anything else worth reporting, please let me know.

In reply to a post by eckiedoo:

Could it be that there is ADSLx equipment being freed up in the Exchanges, so to get an "improved" although not final service to the customer, the "freed-up" ADSLx equipment is being used?

Would this also make it easier for OR to assess the line quality, from the Exchange, by noting the speeds etc achieved by ADSLx?

No use whatsoever. The cabinet is close by and the exchange a distance away so overall line quality information is worth next to nothing.

Jumpering for ADSL at the exchange will need to be removed later as it could/will cause issues with the VDSL service - so who picks up that cost? To me a totally pointless provision ...

Jumpering for ADSL at the exchange will need to be removed later as it could/will cause issues with the VDSL service

I'd have to disagree. My VDSL service ran for a year and a half till it was ceased (long story) at that point I could still gain sync with my original ADSL port, all to no detriment of the VDSL service.

It is entirely normal for the ADSL ties to be left in place after the circuit goes FTTC, they are only recovered if required for another customer.

Since the OP went with TT, then the ADSL sync and voice will be coming from the same equipment in the exchange, then throughout the Openreach TAMS ties, so there's nowt to remove.

Thanks for all the input. Unfortunately the saga continues.

A second Quinn engineer arrived Wednesday, fitted MK2 faceplate and supplied ECI modem, advised tests showed 80/20, VDSL sync'd fine... but no internet connection.

Have spent hours talking with TT engineers, who seem unable to determine the fault. Essentially they can see the connection all the way up to the OR modem, but the HG533 can't auth (tried two routers and two laptops direct into the OR modem). It has been suggested the auth issue is at the exchange, but they seem reluctant to ask OR to fix (presumably because it costs).

It's a month since we ordered the connection, I'd really appreciate any ideas what this might be!

In reply to a post by adammde:

Thanks for all the input. Unfortunately the saga continues.

A second Quinn engineer arrived Wednesday, fitted MK2 faceplate and supplied ECI modem, advised tests showed 80/20, VDSL sync'd fine... but no internet connection.

Have spent hours talking with TT engineers, who seem unable to determine the fault. Essentially they can see the connection all the way up to the OR modem, but the HG533 can't auth (tried two routers and two laptops direct into the OR modem). It has been suggested the auth issue is at the exchange, but they seem reluctant to ask OR to fix (presumably because it costs).

It's a month since we ordered the connection, I'd really appreciate any ideas what this might be!

I had a similar issue on my line. Fortunately, I was using a Fritz!Box and had a detailed log to help with the diagnosis. The problem was a CHAPS authentication failure. A SFI engineer changed the modem and faceplate, and carried out a 'lift and shift'. The BTOR engineer could do no more and the problem was referred back to BTW. Eventually, my ISP persuaded BTW to carry out a radius server rebuild which I was told is similar to a 'cease and re-provide'. I have had no issues since the rebuild was carried out. The challenge is getting BTW to agree to do it.

Sorry to hear it was such a pain for your fix, it does sound similar... Currently battling with TT to push it up the food chain.

It's somewhat comforting that you've had no issues since resolution though!

Eventually, my ISP persuaded BTW to carry out a radius server rebuild which I was told is similar to a 'cease and re-provide'. I have had no issues since the rebuild was carried out. The challenge is getting BTW to agree to do it.

This sounds about right for the OP's fault, the only difference being that there's no BTW involvement for a talk talk service.

My advice to the OP, ask TT to raise an SFVA task (Super Fast Visit Assured) The engineer needs to make sure (via a co-op call to the DCoE) that the circuit is built correctly, BBEU number, S tag and C tag etc. If this is correct, then TT need to strip out and rebuild the circuit their end.