Advertisment: Broadband via satellite
Advertisment: Worldwide satellite services from Ground Control Company

www.satsig.net

Satellite Internet Forum.

Welcome, Guest.        Forum rules.
      Home            Login            Register          
Pages: 1

Remote not acquiring into the network.

(Read 2112 times)
G.ke
Member
★★
Offline



Posts: 6
Jan 14th, 2009 at 9:10am  
I have a remote that dropped off the network on its own and now it’s not registering. TX, RX are solid green but NET is off. When I try pushing the option file to the remote using UDP with reset, it doesn’t load nor does it reboot but when I try reset with UDP it reboots. I have seen this issue on about 3 other sites on the same network which I had to move to another network all together.
Kindly advise what could be causing such an issue.


Kind Regards,

AG
Back to top
 
 
IP Logged
 
smlt_vsat
Senior Member
★★★
Offline



Posts: 56
Reply #1 - Jan 14th, 2009 at 11:40am  


I understand that when u rest with UDP it doesnt and offcourse Net LD is not active so so with TCP u cannot reset . Check the option file and also check the current software version of hub is used in modem.

Also try to send a test Frequency and see whether is there any drift in the career from centre using spectrum.

Are u able to see that PP is assigning Time plan to the remote . on telnet to moem type acq on
and see whether u get acq replies

check your RX SNR value (rmtstat)





Back to top
 
 
IP Logged
 
Ex Member
Ex Member


Reply #2 - Jan 14th, 2009 at 11:55am  
The remote is obviously getting its timeplan from the downstream carrier, and it also knows its location either thru hardcode GPS or external GPS providing NMEA...or that TX light would never illuminate.

The way I see it, you may have two problems:

1. Your inability to reset this remote points to a possible  descrepancy/inaccuracy with the Sat0 (Management) interface.  Have the customer/user extract the OPT locally with iSite and confirm that his Sat0 MGMT interface matches that which is populated in the Hub/NMS.  

2.  The lack of NET light indicates a (possible) problem in your uplink chain. The Modem is obviously pushing Lband out of the TX IF port on the backplane of the IDU.  Once you can confirm the presence of that LBAND you need to look at tx cabling and the BUC/SSPA of the system.  More often than not, the lack of a NET LED is indicative of a faulty BUC or the cabling in the uplink chain is either faulty or loose. 

On top of the above, it is also good practice to double check your GEO coordinates with what is populated in the hub NMS.  However, if your GEO was off by a significant number it normally results in ACQ errors on the line cards. That is why it is doubtful to be a problem, but it is still recommended to check it.

Good luck with it.

M
Back to top
 
 
IP Logged
 
G.ke
Member
★★
Offline



Posts: 6
Reply #3 - Jan 14th, 2009 at 2:37pm  
Hello,

The problem was a low transmit carrier from the remote side. Apparently the customer increased the TX cable which notifying me and when 1st asked they denied. 1db test helped establish new power levels. The cable seems to be losing about 4db of power.

Thanks for the responses.

Kind Regards
Back to top
 
 
IP Logged
 
Ex Member
Ex Member


Reply #4 - Jan 15th, 2009 at 1:55am  
That extra cable will certainly affect the initial Tx values.  Glad it you nailed it down. 

Back to top
 
 
IP Logged
 
Pages: 1