SatSig topic:

HELP! Signal loss after TX enabled (ViaSat)

(Read 12857 times)

May 23^rd, 2006 at 1:49pm

We have installed a 2.4 Meters Ku-Band dish in Ghana (close to Sunyani) and recently tried to set up the system. After pointing our dish we received a good signal (QPSKBER constantly below 0,0000x) and were looking forward to the lineup. When our Provider switched on the TX of our Transceiver (SkyWare 2 Watts model) and established the link we could not believe what we saw: BER sank down to 0.00x and the RSCorrected and UnCorrected ErrorCount started rising. At the end we had a packet-loss of about 50% - too bad for any connection. We don't have any clou where this problem is originating from. Some guesses: Feedhorn issues? Interference or Sidelob reflecting into our own RX? What's your guess? Ay, we're trying to set up this system for a small community in Ghana to supply facilities and a hospital with internet-connections. So our project is really endangered if we cannot solve this packet-loss issue.

May 23^rd, 2006 at 3:25pm

Assuming you've discounted weather on EITHER end as contributing to your packet loss, I think you should optimize your antenna pointing angles - with particular emphasis on the co-pol/cross-pol

//greg//

May 23^rd, 2006 at 7:27pm

Mmh, all right, but checking my cross-pole (is Eutelsat W3a) is kind of difficult without having having someone on the hub to test it nor a spectrum analyzer - is it possible to contact the hub people before you choose a provider? or are there some tricks to check for the right polarization? Can't I just transmit a carrier and realign my dish until i get a good BER again?

May 24^th, 2006 at 12:41am

Without knowing your equipment, I'd have to say no. RSL and BER performance results are limited to your receive only. My guess is that your packet loss issue comes as a result of poor transmitter isolation (co-pol/cross-pol). Some systems (like mine) include software to assist in optimizing all pointing angles, but it sounds like yours may not. Perhaps a review of the system capability might prove that assumption incorrect. But if there's actually no way for you to optimize transmitter isolation by yourself, I see little alternative other than to work in real time with the hub.

On the other hand - if you provide more info about equipment type, provider, et cetera - perhaps someone with a similar configuration might notice and lend assistance.

//greg//

May 24^th, 2006 at 10:19am

So let's post some tech details of my equipment:

Modem: ViaSat RCST Modem - I think it's Rev. D
Tranceiver (Integrated RX/TX): Skyware 2 Watts Cross-Pole Ku-Band (see www.skywareradio.com)
Antenna: 2,4 x 2,6m Offset (ND-Satcom)
Provider: still about to choose - could be Level421 (Germany)

But if the only possibility is to check with the Hub on the phone - how to reach these people? W3a Hub is in Turin/Italy right? Can i just call there and ask for assistance?

PS: Found out, that my KU-Feedhorn is not the one originally supplied with the antenna. Could this be the origin of my problems? But if RX is fine, how should it affect TX?

May 24^th, 2006 at 12:35pm

Maybe I'm all turned around about how things work over on your side of the ocean, but it would seem to me you've put the cart in front of the horse. Your initial post suggested you were already working with a provider when you said they "Provider switched on the TX...". But now you don't seem to HAVE a provider.

Or are you enquiring as the end user - and this PROVIDER is/was the onsite guy with the packet loss issue? If so, I'd think that's the person that should be answering your questions.

Who provided the initial access information: satellite and transponder, TX/RX frequencies, AL/EL/POL angles, polarization, symbol rate, data rate, error correction, et cetera?

Waveguide components - to include feedhorns - are sized so that the internal dimensions match the wavelength of given frequency ranges. Obviously you'd want a feedhorn cut to a dimension that included the wavelength of both your TX and RX frequencies. I suppose it's possible, but an error that gross would border on negligence.

//greg//

May 24^th, 2006 at 1:06pm

So here's the whole story for you:

Indeed, we had a german provider and supplier doing the test with us - but because we really needed a long time (one year) for getting our equipment he was a litte fed up and told us to solve our problems bevore he will try to reconnect - this means, actually were free to choose again, but i don't want to do this without having my equipment working. From our primary Provider we also received the modem and transceiver and the access information - only our dish and feedhorn is supplied by another company - but still all the components are KU-band so I don't see why they should be troublesome.

For the Feedhorn (It's KU-Band from an Prodelin antenna) - I hope i got right that for every VSAT you use just ONE Feedhorn for RX and TX, and because we use a Transceiver and not a detached BUC/LNC there's no Waveguide splitting the Signals.

Let's come back to my most beloved question Wink

Any way to contact the hub directly?

May 24^th, 2006 at 1:59pm

OK. Maybe we've got a perception problem here then, because you still haven't told me WHO the internet service provider IS. Perhaps when you say "hub", you're thinking EuTelSat. If so, that won't work. "Hub" in this instance is that of the internet connection provider, the one to which you would make your monthly subscription payments. The hierarchy is; user>satellite internet service provider>satellite provider.

Yes, there is a satellite provider control center (hub), but in the cases like this, only the service provider contacts them. Service providers a secondary control center (hub) from which they coordinate and troubleshoot ONLY their customers' satellite connections. If you HAVE no satellite internet service provider, there IS no "hub" that YOU can contact directly. At least that's how it works on this side of the ocean.

//greg//

May 24^th, 2006 at 5:01pm

Ahh. got that. I always thought that you can troubleshoot with the satellite operator directly - but in this case i'll have to ask my provider (It is or has been "Level 421") again for tech support or choose a new one to support me. Do you think just realigment whilst online with the provider will do the trick?

May 24^th, 2006 at 9:28pm

No guarantees, obviously. But that's the next logical step. From that point we can reassess the situation.

//greg//

May 27^th, 2006 at 6:42pm

I am just back from cycling around Hungary - again !

A few thoughts:

If the receive BER went down badly when DC power was applied to the BUC then you probably have a bad connection at one or more of the F connectors. If the outer and inner conductors are not perfectly connected then the current via the BUC comes back via the LNB cable and drops the DC volts for the LNB.

If the receive BER went down slightly when the BUC power was turned and goes down further whenever a transmit burst occurs then this is probably a version of the above problem. Many BUCs take more DC current when the unit is transmitting.

If the receive BER went down badly when the BUC transmitted its first burst and HAS STAYED DOWN EVER SINCE, you have probably damaged the LNB by allowing excessive RF power into the LNB input. This may happen if the transmit reject filter is missing in the waveguide to the LNB. Temporary mild overload of the LNB will produce error bursts in the receive continuous signal every time the BUC transmits a burst. If the LNB is not damaged it will operate normally when the BUC is not transmitting.

If the BUC cable has a faulty connector that is short circuiting the cable, then when the BUC power is switched on the power supply unit in the Linkstar will be damaged. The damage may well affect the LNB supply. There must be no fragments of braid wire scattered inside the F connector.

Please say if you can get back to the original high quality receive signal with just the LNB, and LNB cable connected.

The disconnection and connection of cables must be done with the indoor unit switched off. Take great care not to cross over the cables.

Best regards, Eric.

May 30^th, 2006 at 11:19am

With just the LNB-Cable connected, everthing is fine with our BER, we really have good RX then Wink

The failure just starts as soon as we start transmitting - then BER is crashing down rapidly. I'll tell my colleague in Ghana to recheck the cabling very carefully for any connection problems.

Just for the understanding: How can I see if the unit is sending an transmit burst or not? And how can i enable the transmitter by myself? It's not allowed, isn't it - but I'd like too....

May 30^th, 2006 at 1:01pm

Checking the connectors means making sure that the outer braid is properly connecting to the F type outer shell. I would suspect that the BUC cable outer is not connected.

Does a waveguide transmit reject filter (band stop to the transmit frequency band and band pass to the receive frequency band) exist between the OMT junction and the LNB ?

Such a transmit reject filter will be a length of waveguide, perhaps 2-3 inches long, with either an array of pins across it, some set of cavities attached alongside or with rows of slots along the opposing broad walls. An example is shown at the TOP of the figure on this page https://www.satsig.net/feed1.htm The straight through waveguide filter on the left is a transmit band pass filter. This is often omitted.

During commissioning, transmit is enabled by the hub.

During normal operation transmit is enabled every time you press the return key or upload a file or email for example.

Transmit operation is not shown by the LEDs. It occurs at exactly timed brief instants, lasting a fraction of a second, so that your streams of transmit bursts arrive at the satellite interleaved in time with bursts from all the other sites sharing the same uplink transmit frequency.

Best regards, Eric

May 30^th, 2006 at 1:17pm

Forgot to say: We use an integrated Transceiver-Solution (Skyware Transceiver: https://www.skywareradio.com/english/abwa.html) with directly attached Feedhorn. So theres no need for a filter?

Is there any trick for getting the outer braid connected properly?

Thanks and regards,

Hagen

May 30^th, 2006 at 1:58pm

The integrated ORU unit should have adequate transmit reject filtering incorporated. Ideally, it should take stable, steady DC supply currents via each cable.

The good electrical connection between the outer of the two sockets at the ORU makes it all the more important that the transmit cable outer braid is well connected and of low DC resistance.

You might consider an additional really thick earth cable from the ORU to the indoor unit. You do not want the BUC DC current or transmit burst induced or switch mode converter induced variations of BUC current superimposed on the LNB DC current.

( There is the possibility that the BUC uses a switch mode DC-DC converter and tries to pull short pulses of very high current from the cable. )

If you still have problems contact your supplier or the manufacturer. Has this kit ever successfully worked before with a LinkStar modem at an operational site with the types and lengths of cable that you are using ?

Best regards, Eric.

May 31^st, 2006 at 1:50pm

We bought the Indoor Unit and Transceiver in one bundle and we use RG6 as our supplier recommended. According to them this bundle ist usually working without problems - it's one of their standard-bundles. Only our Antenna and Feed comes from a different seller.

Jun 2^nd, 2006 at 4:42pm

Please say what your transmit power setting is.

use command: pconf

Note that -t -30 is the normal starting value which means attenuator set to 15 dB

The hub will adjust this remotely to set your level correct into the hub.

If you have an excessively high value setting (like -t -6) then this could cause your symptoms and also damage the transmitter. High values like this are only needed on exceptionally long, high loss, transmit cables.

Best regards, Eric.

Jun 7^th, 2006 at 7:07pm

Just checked the pconf-output: TX-Power is set to "-30" - that should be right?