|
|
| SatSig Topics Index › iDirect Forum: hubs and terminals › Idirect 3100 tx problem |
SatSig topic: Idirect 3100 tx problem(Read 13225 times) |
|
Jul 19th, 2009 at 3:15pm
thank you |
|
Jul 19th, 2009 at 5:16pm
1. Your initial power setting to ensure it isnt too high or too low. 2. Your Lat/Long that is populated in iBuilder (an NMS GUI they use). Ensure that it is accurate. If your LNB and BUC require any DC bias ensure they have it enabled in your options file. Most VSATs (unless they are SNG systems) require 10MHz reference bias and DC voltage for the BUC and DC for the LNB. Ensure that it is enable (if required). 3. If they check all of that and still no luck, check your Uplink cabling. M |
|
Jul 19th, 2009 at 7:44pm
here is the opt file they sent me [OPTIONS_FILE] modem_sn = 90101 modem_type = Remote modem_hardware = 3100 did = 5070837 generated_by = NMS version $Name: NetModem-8_0_2_1 $ is_mesh = 0 disable_options_flash_command = 0 [SECURITY] password = XXXXXXXXXXXXXXXXXXXX (edited by moderator) admin_password = XXXXXXXXXXXXXXXXXXXX (edited by moderator) [NMS] timeout = 20000 server_ip = XXXXXX broadcast_ip = XXXXXXX keep_alive_port_number = 2860 NRD_server_ip = XXXXXXXXXX NRD_remote_status_port_number = 2859 service_monitor_interval = 1000 download_monitor_group = 239.192.0.0 download_monitor_port = 9000 download_monitor_credentials = 1 is_nms_managed = 1 event_server_ip = XXXXXXX event_server_port = 2860 [VLAN] mode = 0 vid = 1 [ETH0_1] address = XXXXXXXXXX netmask = 255.255.255.248 rip_enabled = 0 [ROUTE_1_0] interface = sat0 network = 0.0.0.0 netmask = 0.0.0.0 gateway = 0.0.0.0 metric = 1 [SAT0_1] address = XXXXXXXXXXXXX netmask = 255.255.255.252 rip_enabled = 0 [ETH0] interface = ixp0 phy_count = 1 [LAN] lan_ip = XXXXXXXXXXXX lan_subnet_ip = 255.255.255.248 lan_gw_ip = 0.0.0.0 [MODEM_PARAMETERS] data_port = 0 loopback = 0 interface_type = 0 rx_freq = 1107620000 rx_acqrange = 1800000 rx_bitrate = 8579389 rx_mode = 2 rx_modtype = 1 rx_fecrate = 15 rx_scram = 1 rx_diff = 0 rx_specinv = 0 tx_freq = 1000000000 tx_bitrate = 1267500 tx_mode = 0 tx_modtype = 1 tx_clksource = 0 tx_fecrate = 5 tx_scram = 1 tx_diff = 0 tx_specinv = 0 tx_power_in_dbm = -4.000000 rx_fsd = 110902 tx_spreading_factor = 1 rx_spreading_factor = 1 is_demod2_active = 0 [ACQUISITION_PARAMETERS] fsd = 99884 [UCP] power_uplink_control_processing = 1 max_power_level_in_db = -2.000000 [ODU] music_present = 0 odu_rx_dc_power = 1 odu_rx_10_mhz = 0 odu_tx_dc_power = 1 odu_tx_10_mhz = 1 odu_disable_tx_pwm = 0 [TDMA] tx_watchdog_timeout_in_frames = 2 [TIMEPLAN] fec_blocks_per_outroute_frame = 330 unique_word_len_downstream = 32 symbols_per_inroute_frame = 119977 outroute_fec_block_len = 512 outroute_fec_type = 793 inroute_fec_block_len = 128 inroute_fec_type = 660 unique_word_len = 32 symbols_per_outroute_frame = 675871 num_acq_slots = 1 aperture_traffic = 8 aperture_acq = 1647 num_traffic_slots = 213 payload = 512 skip_slots = 3 [LL] ll_open_active = 1 ll_tx_window = 1124 ll_rx_window_backoff = 1000 ll_rx_window = 1024 ll_t1_timeout = 4000 ll_t2_timeout = 1000 ll_t3_timeout = 5000 ll_t4_timeout = 1500 ll_t1_retry_limit = 5 [SPOOF] spoof_debug_level = 0 spoof_passthru = 0 spoof_timeout = 100 spoof_oos_buffer_size = 64240 spoof_keepalive_timeout_ms = 6000 spoof_fwd_ack_ms_timeout = 200 spoof_fade_timeout = 120000 spoof_reap_timeout = 480000 spoof_syn_timeout = 120000 spoof_max_sessions = -1 spoof_accel_connect = 1 spoof_accel_port = 80 spoof_retx_buffer_size = 105598 spoof_peer_retx_buffer_size = 118107 spoof_merge_on = 0 spoof_compression_on = 0 [MODEM_INSTALLATION] hub_lat = 37.720000 hub_long = 24.040000 remote_lat = 35.751000 remote_long = 43.102000 spacecraft_long = -1.000000 reflector_offset_angle = 0.000000 [FREQ_TRANS] down_translation = 10000.000000 up_translation = 13050.000000 [DEBUG] cpu_util_test_enabled = 0 [GUI_SERVER_PROXY] port = 14599 [SAR] tx_segment_size = 70 tx_passthru = 0 rx_passthru = 1 [POWER_MANAGEMENT] enable = 0 sleep_timeout = 0 [UPSTREAM_VR_1] name = K5625/111/1W virtual_remote_id = 1 parent_gqos_id = 67 priority = 6 cost = 0.500000 cir_bps = 0 max_bps = -1 sticky_cir_enabled = 0 legacy_fairness = 0 [SERVICE_LEVEL_1] name = NMS_ICMP virtual_remote_id = 1 type = priority priority = 100 max_depth_packets = 715 max_depth_bytes = 35790 max_depth_ms = 250 drop_oldest_uis_first = 1 rt_weight = 0.000000 trigger_wakeup = 1 cir_trigger = 1 [SERVICE_LEVEL_1_RULE_1] PROTOCOL = EQUAL 1 DEST_IP_ADDR = EQUAL 192.168.1.3 [SERVICE_LEVEL_2] name = NMS_UDP virtual_remote_id = 1 type = priority priority = 100 max_depth_packets = 715 max_depth_bytes = 35790 max_depth_ms = 250 drop_oldest_uis_first = 1 rt_weight = 0.000000 trigger_wakeup = 1 cir_trigger = 1 [SERVICE_LEVEL_2_RULE_1] PROTOCOL = EQUAL 17 DEST_IP_ADDR = EQUAL 192.168.1.3 [SERVICE_LEVEL_3] name = NMS_TCP virtual_remote_id = 1 type = priority priority = 100 max_depth_packets = 250 max_depth_bytes = 3004 max_depth_ms = 20 drop_oldest_uis_first = 1 rt_weight = 0.000000 trigger_wakeup = 1 cir_trigger = 1 [SERVICE_LEVEL_3_RULE_1] PROTOCOL = EQUAL 6 DEST_IP_ADDR = EQUAL 192.168.1.3 [UPSTREAM_VR_2] name = K5625/111/1W virtual_remote_id = 2 parent_gqos_id = 88 priority = 2 cost = 1.000000 cir_bps = 0 max_bps = -1 sticky_cir_enabled = 0 legacy_fairness = 0 [SERVICE_LEVEL_4] name = ICMP virtual_remote_id = 2 type = priority priority = 100 max_depth_packets = 715 max_depth_bytes = 35790 max_depth_ms = 250 drop_oldest_uis_first = 1 rt_weight = 0.000000 trigger_wakeup = 1 cir_trigger = 1 [SERVICE_LEVEL_4_RULE_1] PROTOCOL = EQUAL 1 [UPSTREAM_VR_3] name = K5625/111/1W virtual_remote_id = 3 parent_gqos_id = 236 priority = 2 cost = 1.000000 cir_bps = 30000 max_bps = 70000 sticky_cir_enabled = 0 legacy_fairness = 0 [SERVICE_LEVEL_5] name = HTTP virtual_remote_id = 3 type = cost_based cost = 0.100000 max_depth_packets = 250 max_depth_bytes = 3004 max_depth_ms = 20 drop_oldest_uis_first = 1 rt_weight = 0.000000 trigger_wakeup = 1 cir_trigger = 1 [SERVICE_LEVEL_5_RULE_1] SOURCE_PORT = EQUAL 80 PROTOCOL = EQUAL 6 [SERVICE_LEVEL_5_RULE_2] DEST_PORT = EQUAL 8080 PROTOCOL = EQUAL 6 [UPSTREAM_VR_4] name = K5625/111/1W virtual_remote_id = 0 parent_gqos_id = 80 priority = 2 cost = 1.000000 cir_bps = 0 max_bps = -1 sticky_cir_enabled = 0 legacy_fairness = 0 [SERVICE_LEVEL_6] name = TCP virtual_remote_id = 0 type = cost_based cost = 0.500000 max_depth_packets = 250 max_depth_bytes = 3004 max_depth_ms = 20 drop_oldest_uis_first = 1 rt_weight = 0.000000 trigger_wakeup = 1 cir_trigger = 1 [SERVICE_LEVEL_6_RULE_1] PROTOCOL = EQUAL 6 [SERVICE_LEVEL_0] name = DEFAULT virtual_remote_id = 0 type = cost_based cost = 0.500000 max_depth_packets = 715 max_depth_bytes = 35790 max_depth_ms = 250 drop_oldest_uis_first = 1 rt_weight = 0.000000 trigger_wakeup = 1 cir_trigger = 1 [ENC] enc_layer_enabled = 0 enc_enabled = 0 enc_mode = 0 peer_mode = 1 auth_level_required = 0 [NET_ENC] id = 1 is_encrypted = 0 [UDP] passthru = 1 force_udp_fullheader = 1 force_rtp_fullheader = 1 payload_comp = 0 max_hdr_comp_packet_size = 180 [COMPRESSION] Threshold = 90 [PAD] partial_passthru = 0 [OOB] mem_low_percent = 75 mem_high_percent = 90 [TX] device_path = /dev device_mode = tdma device_name = tx [RX1] device_path = /dev device_mode = scpc device_name = rx1 [BTP] device_path = /dev device_mode = tdma device_name = btp [SOF] device_path = /dev device_mode = tdma device_name = sof [SATELLITE] min_look_angle = 0.000000 [SYSTEM_TRAY] mode = 1 server = 192.168.1.3 port = 2859 interval = 5000 service_monitor_group = 239.255.255.1 service_monitor_port = 9001 |
|
Jul 19th, 2009 at 8:30pm
I have been running strong for over 6 months and now all of the sudden no net light. I've adjusted my tx power through telnet with no luck. Please post your resolution for me so I can try to fix mine as well. |
|
Jul 19th, 2009 at 9:07pm
1. Contact the TS2 and confirm that the LAT and LONG they have poulated in iBuilder matches that of your location. 2. Since you have a telnet session open, attempt to adjust power yourself (that is, if you have the margin in your opt...which is based on your 1dB compression test...I am guessing you have a db or two, at least). Procedural steps: Telnet in, at the prompt type tx power. Whatever value it yields (-2 for example) add a dB or two to that value by typing tx power -1 (that will add one dB of power). Repeat as necessary. Remember working your way to 0 (zero) is adding power! Since your Tx is intermittent, I am assuming they are sweeping for you (ACQ Sweeping)...because you modem obviously has its timeplan. Long short, I think your problem is one of a few things: - Your initial tx power (in your options file) is too low or too high....and you are falling short of, or exceeding the network UCP. - Your BUC or associated uplink cabling is suspect (possibly faulty) - Your LAT LONG is wrong/inaccurate in the hub (somewhat unlikely, because they would be calling you, because ACQ errors would be racking up on their line cards, and they wouldnt like that). - There is a problem at the Hub/Teleport on their downlink (rx) chain. There is the possibility that something may have changed in TS2's downlink chain (since another customer is reporting the same thing...outage with Rx LED and trying to TX)...TS2 may be having Rx chain or Rx Line card issues. For all we know, their Line Card RX power levels could be heavily attentuated (-60 or more), thus causing all of the customers to "push up power" in an effort to close the link. For what its worth, there is a big difference from -60dB Rx Power (just an example) and the norm of -32 to -36 dB. If something changed in their downlink chain, modems that dont have the extra power margin will be out of the network. If multiple customers are reporting Rx LEDs and trying to transmit, this is certainly a possibility. Heck, for all we know, they may have had to cutover to a smaller dish! Remember what I said about lots of variables in play? I know this last part is probably greek to you, but hang in there...hopefully they will sort it out. |
|
Jul 19th, 2009 at 9:14pm
I am having the same problem, I'm in Afghanistan and have been dealing with Ts2 and the NOC in Dubai as well. The only way I can get a responce from the NOC is complaining straight to Ts2. I have been running strong for over 6 months and now all of the sudden no net light. I've adjusted my tx power through telnet with no luck. Please post your resolution for me so I can try to fix mine as well. If you are in the same network as the gentleman above (look at your opt and see if your carriers match his) and you have already attempted to manually adjust power, then there is a good chance that there is something amiss at the teleport or a problem on their hub. Squeaky wheel gets the grease, call them and send emails until they listen. |
|
Jul 20th, 2009 at 5:13am
|
|
Jul 20th, 2009 at 11:07am
BUC Serial # 100408901203 PN # 1031106-0011 model NJR2784HH the LNB is S/n #00000661 PN # 102457-0001 |
|
Jul 20th, 2009 at 12:13pm
This modem has been on the air previously, correct? Was the BUC you are using on the air as well? If so, we can assume the BUC and associated cabling is good (for now). I tell ya, it is hard to diagnose this without being able to peer into the hub side. The fact that another TS2 customer is on here reporting the same thing (unsure if you guys reside in the same network) is concerning. To troubleshoot/isolate this further, I would want a look at their Rx cards, and GUI network build. Makes me wonder if they have re-configured recently (dish change, changes in iBuilder, anything..). Your problem could be something very simple, but without a look at the hub, it is tough to diagnose. Things you can do in the interim: 1. If manual power adjustments (via telnet) didnt help, reset your modem so it will come back up on the prescribed tx value (as specified by the opt). 2. If you have a multimeter, try to confirm the presence of DC just prior to the BUC (your options file states that you have DC bias enabled for the BUC...so DC should be on that cable) 3. Double check your uplink cabling (unlikely, but it doesnt hurt). 4. Continue trying to make contact with TS2 in an effort to confirm the accuracy of your lat/long (as they see it, in iBuilder). If you get ahold of them, advise them of your symptoms/observations. RX LED is lit, with intermittent Tx. Have them check you initial power setting (to ensure you have enough to get in). Have them determine WHY you are not getting to the Rx cards or getting a tcp socket. Like I mentioned before, it appears they have changed something on the downlink chain (Hub Rx) If I had to guess, I would assume that there was a dish change, or attentuation has been added somewhere. Does your Tx LED stay lit for any considerable time? Can you run the acq on command in telnet and see if you are getting sweeps? I am curious if the system is meeting the UCP. Therefore it would be UP from an RF perspective, but DOWN from a network perspective. If you see ACQ sweeps (scrolling) then you are good. If those ACQ sweeps are NOT there, the system is likely up on RF, but hasnt been issued a tcp socket. Since you have an Rx light (combined with the fact that your tx intermittent), I am assuming that you will see them. You can turn them off by typing acq off. You can type it as it scrolls, once you hit enter they will stop. |
|
Jul 20th, 2009 at 1:42pm
|
|
Jul 20th, 2009 at 2:09pm
Dear Sir, Where are you getting all this? What according to you is an Rx card or a tcp socket? Is this from the satsig.net forums by any chance? There is nothing wrong with our line cards or our own inbound path - otherwise all customers would have the same problem you do. So far, 99% of the users are not reporting any service breaks. The problem is not with the compression test either. We have checked everything on our side and re-checked it again. Your terminal's transmission signal quality is simply too low, most often meaning a problem with antenna alignment. I will quote a post fro mthe very same forums, that helped others many times: you may still be badly pointed on transmit, even with 17 volts on receive. The transmit beam is narrower than the receive beam and you need to centre the receive beam perfectly. This will normally involve moving off, down to say exactly 16 volts on each side and then marking these points and moving the dish mechanically to the middle. It usually takes far longer to peak up than to find the satellite Is there a way to read the trasmitting signal? so that when i am pointing it better i know when i get it? |
|
Jul 20th, 2009 at 2:40pm
How are they confirming your tx signal is too low? Are they dumping acquisition bursts on their rx line cards? Doubtful. Since they are saying that your transmit signal is too low, please get a specan (if you dont have one use iSite) to ensure you are properly pointed. Since they are watching this forum, they need to realize that there is another customer complaining as well. Unsure if you are on the same network or not, but the fact that antoher TS2 customer is complaining is something to note. Either both of you are poorly pointed, or there is something else (underlying) wrong. My suggestion to them is to take an interest in HELPING you get back on line, versus put you on the backburner. Same applies to the other user. Customer Service maybe? TS2, care to comment? Maybe help this guy determine what is wrong? |
|
Jul 20th, 2009 at 4:54pm
BUC Serial # 100408901203 PN # 1031106-0011 model NJR2784HH the LNB is S/n #00000661 PN # 102457-0001 |
|
Jul 20th, 2009 at 6:46pm
their recommendation was to point for less SNR. Im going to give it a shot tonight. p.s. Im in afghanistan, with other Ts2 customers that are not experienceing the same problems. We have issues with signal strength alot though. their solution is ALWAYS repoint the dish.... |
|
Jul 20th, 2009 at 7:01pm
The iSite pointing tool, is the tool I was refering to. It is not a Specan, but it is a "decent" way to peak on the signal when you do not have a specan readily available. If you are seeing 16+, then you are likely peaked pretty well. See if you can improve it any. If not, hold what you have. |
|
Jul 20th, 2009 at 7:22pm
[ added by forum admin... LNB NJR2874H Suitable for input frequency range 10.95 - 11.7 GHz Local oscillator frequency = 10 GHz Output, L band cable, freq range 950 - 1700 MHz. Ref: https://mc.njr.co.jp/eng/products/vsat/ku-lnb/dro900.html ] |
|
Jul 20th, 2009 at 7:32pm
|
|
Jul 20th, 2009 at 9:06pm
|
|
Jul 21st, 2009 at 5:23am
|
|
Jul 21st, 2009 at 12:02pm
Good luck with it. |
|
Email me:eric@satsig.net |