hello i have a idirect 3100 that was given to me and i am trying to hook it up with ts2. i have a rx green and a tx flashing green and a orange flashing net led. i have talked to ts2 support and they have sent me a new opt file that i uploaded using isite. my version is 8.0.2.0 any help on how to get the sytem up and running. i am in iraq trying to use internet to talk to my kids back home any help.
thank you

Green TX is on but intermittent?  Have TS2 check:

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

i am sorry but i am no guru at this. when i telnet the tx power it says -2. my lat is 35 deg, 45.2 mins North and that my long is 43,6 min East. as for the other stuff u asked i have no idea how to check all that. I have checked that up link cable and changed the coaxil and the ends with the same results. Thank you  cause i think the people at ts2 support have given up on me. They make me email the dubai office and i feel after reading these forums i am smarter than those techs. any more help would be appreciated. Thank you

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

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.

Hard to say what your problem is.  Could be numerous things as there are so many variables in play.  Here is what I want you to do (in order).

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.

SSG_of_America wrote on Jul 19^th, 2009 at 8:30pm:

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.

Hello mike thank you for your help already u have helped more than they could. i am still trying to contact them via email and phone. i have adjusted the tx power from -20 all the way to -1 but in my modem parameter it say that -2. is that the highest i can get? i have also checked to make sure it is unlocked.

here r the buc & LNB parts

BUC Serial # 100408901203
PN # 1031106-0011
model NJR2784HH
the LNB is S/n #00000661
PN # 102457-0001

Np problem, just trying to be value added, since your ISP is lacking in that department.

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.

ok yes  the buc was used on oifnet just four days ago until i decided to switch cause i was given idirect modem and oifnet raised their prices. the modem was hooked up just two weeks ago with ts2 on this same base h3-qwest iraq. the tx light will stay green for a couple sec then go off when the net led flashes. i will check the telnet to c if i am getting sweeps and let u know thanks again

here is the last email from ts2.

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?

Has this system been ONLINE since the BUC change?  I see that your BUC LO (specified in iBuilder) is 13050. Does the Hub have that LO (translation) specified in iBuilder?

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?  

Mike i am so thankfull for people like u, how do i use iste to spcan? i have a signal of 16.7 using the isite dish pointing. i have tried everthing i know. could it b that the buc isnt the right one?If so where can i get the right one?
BUC Serial # 100408901203  
PN # 1031106-0011
model NJR2784HH  
the LNB is S/n #00000661
PN # 102457-0001

So far Ts2 has been the only ones to attmept to help. the guys at GTSC that run the hub are EXTREMELY difficult to contact. If you contact Ts2 they will get the burner going. I was finaly contacted today, they asked for the rx snr.

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....

I cannot tell what kind of BUC that is.  Is there any way to cross-reference that PN and get some specs on it?  Need to determine if it is an extended or standard Ku BUC.  

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.

That LNB NJR2784HH is a Euro Low DRO LNB +/- 900 KHz. Am checking on the BUC now...

[ 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

]

It appears as if that BUC 1031106-0011 is an HNS 1W BUC. It won't work on the iDirect because it is a saturated BUC and not linear and secondly because it is not L-band.

That may be the problem....  

ok does anyone know what kind i need and where i can get it fairly cheap and fast? I dont understand why ts2 hasnt told me that would b the problem since i gave them the same info i gave all of you guys. I want to thank Mike for the quick response and info and dot for helping out too. Without you guys i would b gettting really angry. THANKS Again.

I am not an authority in rooftop VSAT components..BUCs, LNBS, etc. I am geared more towards SNG. As for assistance, not a problem.  

Good luck with it.