Again thanks for the comment - So based on the Issues being noted - no suggestions as to the Actual possible cause?

1. Failure to SYNC on a SOGEA Line
2. Loss of Service on VDSL Controller when a "Clear Counters" command is issued - this is noted on Both C887 and C927

Relevant condition does not occur when connected to any other FTTC based service.

Thanks and noted your final comments - just one point of address based on your Point 3

PCP-1 has a DSLAM on the Opposite side of the Road its a ECI 128/256 FTTC cabinet

Clearly noted on the left hand side of the road.
https://www.google.com/maps/@53.6828941,-1.8437895,3...

Fully aware that the "Test Side" routes copper to the exchange.

Thanks again

The further information that you have provided is useful but inconsistent.

You need to stop being fixated on this estimated line length value that the router states when not even syncing. You can disregard it, estimates are just that and not accurate.

I tend to agree with the comments @dect has stated in his reply, in particular the fact that the copper goes back to the exchange but the VDSL signal moves over to fibre at the FTTC cabinet.

Looking at the router stats you have provided for the 80/20 service these are not the same as the previous data you gave which as I thought were for a much shorter line probably in sync at the full 80/20 which would explain the high SNRM values so I am ignoring that data.

The stats for the Cisco show the 80/20 service in sync :-

DS Channel1 DS Channel0 US Channel1 US Channel0
Speed (kbps): 0 64501 0 16315
Noise Margin: 6.1 dB 6.0 dB
Line Attenuation: 16.7 dB 0.0 dB
Line Attenuation(dB) by frequency band 11.4 28.3 44.7 5.4 23.0 36.5 N/A

That looks perfectly normal for a line around 500 metres to the cabinet, my line is around 400m and the attenuation is 15.1dB

For the 40/10 service, I have no idea why you changed to the lower speed.

I notice this is using a different Cisco modem/router

DS Channel1 DS Channel0 US Channel1 US Channel0
Speed (kbps): 0 39998 0 8496
Noise Margin: 11.2 dB 6.1 dB
Line Attenuation: 0.0 dB 0.0 dB
Line Attenuation(dB) by frequency band 11.1 28.3 46.0 5.2 23.1 36.4 N/A

Again it all looks correct, the upload is bit below the expected 10Mbps but it is different firmware to the previous stats. Broadcom based modems sometimes don't show upload attenuation, this one doesn't show anything for the combined attenuation figures but the per band values are very similar to the previous stats.

I am struggling to understand what your actual problem is. You have a working connection that could be running at 64.5Mbps download if you had stayed on the 80/20 service.

The only thing that you seem to think is a big problem is that the Digi router fails to sync and you have come to the totally incorrect conclusion that it is out of range of the DSLAM.
The router stats from the Cisco devices show that you are still connected to the same cabinet as I stated in my previous reply.

The Digi Transport WR44 router is a bit of an odd device and seems to require a lot of custom configuration to work on BT FTTC. Perhaps there is some small change on a SOGEA service that has stopped it working, I don't know what that might be and I'm 100% sure no Openreach engineer will have a clue. They will just say use another router.

Edit: I have seen your later posts are you saying the service does not work with the Cisco routers?
I have no idea what a clear counters command does or why it should drop the connection.

Edited by Realalemadrid (Fri 19-Feb-21 13:54:06)

Fully aware of the ECI cabinet connected to PCP 1 (which you are connected to), I was referring to the fact that you kept talking about a DSLAM at the MYELL exchange so I was making a point of stating where the nearest DSLAM to the exchange is and what PCP its connected to, I was in no way trying to say you was connected to it (if anything I was saying the opposite).

Again thanks

For the Status provided the following was relevant at the time of when the status was noted

The common access service was used for both.

SOGEA 80/20 Service - CPE Connected Cisco 927
SOGEA 40/10 Service - CPE Connected Cisco 887

The reason for change in speed was to at the time emulate the Known working SYNC speed
I agree that only changes that element but having spoken with my CP the profile associated was set to "SuperStable"

The only difference between FTTC with a PSTN service on the same pair, and a SOGEA service, is the lack of PSTN.

Both are connected to the exact same DSLAM. The DSLAM works the same way for both.
The DSLAM isn't even aware it's a SOGEA service.

There are also no VDSL2 DSLAM's in exchanges so that isn't even possible.

On both services the xDSL link is between your modem and the DSLAM next to your PCP.

On normal FTTC the E-Side (copper between cabinet and exchange) is only used for PSTN (voice) and for line tests.
With SOGEA the E-Side is still physically connected but this is only for line tests from the TAM's in the exchange.

If you migrate from a bundled FTTC+PSTN service to a SOGEA service then an engineer doesn't even need to visit your cabinet.
SOGEA continues on the exact same port in the DSLAM, with the same E-Side pair running to the exchange.

There is no way that SOGEA could be delivered from the exchange, or even from a different PCP.
Your line only runs to 1 PCP.

It's very strange that you are experiencing differences in how CPE syncs on a SOGEA service compared to a bundled FTTC+PSTN service.
It should make zero difference, and does make zero difference for every other SOGEA line I've seen.

I would ignore any comments from ISP's who mention broadband coming from the exchange.
ISP's have been making such comments long before SOGEA was a thing.
It's just a lack of understanding from the Customer Service rep as to how FTTC works, mixing it up with how ADSL works.
They have been doing this for years.

I agree that only changes that element but having spoken with my CP the profile associated was set to "SuperStable"

Is it a business line?
I've only seen SuperStable used on business ISP's.
It's the DLM profile used and it prefers Interleaving over fastpath on ECI cabinets.

BT residential usually use Standard, and occasionally stable. I've never known them to use SuperStable.

Edited by j0hn83 (Fri 19-Feb-21 16:39:59)

Thanks John

I could not agree more - we have migrated services from ADSL2+ to SOGEA and have not noticed the issue I am seeing on my Line.

All migrated services have the same CPE Model Cisco 887, IOS and Firmware - we have a mixed estate and are no conducting testing on the other vendors and models.

I have another SOGEA service that is bein installed to a collogues location - where we will conduct the same testing. I am hoping that rules out the issues I am noting on my line.

The track of where the service terminated - started with the Original Engineer - I have been in contact with Openreach - trial support and they have confirmed I am connected to the DSLAM associated with PCP-1.

The issue is OR provide the local services -
BTW - Provide the Backhaul to the CP
CP - Controls the Service and has the ability to set/change profiles associated with the service.

However I have to state each have been helpful - but cannot provide a reason for the issues being noted.