04-08-2022 15:12 - edited 04-08-2022 15:23
The VM resolve team tell me the area 3 high utilisation fault F009369438 has now been fixed well ahead of the scheduled fix date of 30/9/22. But we are still experiencing an unreliable connection. @Martin_N you advised yesterday that the issues would resolve when the area fault was fixed but they haven't - so it seems something else is going on with our Hub 4 connection.
We seem to have half hourly spikes on the BMQ and a poor SNR on several channels. Any suggestions gratefully received
4 | 163000000 | 3.500000 | 32.321487 | QAM256 | 4 |
1 | 139000000 | 3.599998 | 33.956509 | QAM256 | 1 |
2 | 147000000 | 3.400002 | 31.403784 | QAM256 | 2 |
3 | 155000000 | 3.400002 | 31.335388 | QAM256 | 3 |
5 | 171000000 | 3.000000 | 33.376591 | QAM256 | 5 |
6 | 179000000 | 2.299999 | 34.345688 | QAM256 | 6 |
7 | 187000000 | 1.400002 | 35.083549 | QAM256 | 7 |
8 | 195000000 | 0.900002 | 36.609653 | QAM256 | 8 |
9 | 203000000 | 0.900002 | 37.355988 | QAM256 | 9 |
10 | 211000000 | 1.500000 | 37.636276 | QAM256 | 10 |
11 | 219000000 | 1.700001 | 38.605377 | QAM256 | 11 |
12 | 227000000 | 1.799999 | 37.636276 | QAM256 | 12 |
13 | 235000000 | 1.700001 | 37.636276 | QAM256 | 13 |
14 | 243000000 | 1.299999 | 37.636276 | QAM256 | 14 |
15 | 251000000 | 1.299999 | 36.609653 | QAM256 | 15 |
16 | 259000000 | 1.799999 | 37.355988 | QAM256 | 16 |
17 | 267000000 | 2.099998 | 37.355988 | QAM256 | 17 |
18 | 275000000 | 2.700001 | 37.355988 | QAM256 | 18 |
19 | 283000000 | 3.200001 | 37.636276 | QAM256 | 19 |
20 | 291000000 | 3.599998 | 38.605377 | QAM256 | 20 |
21 | 299000000 | 3.500000 | 38.605377 | QAM256 | 21 |
22 | 307000000 | 2.500000 | 37.636276 | QAM256 | 22 |
23 | 315000000 | 1.799999 | 37.355988 | QAM256 | 23 |
24 | 323000000 | 1.599998 | 37.636276 | QAM256 | 24 |
25 | 331000000 | 1.599998 | 37.636276 | QAM256 | 25 |
26 | 339000000 | 1.500000 | 37.636276 | QAM256 | 26 |
27 | 347000000 | 1.599998 | 38.605377 | QAM256 | 27 |
28 | 355000000 | 1.700001 | 37.636276 | QAM256 | 28 |
29 | 363000000 | 1.799999 | 38.605377 | QAM256 | 29 |
30 | 371000000 | 2.099998 | 38.605377 | QAM256 | 30 |
31 | 379000000 | 2.299999 | 38.983261 | QAM256 | 31 |
Channel Lock Status RxMER (dB) Pre RS Errors Post RS Errors
4 | Locked | 32.321487 | 1022466 | 0 |
1 | Locked | 33.956509 | 331511 | 0 |
2 | Locked | 31.403784 | 3659342 | 0 |
3 | Locked | 31.335388 | 4751173 | 0 |
5 | Locked | 33.376591 | 156370 | 0 |
6 | Locked | 34.345688 | 39573 | 0 |
7 | Locked | 35.083549 | 16929 | 0 |
8 | Locked | 36.609653 | 13036 | 0 |
9 | Locked | 37.355988 | 14329 | 0 |
10 | Locked | 37.636276 | 13189 | 0 |
11 | Locked | 38.605377 | 13970 | 0 |
12 | Locked | 37.636276 | 16840 | 0 |
13 | Locked | 37.636276 | 25927 | 0 |
14 | Locked | 37.636276 | 41943 | 0 |
15 | Locked | 36.609653 | 52659 | 0 |
16 | Locked | 37.355988 | 45200 | 0 |
17 | Locked | 37.355988 | 37160 | 0 |
18 | Locked | 37.355988 | 25571 | 0 |
19 | Locked | 37.636276 | 18691 | 0 |
20 | Locked | 38.605377 | 16950 | 0 |
21 | Locked | 38.605377 | 20746 | 0 |
22 | Locked | 37.636276 | 33072 | 0 |
23 | Locked | 37.355988 | 53523 | 0 |
24 | Locked | 37.636276 | 78104 | 0 |
25 | Locked | 37.636276 | 102274 | 0 |
26 | Locked | 37.636276 | 106381 | 0 |
27 | Locked | 38.605377 | 113443 | 0 |
28 | Locked | 37.636276 | 125319 | 0 |
29 | Locked | 38.605377 | 123963 | 0 |
30 | Locked | 38.605377 | 126334 | 0 |
31 | Locked | 38.983261 | 121600 | 0 |
33 | 96 | 4K | 1880 | QAM2048 | 759 |
Answered! Go to Answer
04-08-2022 15:29 - edited 04-08-2022 16:00
Those spikes on the BQM I believe are due to the regular Samknows speed tests that the Hub is performing.
Certainly no evidence of OU on that BQM.
One or two down channels have low down power levels that may be giving issues
Might be worth resetting the hub like this
_________________________________
Switch the Hub off and unplug it from the mains supply for five minutes. Whilst it's off, do a quick check that all of your coax and ethernet cable connections are in nice and "finger" tight - at the Hub and wall box and also at any connectors etc. Ensure there are no “unterminated cable loose ends. Disconnect all the connections and reconnect to be sure. Also check that the internal wiring is ok with no kinking or chaffing, check that all looks good with the outside cabling and wall box (no “staples, etc.,) piercing the cables. Then switch the Hub back on and leave ~5 minutes
When all done, check back in the settings and ensure that the RS error counts and T3 errors have all reset to 0. Then check every hour or so to see if they start reappearing - they shouldn't.
04-08-2022 15:28 - edited 04-08-2022 15:29
here is the Network log on the day of the area fault fix at 3 pm:
Tue Aug 2 08:24:33 2022 | 3 | SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Aug 2 08:24:38 2022 | 5 | Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Aug 2 08:27:27 2022 | 3 | Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Aug 2 13:15:40 2022 | 4 | Missing Mandatory MDD TLV on primary DS Channel;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Tue Aug 2 13:15:56 2022 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
And the upstream data if it helps
Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID
1 | 60300000 | 44.020599 | 5120 KSym/sec | 64QAM | 1 |
2 | 39400000 | 43.270599 | 5120 KSym/sec | 64QAM | 4 |
3 | 53700000 | 43.520599 | 5120 KSym/sec | 64QAM | 2 |
4 | 46200000 | 42.770599 | 5120 KSym/sec | 64QAM | 3 |
Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts
1 | US_TYPE_STDMA | 0 | 0 | 0 | 0 |
2 | US_TYPE_STDMA | 0 | 0 | 0 | 0 |
3 | US_TYPE_STDMA | 0 | 0 | 0 | 0 |
4 | US_TYPE_STDMA | 0 | 0 | 0 | 0 |
04-08-2022 15:29 - edited 04-08-2022 16:00
Those spikes on the BQM I believe are due to the regular Samknows speed tests that the Hub is performing.
Certainly no evidence of OU on that BQM.
One or two down channels have low down power levels that may be giving issues
Might be worth resetting the hub like this
_________________________________
Switch the Hub off and unplug it from the mains supply for five minutes. Whilst it's off, do a quick check that all of your coax and ethernet cable connections are in nice and "finger" tight - at the Hub and wall box and also at any connectors etc. Ensure there are no “unterminated cable loose ends. Disconnect all the connections and reconnect to be sure. Also check that the internal wiring is ok with no kinking or chaffing, check that all looks good with the outside cabling and wall box (no “staples, etc.,) piercing the cables. Then switch the Hub back on and leave ~5 minutes
When all done, check back in the settings and ensure that the RS error counts and T3 errors have all reset to 0. Then check every hour or so to see if they start reappearing - they shouldn't.
on 04-08-2022 15:36
Thanks - will turn hub off this evening
I haven't set Sam Knows up to do this speed checking - does VM arrange for this? Do I need to stop it and if so how?
I think an engineer is coming on Monday so will ask him to look at the low downstream power levels if they persist.
on 04-08-2022 16:01
on 04-08-2022 16:19
The half hourly spikes have only been since 30 July so for us it is a new thing!
on 04-08-2022 17:06
04-08-2022 17:26 - edited 04-08-2022 17:27
I don't mind - it is just so odd VM didn't do this and then suddenly started doing it at the end of July! Mystery.
on 08-08-2022 09:44
update
Engineer has just been - these spikes are to do with the poor SNR... another engineer will look at amp in the street to try to fix
on 10-08-2022 10:44
Thanks for the update @2tw2, have we been able to offer a date as to when the follow up engineer is due?
Kindest regards,
David_Bn