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!