i have iDirect version 6.0.9, currently i'm facing a problem with one of our remote, it's always down (out of the network) for about 2 minutes and this happened every about 30 minutes, there's no scpc error detected
Fact finding. We will need more info, if possible.
1. When you say it goes down, how is this observed? iMonitor?
2. Do you have visibility of that remotes SATCOM statistics when it goes down?
3. What are downstream and upstream SNRs looking like at the time of outage? Does it abruptly fall out of the network or do the satcom statistics report a slow deterioration of the link?
4. Does this happen in an sort of pattern or is it random?
5. Are there other remotes in that network? Any visual indications reported in Imonitor on the remaining nodes (at the time you observe outage on the other).
Sounds to me like your problem is isolated to the node itself. Possibly an IDU problem or failing remote RFT equipment/components.
the event like this: Warning UCP_LOST_CONTACT 5255041 Info UCP!: SO( +8), FO( -5148), PO( +0.0) Error UCP_OUT_OF_NETWORK 5255041 Info ACQ_TX remote_id =5255041 cmd =SWEEP: fo= -2908, fr = 14999, fi = 727
about 3 or 4 minutes later it recovered, link up and this happened again after about 30 minutes. we found tdm lost increasing after remote back to up, this only happened to this site, other remotes is working normal
2. What is the physical location of the remote? Indoor, or outdoor? (read: where is the IDU/ODU located?)
Due to your statement that other remotes are not reporting a problem, your issue is obviously isolated to this single node. Reported TDM Loss could be a couple things, but my initial guess is that your LNB is starting to fail you. That, or you have a problem somewhere in your receive (RF to IF) chain.
However, I am curious of what type of remote it is (3100 with non ovenized oscillator?). Which is why I asked about the remotes operating environment (temps). 3100s can become unstable with radical temp swings. Especially when located outdoors.
on satcom graph, i found that tx power drop slowly (4 to 7 minutes or more) to the initial power level and in the same time tdm lost detected and up c/n drop to 6 dB in about 1 minutes or less. after that power level increase again till up c/n on 8 dB average. but then it happened again periodically.
What you described with the tx power levels increasing and upstream SNR decreasing could be a couple of things.
My gut is telling me your system is poorly peaked on the spacecraft. Poor peaking also points to why your C/N is where it is at (lingering at 8dB). Being poorly pointed, will also cause your modem to work harder to close the link. As the craft moves in its station box your bursts are arriving at various C/N at the hub line card. That hub line card has a UCP (normally set to 9dB in most networks) that EVERY remote must meet. Your remote is having difficulty achieving that 9dB (possibly due to poor peaking) and the NMS is PUSHING UP power (thru power offsets) in an effort to achieve the 9dB UPC network configuration. When you cannot meet the UCP (Uplink CONTROL parameter), read: you are falling short of it (like you are) the NMS will give you power offsets (up to your 1dB comp point) to increase your power (in an effort to nominalize you).
The same concept/process applies if your burst arrival were arriving too HIGH. The NMS would back you down to meet the 9dB setting. Apologize for the dissertation, but just wanted to give you some background.
If the above is in fact happening, your remote is pushing up power until it either 1) reaches the max power setting that the hub set for you - read: your 1DB compression point and cannot increase anymore. Or 2) You are saturating well before and your remote CANNOT push up power enough and your bursts continue to fall short on the UCP due to satruatiuon/spectral regrowth and the remotes carrier becomes unusable.
If the above is truly the case, weather and cloud cover (at the hub and the remote operating location) will be a compounding factor. Weather naturally attentuates the link.
I dont want to get wrapped around possible saturation or your inability to meet the UCP, you very well could have an issue with the rx or tx side of that system. I would start with a good peak/pol/isolation check and see if it resolves your situation. Get a good 1DB compression check while you are at it.
If possible can you provide me with the following information (like you did above):
* need you to copy/paste this info from just before the outage, thru the outage, and after the remote recovers.
1. Downstream C/N 2. Upstream C/N 3. Modem transmit power (actual) 4. Remote Rx power
In addition to the above I would like to solicit your intial tx power level (set by the hub) as well as your 1dB compression point (also set by the hub). 1-4 can be found in the UCP and the REMOTE STATUS tabs of iMonitor. The intial and max power setting canb be obtained from the "General tab" on the control panel for the remote.
Also, if you are a Hub operator, can you porvide the RX POWER of the line cards at the observed time of outage. You can query that info by right clicking on the line cards (that the remote is using) and select "Line card stats" and provide me the rx power for each line card.
1. You say your UCP GREEN (sweet spot) is config'ed to 7-9 dB for upstream. Most use 9dB for the center, you are a dB lower at 8dB. 8dB is a bit low, but considering your circumstances with this customer I would not increase/adjust that ucp window to 8 - 10. It will only make things worse for this customer...because he is having difficulty holding up 7DB. So, hold what you have (7-9dB) for now. Just realize that 9dB is the norm for the UCP (TDMA Nominal). A lot of folks will use 7-9 in an effort to allow customers with inferior BUCs into their network. Setting the UCP to 7-9 (iDS 6.X) buys additional margin for customers who have BUCs that fall a bit short of their link budget/network requirements. It lliterally allows them to shave off a dB of upstream SNR.
2. According to your cut/paste statistical output, this customer's downstream C/N is considerably low. I dont have situational awareness on your link budget, but most VSAT customers shoot for 10.5-11dB of downstream rx SNR (SLA driven!). What are other customers under this same downstream carrier reporting for RX SNR? Are they reporting approx 8dB like this customer? Please advise.
3. You mentioned that initial tx power is -5. What is high max tx value set to (aka the 1dB compression point)? Also, when commissioning a node, do you compression test each of them?
I can see from the above that the remote is pushing up power (+.4) when it falls below the configured sweet spot for the UCP. When it upstream SNR (as seen by the line cards) drops below 7 (as you can see above) the NMS recognizes the low arrival of your bursts and is asking the remote to push up power in an effort to get it back to the sweet spot (which is above 7dB).
You can also correlate the low upstream SNR (under 7dB burst arrival at the line card) with the errors observed on the HLC (I have cut and pasted the above)
4. Your HLCs are concerning. Are these HLCs supporting the same inroute group? (read: are they identical in transmission rate, info rate, and symbol rate) and supporting the same group of remotes in either frequency hop or carrier grooming? Need to know if they are on the same RF downlink chain?
Reason I ask is that rx power is too low. One is reporting approx -47dB and the other is reporting -56dB (your remotes are working harder because of this!)
a. Need to know if they BOTH support the same inroute group and if they reside on the same RF/IF downlink chain? (it is alarming that there is a 10dB variance between the two, and if they BOTH support the same network inroute, then we may need to investigate further).
b. The observed values are too low (attenuated). Do you have any attentuation pads in line on that downlink chain? If the answer is no, you should consider putting in an L-Band amp on the receive chain to get that value closer to -36. In doing so, it will buy you additional power margin on the remote side. As configured, you are severely attenuated on one of the cards and the other is borderline (-48 should be considered the max-threshold for rx power).
Courses of Action:
1. I still recommend that the tech conduct a peak/pol/isolation check on this customer. I think it will resolve most of your problems. 2. Consider pulling any software or physical attenuation (if any exists) on this downlink chain. If none exists, consider putting a small amp in place to get the HLC rx power values where they need to be (target = -36dB) 3. Even with the above recommendations, we should not rule out the possibility of this customer reaching BUC saturation. Recommend you have the tech check what size BUC he is using, and ensure that it is conducive to the link budget for your network. He very well may have an inferior BUC. If you complete COA#2 above (remove atten/add amplification) your remotes should back out in power a few dB (1-2 dB). This may buy you additional power margin for the return path.
Lastly, if all of your remotes are receiving that downstream carrier at approx 8dB, get ahold of controllers and ensure you radiating at contract power. 8dB doesnt offer you much weather margin/flexibility.
