08-23-2022 10:29 AM
Upstream | Channel Bonding Value | |||
1 | 2 | 3 | 4 | 5 |
Locked | Locked | Locked | Locked | Locked |
38700000 | 21100000 | 32300000 | 25900000 | 45700000-84950000 |
5120 KSym/sec | 2560 KSym/sec | 5120 KSym/sec | 5120 KSym/sec | 0 KSym/sec |
42.020599 | 40.260300 | 40.770599 | 40.770599 | 57.141663 |
64QAM | 64QAM | 64QAM | 64QAM | OFDMA |
US_TYPE_ATDMA | US_TYPE_TDMA_ATDMA | US_TYPE_ATDMA | US_TYPE_ATDMA | US_TYPE_OFDMA |
Downstream | Channel Bonding Value | ||||||||||||||||||||||||||||||||||
13 | 7 | 8 | 9 | 2 | 3 | 4 | 5 | 6 | 10 | 11 | 12 | 1 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 0 | 0 | 33 | 34 |
Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | ||
633000000 | 591000000 | 597000000 | 603000000 | 849000000 | 855000000 | 861000000 | 579000000 | 585000000 | 609000000 | 615000000 | 621000000 | 279000000 | 639000000 | 645000000 | 651000000 | 657000000 | 663000000 | 669000000 | 675000000 | 681000000 | 687000000 | 693000000 | 699000000 | 705000000 | 711000000 | 717000000 | 723000000 | 825000000 | 831000000 | 837000000 | 843000000 | 352800000 | 922800000 | ||
38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.605377 | 38.605377 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.605377 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.605377 | 38.605377 | 38.605377 | 40.20 dB | 38.67 dB | ||
0.400002 | 0.799999 | 0.200001 | 0.099998 | -0.099998 | -0.200001 | -0.400002 | 0.799999 | 0.799999 | 0.400002 | 0.500000 | 0.400002 | -0.900002 | 0.400002 | 0.400002 | 0.400002 | 0.299999 | 0.299999 | 0.299999 | 0.099998 | 0.099998 | 0.099998 | 0.099998 | 0.599998 | 0.200001 | 0.299999 | -0.099998 | -0.099998 | 0.099998 | 0.200001 | 0.099998 | 0.099998 | -0.900002 dBmV | -1.400002 dBmV | ||
QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | OFDM | OFDM |
08-23-2022 01:31 PM - edited 08-23-2022 01:34 PM
@amd7674 I'm not sure what to make of those power levels on the upstream OFDMA channel. I have seen some crazy values, like 4200000.0 dBmV in other modems' stats.... but yours looks "normal". However, to the best of my knowledge, I'm pretty sure that anything higher than 52 dBmV would put that channel into a failed state. Right now, your stats show 0 KSym/sec, so that confirms that this channel is not carrying any traffic. The question is, should it be?
I would send a private message to @CommunityHelps and ask them to look into this further.
08-23-2022 01:38 PM
Thank you I just PM @CommunityHelps
08-23-2022 01:58 PM - edited 08-23-2022 01:59 PM
@amd7674 just to point out, your post is the first posted evidence that Rogers is starting to use mid-split for the upstream channels. That extends the upstream bandwidth from 5 to 42 Mhz up to 5 to 85 Mhz. So, that might require a higher output level for the channels that run from 42 to 85 Mhz, as your OFDMA channel does. The OFDMA Frequency in your post shows the bandwidth used by the OFDMA channel.
That extension up to 85 Mhz also makes sense given your observation of the 100 Mb/s upstream data rate.
Here's a dslreports thread that comments on the increase in upstream data rates. So far, there's been no discussion or confirmation by Rogers anywhere in the Rogers forum to indicate that Rogers is finally increasing the upstream data rates:
https://www.dslreports.com/forum/r33422455-Increased-upload-speed-coax-DOCSIS
08-23-2022 02:25 PM
@DatalinkThank you very much. BTW... your recommendation for getting PPC FPA6-54 Forward Path Attenuator 6dB. It works very well 🙂
08-24-2022 12:51 AM - edited 08-24-2022 12:52 AM
@amd7674 the FPA6-54 Attenuator is probably the cause of the high OFDMA signal level. You're most likely the first individual who posted a situation involving the switch to mid-split upstream frequencies and existing equipment incompatibility.
That attenuator is essentially a low pass filter, where the low frequencies, from 5 to 54 Mhz pass thru the filter without any attenuation. Anything above 54 Mhz would be attenuated. So, the OFDMA channel which runs up to 85 Mhz is split between unattenuated and attenuated bands within the entire OFDMA bandwidth (45.7 to 84.95 Mhz) with the majority of the OFDMA channel sitting above 54 Mhz.
So, for test purposes I recommend removing the attenuator and then rebooting the modem. After the reboot have a look at the signal levels again. I'd like to see them if you don't mind posting them. I'd bet that:
1. The OFDMA signal level will drop, perhaps as low as 40 dBmV, inline with the QAM channels;
2. Perhaps the symbol rate, which currently sits at zero, will actually show the real value.
The symbol rate sitting at zero makes no sense given the 100 Mb/s data rate that you're now seeing. That might be due to the signal attenuation across the OFDMA band.
With the attenuator removed, run another speedtest to see if there is any change. Its possible that you might see a higher result if the entire OFDMA band is operating as it should.
The other question is whether or not the engineers have done anything with the high signal level output at the neighbourhood node. It would be worth checking at this point to look for any difference between the previous unattenuated levels and where they might be sitting now. Perhaps you don't need any attenuator at all?? Won't know until you check it out.
I had a look for a suitable attenuator and came across the following :
https://www.multicominc.com/product/multicom-mul-fpa85-forward-path-attenuator/
There are two versions, a 3 dB attenuator MUL-FPA85-03 and a 6 dB attenuator MUL-FPA85-06. There is an online store but I wasn't able to find those in the store listing. It might take a phone call or email to determine how much these are and how to buy a couple of these.
Looking at the spec sheet, these attenuators run from 85 Mhz up to 1200 Mhz. They should run up to 1218 Mhz, but, perhaps Multicom is simply rounding down the upper number.
So those attenuators would be compatible with the mid-split (5 to 85 Mhz) configuration that you now have and would also cover the Docsis extension above1 Ghz, for whenever Rogers decides to flip the switch and run the frequency range up to 1218 Mhz.
08-24-2022 09:28 AM
@Datalinkthank you so much.... I'm glad I did mention it. 🙂 I will remove it and re-run the tests and re-post them. Unfortunately, I cannot do it during the day. We are working remotely and kids are at home.... LOL
08-24-2022 12:17 PM
@DatalinkThere you go. 🙂 It seems there is no difference in speed. Removing attenuator helped to lower Power to 51db from 57db (surprise, surprise LOL). Since there is no difference and OFDMA power is under allowed 60db, should I just keep it (put it back) to help to get to "0" for downstream channles? What do you think?
IndexLock StatusFrequencySNRPower LevelModulation
Downstream | Channel Bonding Value | ||||||||||||||||||||||||||||||||||
13 | 7 | 8 | 9 | 2 | 3 | 4 | 5 | 6 | 10 | 11 | 12 | 1 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 0 | 0 | 33 | 34 |
Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | ||
633000000 | 591000000 | 597000000 | 603000000 | 849000000 | 855000000 | 861000000 | 579000000 | 585000000 | 609000000 | 615000000 | 621000000 | 279000000 | 639000000 | 645000000 | 651000000 | 657000000 | 663000000 | 669000000 | 675000000 | 681000000 | 687000000 | 693000000 | 699000000 | 705000000 | 711000000 | 717000000 | 723000000 | 825000000 | 831000000 | 837000000 | 843000000 | 352800000 | 922800000 | ||
38.983261 | 40.366287 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.605377 | 38.605377 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 40.50 dB | 39.05 dB | ||
6.500000 | 6.900002 | 6.300003 | 6.199997 | 5.400002 | 5.400002 | 5.599998 | 7.000000 | 6.900002 | 6.599998 | 6.699997 | 6.599998 | 5.400002 | 6.500000 | 6.599998 | 6.599998 | 6.599998 | 6.500000 | 6.500000 | 6.400002 | 6.099998 | 6.099998 | 6.099998 | 6.699997 | 6.400002 | 6.500000 | 6.099998 | 6.099998 | 6.199997 | 6.199997 | 5.900002 | 5.699997 | 5.000000 dBmV | 4.699997 dBmV | ||
QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | OFDM | OFDM |
IndexLock StatusFrequencySymbol RatePower LevelModulationChannel Type
Upstream | Channel Bonding Value | |||
1 | 2 | 3 | 4 | 5 |
Locked | Locked | Locked | Locked | Locked |
38700000 | 21100000 | 32300000 | 25900000 | 45700000-84950000 |
5120 KSym/sec | 2560 KSym/sec | 5120 KSym/sec | 5120 KSym/sec | 0 KSym/sec |
40.770599 | 39.010300 | 40.770599 | 40.020599 | 51.391663 |
64QAM | 64QAM | 64QAM | 64QAM | OFDMA |
US_TYPE_ATDMA | US_TYPE_TDMA_ATDMA | US_TYPE_ATDMA | US_TYPE_ATDMA | US_TYPE_OFDMA |
08-24-2022 01:10 PM
@Datalink wrote:
@amd7674 the FPA6-54 Attenuator is probably the cause of the high OFDMA signal level. You're most likely the first individual who posted a situation involving the switch to mid-split upstream frequencies and existing equipment incompatibility.
I was wondering about that as well after looking at the specs for that FPA. (Then was unable to log in here (again!) to post.)
The symbol rate sitting at zero makes no sense given the 100 Mb/s data rate that you're now seeing. That might be due to the signal attenuation across the OFDMA band.
With that power level, the channel should be in a failed state and not even come up, so this is not unexpected.
@amd7674 Do you see anything in Troubleshooting > Logs -- Event Logs (Last Week)?
I wouldn't be surprised if you don't; the Ignite gateways "normally" do not log anything useful but I am still curious.
I think somebody also expressed surprise that you were still getting the higher upload speed with the D3.1 OFDMA channel being inactive. I think that this is normal/expected. It should work just like the downstream channels. If your downstream D3.1 (OFDM) channel goes down, the modem should fall back to using the D3.0 channels. You should still have the same upload/download speeds that you were provisioned for, but you may not be able to attain them if too many customers are in the same state as you and there is not enough upstream bandwidth available.
08-24-2022 01:24 PM
@-G-Nothing in event/system logs. Perhaps all of them get wiped out when powering down/up modem. 😛
08-24-2022 02:06 PM
@amd7674 wrote:
@-G-Nothing in event/system logs. Perhaps all of them get wiped out when powering down/up modem. 😛
The only logs that we can see are the Firewall logs (and those are totally useless) and admin GUI logins in the System log. There is nothing in the event logs. It looks like Rogers is (and always has been) blocking us from seeing anything other then "Information" level events, which keeps us completely in the dark when we need to troubleshoot problems.
08-24-2022 02:58 PM - edited 08-24-2022 03:52 PM
@amd7674 fwiw, I'd leave the attenuator off at the present time. Your downstream QAM channels are running from 5.4 to 7 dBmV. I like to see that lower if you were running just the QAM downstream channels, but, thats not applicable here. The two OFDM channels are running at 5 dBmV, which looks ok at the present time. Their not totally out to lunch.
The upstream is an interesting question. Keep in mind that DOCSIS 3.0 allows modems to run 56 or 57 dBmV, don't remember the exact number. However, just because its possible doesn't mean that you would want to do that over the long haul. High power output levels means more component heat, which translates to cooling issues and possible goofy modem issues. The best plan, over the long term is to avoid that. I'll have to do some reading to see what's expected for power levels for Docsis 3.1
For comparison sake, here's the power output levels for three dBmV cases:
Case 1: 40 dBmV at 75 ohms = 0.13 mw
Case 2: 51 dBmV at 75 ohms = 1.68 mw, 12.92 times 40 dBmV case
Case 3: 57 dBmV at75 ohms = 6.68 mw, 3.98 times 51 dBmV 51.38times 40 dBmV case
Each one of those represents the theoretical power output (milli-watts) for the OFDMA channel assuming stepped up output levels from case to case.
So, for 57 dBmV, that runs at 3.98 times the power output when compared to 51 dBmV. So, I'd choose case number two for the time being, just to avoid any component heating issues.
Keep in mind that the bandwidth is much higher for the OFDMA channel. The QAM channels are 6 Mhz wide, the OFDMA channel is 39.25 Mhz wide. Although the power output in the sub-carriers is much lower, the trade-off is the higher bandwidth. What's normal in terms of power output??? Good question!!! All my questions regarding channel configuration have been ignored, so, we're back into a "learn as we go" mode. That's really unfortunate as a small amount of information would really be useful in troubleshooting simple issues.
The symbol rate indicating zero?? Well, that's another one of those engineering questions. Earth to Rogers Engineers: what's the problem with the OFDMA symbol rate? Why is it indicating zero instead of a real symbol rate?
Guess I'll have to take a read thru the DOCSIS 3.1 spec......
So, for now, I'd leave the attenuator off. That should ensure that the upstream OFDMA channel operates as it should and it will help to avoid any component heating issues which would result in strange modem issues. I've sent in a query to Multicom regarding the 85 Mhz attenuator's cost and availability. Haven't heard back yet.
08-24-2022 03:53 PM
@amd7674 I would remove the attenuator (and anything else) and that you may have added and revert back to your "as-installed" configuration. Next reboot your gateway and check your signal levels again. If anything still looks amiss or if you experience any other issues with your service, send a private message to @CommunityHelps and get them engaged.
We have no idea how Rogers even has your area provisioned. They may still be fine-tuning things for mid-split in your area. Rogers may also have your modem provisioned to try to establish the D3.1 upstream channel but also have you configured to only use D3.0 upstream until the dust settles and the OFDMA channel (for all customers) is stable. They certainly would not be expecting customers to have FPA's installed that they did not provide, so your attempts to fine-tune your own service may be complicating things for everybody.
08-24-2022 06:04 PM
08-24-2022 11:27 PM
@amd7674 wrote:
Thank you very much @Datalink and @-G- . I will keep attenuator for now. Also I have MOCA filter (in case my neighbours use MOCA), which should not interfere right? or should I remove that too?
You only need to have a MoCA filter installed if YOU have an active MoCA network in your own home, and that is primarily to prevent those signals from being transmitted out into the neighbourhood cable plant. It will also prevent the ingress of MoCA signals from outside... but if you don't have any MoCA-connected devices in your own home, it doesn't really matter because there is nothing that those signals, at those specific frequencies, would interfere with.
If it's a simple POE filter, not integrated into an amplifier, it shouldn't (?) cause any problems... but I would still avoid having any unnecessary items installed... especially it was not provided or installed by Rogers as part of your current Ignite installation.
In my home, the coax cable that comes in from the street plugs directly into my Ignite gateway, and the Ignite gateway is the only coax-connected device in my home.
08-25-2022 01:54 AM - edited 08-25-2022 02:39 AM
Fwiw, in theory you shouldn't need a MoCA filter. But, I have seen posts where neighbours MoCA adapters have caused issues with modems. Those issues were only resolved when the user in question installed a MoCA POE filter even though he or she didn't use MoCA. I would speculate that would happen if an immediate neighbour who is connected to the same Local Tap was running a MoCA adapter connected directly to the (inbound) external cable. In theory it still shouldn't affect a neighbours modem if the modem had enough protection against high, out of band signal levels, but, that depends on the front end filtering. Maybe some modems aren't built the way that they should be, which would be rather strange as they were designed originally by Intel or Technicolour. Essentially the same designs used by different manufacturers should have resulted in the same signal level performance and out of band protection.
Ok, so, you still have a good reason to remove the MoCA filter. That filter is probably built to run 5 to 1002 Mhz. You have a downstream OFDM channel which is annotated at 922.8 Mhz. That's probably the first usable frequency in the low end of the OFDM band, as a guess. The problem here is that you don't know the upper cut-off frequency. It just might be above 1002 Mhz. One way to find out (maybe) is to call tech support and ask what the upper frequency happens to be. I doubt that first line tech support has the capability to determine that, but, you might get lucky. Community helps should be able to tell you that as they have access to the OFDM MIB data. First line tech support doesn't have access to that same data. That's actually a very good question to ask of @CommunityHelps and I'd be very interested in the answer. So, given the chance that Rogers is, or will soon be running frequencies above 1002 Mhz, its a good idea to remove the MoCA POE filter at this point. If you run into strange issues, you can always experiment with installing the filter once again, with the knowledge that you could potentially do more harm than good given the presence of that upper frequency OFDM band. I've looked around for MoCA filters that start at 1218 Mhz and run up to the upper MoCA limit at 1675 Mhz but I haven't found a suitable candidate. That's an industry problem....
As for the Forward Attenuator, I'd remove that as well as it definitely will cause problems for the lower OFDM band. You're signal levels have dropped by 4 to 6 dBmV from the previous levels with the 4582 modem, so, at this point I'd say that there's no highly compelling reason to keep the Forward Attenuator installed.
The two items worth pursuing would be:
1. send @CommunityHelps a message, asking if your upper OFDM channel runs up beyond 1002 Mhz. If it does, leave the MoCA filter off. If it doesn't you can consider keeping it installed, but, you run the risk of degrading the modem performance when Rogers starts using frequencies above 1002 Mhz for that upper OFDM channel. Its unfortunate that Rogers doesn't post basic information about frequency configuration changes as it they affect customers who use Rogers or other installed amplifiers and potentially, MoCA users.
2. purchase a Forward Path attenuator such as the Multicom FPA85-3 and FPA85-6 attenuators and keep them on hand in case the signal levels move back up towards their previous levels. Those attenuators shouldn't cause any issue with the lower OFDM band. Over time, more companies will make similar attenuators, so, its a matter of keeping an eye open to see who can supply them.
08-25-2022 07:30 AM
@Datalink @-G- Thank you for all your help. I will removed MOCA filter last night. MY XB7 was on/off (losing connection) several times yesterday (late afternoon / evening). I did restarted it last evening and at the same time I removed MOCA filter. Everything it seems "fine" now. I was in contact with Rogers folks via private chat and my event logs (see below from this night) did not reveal any issues. The Rogers Rep offered to take a look at my modem, but I would have to unbridge the modem, which I didn't want to do.
DHCPv4[25383]: 72001001-DHCPv4 Provision - Completed | 2022/8/25 04:43:36 | Informational |
DHCPv6[25485]: 72001002-DHCPv6 Provision - Completed | 2022/8/25 04:43:34 | Informational |
DHCPv6[25485]: 72001011-DHCPv6 - Missing Required Option 82 | 2022/8/25 04:43:32 | Critical |
DHCPv6[25485]: 72001011-DHCPv6 - Missing Required Option 24 | 2022/8/25 04:43:32 | Critical |
DHCPv6[25485]: 72001004-DHCPv6 Provision - 0 Retries Attempted with Last attempt at Thu Aug 25 09:43:31 2022 | 2022/8/25 04:43:32 | Critical |
DHCPv6[25485]: 72001011-DHCPv6 - Missing Required Option 82 | 2022/8/25 04:43:31 | Critical |
DHCPv6[25485]: 72001011-DHCPv6 - Missing Required Option 24 | 2022/8/25 04:43:31 | Critical |
eRouterEvents[25342]: 72003004-eRouter enabled as Dual Stack | 2022/8/25 04:43:29 | Informational |
eRouterEvents[23142]: 72003001-eRouter is administratively disabled | 2022/8/25 04:42:17 | Informational |
eRouterEvents[23142]: 72003004-eRouter enabled as Dual Stack | 2022/8/25 04:42:16 | Informational |
DHCPv4[12939]: 72001020-DHCPv4 - IP Address Released | 2022/8/25 04:42:16 | Informational |
DHCPv6[13073]: 72001011-DHCPv6 - Missing Required Option 24 | 2022/8/25 04:42:16 | Critical |
DHCPv6[13073]: 72001011-DHCPv6 - Missing Required Option 24 | 2022/8/25 04:42:16 | Critical |
DHCPv4[12939]: 72001001-DHCPv4 Provision - Completed | 2022/8/25 02:39:48 | Informational |
DHCPv6[13073]: 72001002-DHCPv6 Provision - Completed | 2022/8/25 02:39:46 | Informational |
DHCPv6[13073]: 72001011-DHCPv6 - Missing Required Option 82 | 2022/8/25 02:39:44 | Critical |
DHCPv6[13073]: 72001011-DHCPv6 - Missing Required Option 24 | 2022/8/25 02:39:44 | Critical |
DHCPv6[13073]: 72001004-DHCPv6 Provision - 0 Retries Attempted with Last attempt at Thu Aug 25 07:39:42 2022 | 2022/8/25 02:39:44 | Critical |
DHCPv6[13073]: 72001011-DHCPv6 - Missing Required Option 82 | 2022/8/25 02:39:43 | Critical |
DHCPv6[13073]: 72001011-DHCPv6 - Missing Required Option 24 | 2022/8/25 02:39:43 |
08-25-2022 08:55 AM
@amd7674 wrote:
@Datalink @-G- Thank you for all your help. I will removed MOCA filter last night. MY XB7 was on/off (losing connection) several times yesterday (late afternoon / evening). I did restarted it last evening and at the same time I removed MOCA filter. Everything it seems "fine" now. I was in contact with Rogers folks via private chat and my event logs (see below from this night) did not reveal any issues. The Rogers Rep offered to take a look at my modem, but I would have to unbridge the modem, which I didn't want to do.
Sorry, it is still unclear to me what happened yesterday. Are you saying that everything is now working well after you removed the MoCA filter and the Forward Path Attenuator?
I don't think that removing the MoCA filter should have caused any problems.
When you modem was losing its connection, was that with the MoCA filter installed or without the filter? Your modem could have been resetting due to problems with the stability of your DOCSIS channels or due to work that Rogers was also doing at the time.
More importantly, is everything stable now? Do you have still have any filters or attenuators installed or do you now just have a simple connection to your Ignite modem with nothing installed in between?
08-25-2022 09:08 AM
@-G- I'm sorry if I wasn't clear 🙂
Yesterday at noon I removed FPA and rebooted the modem. Around 4pm-ish till 9pm-ish the network was very unstable (up and down) and the modem was rebooting/restarting itself sporadically. When I got home around 9pm (I was away for few hours) but my older son told me the internet was up and down. Then I've decided to reboot the modem (praying the problem will go away LOL) and at the same time I removed MOCA filter. Other than event messages I posted above, the network seem to be stable at the moment. Again at the moment I'm running without MOCA and FPA filters. My stats are:
IndexLock StatusFrequencySNRPower LevelModulation
Downstream | Channel Bonding Value | ||||||||||||||||||||||||||||||||||
7 | 8 | 9 | 10 | 2 | 3 | 4 | 5 | 6 | 1 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 0 | 0 | 33 | 34 |
Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | ||
591000000 | 597000000 | 603000000 | 609000000 | 849000000 | 855000000 | 861000000 | 579000000 | 585000000 | 279000000 | 615000000 | 621000000 | 633000000 | 639000000 | 645000000 | 651000000 | 657000000 | 663000000 | 669000000 | 675000000 | 681000000 | 687000000 | 693000000 | 699000000 | 705000000 | 711000000 | 717000000 | 723000000 | 825000000 | 831000000 | 837000000 | 843000000 | 352800000 | 922800000 | ||
40.366287 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.605377 | 38.605377 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.983261 | 38.605377 | 38.983261 | 38.605377 | 38.983261 | 38.605377 | 38.605377 | 40.27 dB | 39.21 dB | ||
5.699997 | 5.099998 | 5.199997 | 5.400002 | 5.099998 | 5.199997 | 5.099998 | 5.800003 | 5.699997 | 3.900002 | 5.500000 | 5.500000 | 5.599998 | 5.500000 | 5.599998 | 5.300003 | 5.300003 | 5.199997 | 5.199997 | 5.300003 | 5.099998 | 5.099998 | 5.199997 | 5.599998 | 5.199997 | 5.199997 | 4.800003 | 4.800003 | 5.199997 | 5.300003 | 5.300003 | 5.199997 | 4.199997 dBmV | 4.500000 dBmV | ||
QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | QAM256 | OFDM | OFDM |
IndexLock StatusFrequencySymbol RatePower LevelModulationChannel Type
Upstream | Channel Bonding Value | |||
1 | 2 | 3 | 4 | 5 |
Locked | Locked | Locked | Locked | Locked |
32300000 | 38700000 | 21100000 | 25900000 | 45700000-84950000 |
5120 KSym/sec | 5120 KSym/sec | 2560 KSym/sec | 5120 KSym/sec | 0 KSym/sec |
41.520599 | 42.270599 | 40.510300 | 41.520599 | 51.641663 |
64QAM | 64QAM | 64QAM | 64QAM | OFDMA |
US_TYPE_ATDMA | US_TYPE_ATDMA | US_TYPE_TDMA_ATDMA | US_TYPE_ATDMA | US_TYPE_OFDMA |
08-25-2022 09:13 AM
The power levels and signal to noise ratios look not too bad. The power levels are a little high for the downstream QAM channels but they shouldn't cause any issues.
Can you post the codeword stats from time to time, just to see how their doing?
Looking at the power levels and signal to noise ratios, they don't explain any issues that you might be having with stability, so, I'm wondering how the uncorrected codewords are doing?
08-25-2022 10:04 AM
@Datalinkwith a pressure:
Unerrored CodewordsCorrectable CodewordsUncorrectable Codewords
CM Error Codewords | |||||||||||||||||||||||||||||||||
26849 | 26669 | 26531 | 26397 | 26282 | 26073 | 25942 | 25786 | 25650 | 25519 | 25405 | 25228 | 25048 | 24891 | 24726 | 24560 | 24418 | 24061 | 23756 | 23607 | 23462 | 23289 | 23175 | 23037 | 22894 | 22762 | 22611 | 22470 | 22340 | 22190 | 22054 | 21922 | 46 | 45 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |