| Attachment | Size |
|---|---|
 graph_image.php_.png | 51.12 KB |
| return-spec.png | 47.73 KB |
I have a node that has a SNR issue. The SNR never peaks 26dB but always holds steady at 25-26dB while my other nodes hold 34-36dB. We use all SA/Cisco Gainmaker 870 gear. Checking the Port codeword errors and corrects it is our lowest error rate % port "Peaks 1.04% correct / 0.01% uncorrect" and thats only for a matter of a few minutes. This strikes me odd, so we hooked up our meter to the return and you couldn't ask for a more ingress clear return. The entire span from 5-55Mhz looked like this......
(See Attached SNR-spec Picture)
Our Upstream configuration follows all our other ports as the following :
Upstream Frequency 32Mhz
Channel-Width 3.2Mhz
TDMA-ATDMA Mix 16QAM / 64QAM
I can change the modulations to QPSK or go to 32QAM / 64QAM with no difference in the SNR. The only way to make it chance is to adjust the Width. Going to 1.8Mhz will increase our SNR to 28dB and going 6.4Mhz will decrease it to 20-23dB
Any Suggestions?
Attached is what most of our other nodes look like.
what upstream frequency are you using?
If you have really old plant you could have some equalizers that only pass < 30 Mhz which would affect certain legs of your plant and drag an otherwise clean nodes SNR down. You can check by moving the return carrier so the whole carrier is below 30 Mhz.
Is your upstream pre-equalization turned on?
We are using all new SA/cisco gainmaker 870mhz gear. All eq's are 5-42. Yes pre eq is turned on
What brand of return eq's did you stick in all that gainmaker gear? I've had some off-brand that I found were shaving the top edge of my spectrum off. It didn't look like much, but the carrier hated it, it was enough that I had to move my carrier down a few mhz from the edge or the modems would not come online, have you hooked up a sweep on the return yet?
Hi, if you send me a output from the Pre-Equalizer from one of the affected cable modem I can create a Tap-View for you. Then we might see some issues.
e.g. SNMP community = public, CM-Mgmt-IPv4-Address: 10.0.0.22. Please adapt for your settings:
snmpbulkwalk -v 2c -c public 10.0.0.22 1.3.6.1.2.1.10.127.1.2.2.1.17
After a walk there should be some output like this:
SNMPv2-SMI::transmission.127.1.2.2.1.17.2 = Hex-STRING: 08 01 18 00 FF FE FF FD 00 01 00 07 00 06 FF F6
FF FC 00 0F 00 06 FF E2 FF FB 00 30 00 01 FF 8E
07 FA 00 19 00 2E 00 07 00 12 FF E2 FF FE 00 11
00 07 FF F5 FF FC 00 09 00 05 00 00 00 04 00 04
00 06 FF FB 00 02 FF FF 00 01 FF FC 00 03 00 04
00 03 00 07 00 03 00 06 00 04 00 02 00 00 FF FF
00 02 FF FA
Best regards,
wittmann
I think I have figured out our issue.... After consulting with my tech's and they swearing that the node was clean on the spectrum, which I have verified. At a closer look reading right off the laser, sure enough there was nothing -40dB noise floor but the signal for the modems were coming in around 3dB... I increased the power-level to +6 on the CMTS and our modems come in around 9dB now and our SNR jumped from 26 to 30dB. Further increasing this number to +12, +15 increased our snr up to 36dB, but with the ill effect of max power on modems. This was telling me someone was lazy when aligning this node. I personally went out the node to check our level's there "after resetting the cmts back to 0". Sure enough we had a 20dB pad on the input return of the node and a 0db Pad on the output return. Meaning if Modems are leaving the node at +3dB then the reverse engineer the signal and it would look like this..... ~+3dB Input of Node > 20dB Pad (Signal now -17dB) goes through the interstage amp leaving at > ~+3dB > 0dB Pad then to the Tx laser. The low signal going through the amp was causing the problem. I have my tech's now going through this node. We look for having at least +22dB on the return hitting the amps with a output value of +35dB. We are also changing everything over to Fiber to feeder making this a lot easier for them to align. (Node + 2 Amps Max)
20db pad on input will sure do it! IMHO, anytime someone is balancing a node's return, they need to be on the phone with the headend, because thats about the only way you can correctly optimize a return link.
What is docsIfCmStatusEqualizationData? and What is Tap-View?
We use the standard SA pads / EQs... Our Roll off starts at 39Mhz and go flat at 41.5Mhz. Moving Freq. does not help nor change the SNR reading until you get to about 10Mhz then it goes downhill fast.
After fixing the return alignment this is what the node looks like. "We have the Uncorrect CW * 10 so they show up on the graph better"
Doesnt get much better than this.....
Thank you for taking the time to post your solution
Yep. Looks good.
I learned years ago that if someone "swears up and down" they checked something "inside and out", that's usually code for, "Yeah. I think I may have driven past that node last week. Looked OK from the ground." ;-)