SatSig topic:

CRC error check in Hughes HN9600 system

(Read 9828 times)

Nov 26^th, 2016 at 8:15am

Pls, on my yahclick installation with hn9600, i locked the satellite with a very good signal strength and having passed all the test DAPT and OVT, my provider is saying that they are seeing CRC errors on my link.

Even when using a 2m cable length they are still seeing errors. What could be the cause of the error and how will solve it?

Nov 26^th, 2016 at 2:58pm

A CRC error means that a block of data has been corrupted. The Cyclic Redundancy Check is set of few bits at the end of the data block that helps identify if there has been any errors in the whole data block.

Your hub should be helping you resolve this.

They should be able to determine if the CRC errors are occurring on the outlink towards your site or on the return link towards the hub teleport.

What is the signal level now of your bursts transmitted towards the teleport hub?

If the problem is on the return link towards the teleport then here are some possibilities:

1. Dish pointing.
It is quite possible to get a 'perfect' receive signal but still have the beam so mispointed so that transmit signal is low. The transmit beam is narrower than the receive beam. With an unusually strong satellite signal, finding the satellite is very easy but accurately aligning the receive beam is then more difficult because it gives a 'perfect' signal for quite a large range of movement. Try moving your dish in all 4 directions, up/down, left/right till you lose the signal. Note or mark each point and then physically put the antenna in the middle each way.
Can the hub see any improvement in your burst levels?

2. Cable.
When your site transmits a burst the DC power current in the cable increases. Any resistance causes a voltage drop and the burst envelope may droop. This is not very likely with a 6ft long cable but it might be worth checking that the braid makes good connection. A good DC power supply module is important.

3. The teleport hub needs to investigate and keep on testing till the source of the problem is found and resolved. They should use both the hub software and spectrum analysers to investigate.

Eric

Nov 28^th, 2016 at 6:45am

Just to add my two cents, when we face CRC errors, sometimes indeed it is because of cable and point issue, as Eric mentioned. On C band, sometimes it related to terrestrial interference. However, most of the times we face CRC on the inbound (the site uplink), we manage to fix it only by replacing the BUC, after eliminating anything else. I just share my personal experience...

Nov 29^th, 2016 at 9:57am

Thank you sir for the replies.
From the remote end, we have passed the DAPT/pointing test (center test) and also the online validation test (ovt). Though we haven't tested with a different Buc or modem. And this was suggested by the hub operators that we should find another radio to test with. But the radio preesently on site is working well at a different region before I move it to another region. Could any sort of interference affects the CRC error?

Nov 29^th, 2016 at 1:16pm

It would be helpful to clarify where the CRC errors are being detected, either in your modem when receiving the outlink from the hub, or at the hub regarding the burst transmissions from your remote site.

If the errors occur in your modem when receiving the outlink from the hub then local interference might be the cause. Is there any local possible source ? It seems unlikely at Ka band, but look about. Is there radar nearby, electrical equipment, lights etc. Do the errors occur at particular times of the day ? If the CRC errors occur only at the instant when you transmit a burst, the fault could be DC current cable problems, BUC, Modem, LNB or your power supply.

More likely the CRC errors are detected on the packets you transmit to the hub, in which case your transmit bursts are low level or distorted. If your outlink received signal is very strong this makes it extra difficult to the point the dish accurately. It is possible to have a perfect and excellent receive signal for a wide range of physical movement of the dish pointing.

I don't know what is "DAPT/pointing test (center test)" but I doubt that it includes de-pointing the dish in 4 directions to equal degraded levels, marking these points and physically halving the distances.

Dish pointing, cable connections, BUC faulty or weak power supply are all possibilities.

If the hub examine your bursts with a spectrum analyser in zero span they can see if the burst amplitude is correct, if the amplitude remains stable during the burst and if the burst has clear guard time gaps from the preceding and following bursts and is not overlapping. Your lat and long should be stored in the hub for initial acquisition but, once working, the hub should adjust your burst timing dynamically to keep it clear of other bursts.