Satellite Internet Forum.

Welcome, Guest.
Welcome to this satellite broadband discussion forum. Wherever you are and whatever your problem we are here to help each other. Connecting to the internet via satellite is not always easy but is critically important to those in remote places or with poor terrestrial infrastructure. Both service providers and customers are encouraged to contribute. Register at the bottom of the forum home page if you wish to contribute or ask question. May 2018: GDPR: Updates to Privacy and Cookies policies: As you may know, a new EU data protection law called GDPR will apply from Friday 25th May 2018. As part of satsig's commitment to protecting the privacy of site visitors and forum members, I have therefore updated the Privacy and Cookie policies. There are now links leading to these policies: Disclaimer, Terms of Use and Privacy, Forum User Agreement, Forum Rules and Cookies at the bottom of the home page and all forum pages. Read the Forum rules.

Satellite Internet forum › LinkStar Forum: VSAT hubs and terminals › Linkstar Transmit Questions

Pages: 1

Send Topic | Print

Linkstar Transmit Questions

(Read 6464 times)

Ex Member

Ex Member

Feb 9^th, 2008 at 11:16am

To start I have the following hardware:

1.8m (Channel Master) Andrew Type 183 Dish
LNB: NJR2784HH or NJR2784F
BUC: NJT5017F or NJT5016F
Linkstar RCST

(I have tested with both with similar results).

The issue is I am not able to achieve ANY transmission or Tx Lock.

I am pointed at NSS-6 (95E). I am located in Iraq at LSA anaconda (Balad Airbase) around 33.9 N and 44.3 E. I receive excellent BER from the satellite. (0.000009 or so).

However, I believe the issue may be related to the Length of Coax I have running from the satellite (which is a good distance away) to the Linkstar RCST in my room. I have Commscope 5782 cable (Quad Shielded RG-6) running for both the Rx and Tx. However, it is roughly 220+ feet (from looking at the Printed length at the beginning and end of the cable).

For 5782, the decibel loss per 100 ft is 7.49 db at 1450 MHz.

To check other possible reasons, I switched the Tx and Rx cables (using the Tx Cable on the Rx) and still receive good BER.

I also used a Multimeter and measured 24.88V at the satellite end of the cable.

I have the boot parameters exactly as the provider has told me (NSTT in this instance, but I am working on contacting Bentley Walker for a quote)

1. The key question: Would I be able to receive good BER, yet not be able to Transmit AT ALL? **

2. Can I increase the decibel output to compensate for length?

3. What is Saturation Point for NJT5016F and NJT5017F BUCs? The level is supposed to be 3 decibels below.

I will probably receive the response "Yes cut the cable" and want to ensure every other option is looked at before I cut such nice coax. However, there is Excess which I have noticed, so I will be able to reduce the length. However, I cannot move the dish any closer, but MAY be able to move the location of the indoor unit.

I can post several screenshots showing pconf, tcmp results, tclgets, prt termexec etc for any ideas.

Thank you,
Alex

IP Logged

Admin1

YaBB Administrator

Offline

Personal text from: Profile,
Options, Top line

Posts: 874

Reply #1 - Feb 9^th, 2008 at 2:50pm

1. Given the high gain of the LNB, low DC current needed by the LNB, a good dish and strong signal from the satellite it is quite credible that you have a good receive signal, even with an excessively long cable. You can check you are on the correct satellite and carrier with tclgets, you should see pcr=true

2. You can alter the drive level into the transmit cable using the transmit attenuator setting to compensate, to some extent, for cable length and to set the required uplink power needed. �I think the setting number is in 0.5 dB steps.

Your cable length may be causing too much DC volts drop when the BUC is connected. �Your length is excessive compared with the image above. �If you use the 4 watt BUC it says you should have an external power supply. �Maybe your internal power supply trips to OFF due to excessive current load ?

If you can get sufficient DC power to the BUC, and if you ask the hub to tell you how to transmit a CW carrier they will certainly be able to detect your signal, regardless of length of cable. � They or you can then alter the drive level in 1 dB steps till the BUC starts to saturate, then back off, say 3 dB. � This will verify that your modem and BUC are not faulty. � Even if the BUC never saturates its output level may be sufficient.

If the output level of the BUC is not sufficient, even with the attenuator at minimum, then I would suggest trying a lower transmit bit rate, if the hub has a suitable burst demodulator.

BUCs have a stated power rating. �This refers to the -1dB compression point. �If you try to increase the power above this the BUC saturates and the signal is distorted, the bit error rate degrades and the transistors may be permanently damaged once the modulation is switched on. �It is like turning the volume up too high on an audio amplifier and blowing the output stage and loudspeaker.

The -1dB compression point is the maximum BUC rating. �The actual level used will normally be lower, set as required to get the level right at the hub.

The NJT5016 is a 2 watt device, needs 37.5 watt DC supply at 15 - 24 V.
The NJT5017 is a 4 watt device, needs 50 watt DC supply at 15 - 24 V.

Be careful never to cross over the cables - you can burn out the LNB power supply.

Send images to me eric@satsig.net or put them on a server somewhere. Read �how to put images into yabb forum.

Regards, Eric.

WWW

IP Logged

Ex Member

Ex Member

Reply #2 - Feb 9^th, 2008 at 3:26pm

Good news, I adjusted the cable to be a better "straight shot" and based on the printing on the cable can reduce it from 230-240 ft to 130ft or so. I have not had a chance to cut it yet, but I anticipate doing so anyway.

With the extreme length I measured 24.88V at the end of the cable, and with a short whip 24.88V as well. However, when it is connected, the length may be having the stated effect.

The ODU Light never switches off or "switches" from Internal to External in any time i have checked the pconf.
Is there a setting I can check if Transmit is "enabled" (beside the Voltage passing through the cable)? The ideal method would be a Spectrum Analyzer, but I don't have access to one (yet).

- What is the max Linkstar db (Tx) level? I believe the most I set it to so far has been -18 (-18 * 0.5 = -9 dBm)
- How can I adjust the Tx bit rate?
- Is there a possibility due to the current length NO signal reaches the BUC?
- From one of the images i attempted "rep -t 1000 tb" and it shows no transmit occuring. Is this a response from the hub or showing if the buc is "outputting"?

I will work on sending a carrier to the hub to fully rule out a bad BUC (two of them) or Bad modem.

Thanks,
Alex

Images below added by form admin....

Image above LinkStar tcmp command.

Image above LinkStar pconf command.

Image above LinkStar tclgets command.

Image above LinkStar prt-termexec command.

Image above LinkStar no-transmit command.

IP Logged

Eric Johnston

Senior Member

Offline

Personal text from Profile,
Options, Top line

Posts: 2108

Reply #3 - Feb 9^th, 2008 at 3:52pm

Talk to your hub. � You need their help with any transmit commands. � They will put your modem on a specific frequency for any CW testing. �Do not transmit without their approval as you will interfere with other peoples' services.

Regarding the return link bit rate, this needs to match the hub burst receiver equipment. �With a shorter cable you will be able to match a wider range of transmit bit rates. �Your actual rate will be determined by the hub. �If your transmit power had been inadequate then I suggested a lower transmit bit rate.

If the modem output level is adjustable -30 dBm to -5 dBm and the attenuator is at 9 dB then the modem output level into the cable is -14 dBm.

The input level to the BUC for max output is -20 dBm

Regards, Eric.

IP Logged

Pages: 1

Send Topic | Print

Disclaimer, Terms of Use and Privacy Forum User Agreement Forum rules Cookie policy.