SatSig topic:

Intermittent Ping to the Management IP address of X3 Remote

(Read 6607 times)

Jul 9^th, 2014 at 10:12pm

Hi,

I have a problem with a remote, in iMonitor I see several "request timed out" in the latency tab, in the Inroute Distribution only is allocated the 49% of the slots, the Downstream C/N is 13.8 and the Upstream C/N is 9.1 and is
working with the initial tx power of -32 dBm.

I hope you can help me, thanks in Advance.

Jul 17^th, 2014 at 6:03am

Hi Jose,

Are these request time outs occurring all the time? Or are they only during certain periods through out the day?

what is the average RTT latency for this remote?

Does a modem reboot help the issue?

Sep 2^nd, 2014 at 3:08am

Hi fluffymassive,

Excuseme for the delay in responding, the requests time out happens all the time, the average of RTT latency is around 650 ms. and the reboot doesn't help the issue.

Sep 3^rd, 2014 at 7:25am

IS the remote maxing out its bandwidth? Even though there are free slots on the inroute, it could be maxing out the MIR set in the QoS.

Have you tried another modem with the same config?

Sep 14^th, 2014 at 7:32pm

Hi,

Even when the remote is not making traffic the "request timeout" appears, besides due to this packets loss, the remote can't traffic too much.

The problem is with a remote in the field, I've tried here in the hub the modem we use for test with the same configuration and the problem disappeared, so I Thought the modem in the field must be the the problem , but when the modem was changed the problem continues.

Which could be the problem? it was a coincidence that the other modem was bad too, I really don't think that the LNB and BUC or IF cables could be the problem.

I hope your comments, thank you.

Sep 16^th, 2014 at 8:26am

Hi,

Maybe local interference at the remote site.

Do you see a variation in the downstream c/n or is it constant?

Sep 16^th, 2014 at 7:00pm

Are any of these abnormal ?

Remote Rx composite power.
Remote ref clock DAC.
Remote TDM frame lock lost count.

I don't know if there is a way to measure the remote Rx bit error rate or to do accumulated error counts. That might be helpful.

Best regards, Eric

Sep 19^th, 2014 at 3:32am

The downstream and upstream C/N are constant. Comparing with other remotes that hasn't the problem there isn't a lot of variation with the The Rx composite Power, ref. clock DAC and TDM Lost, they have similar values. The Rx Composite Power goes around -42.xx doesn't change of -42, the Ref Clock DAC have variations between 3200 and 3300, the TDM lost is 0.

I have saturation of bandwidth in the network, I think that could be the problem, I have other remotes that have the packet loss but only trough certain periods of the day, but the remote that I owe this post have packet loss all the time.

Sep 21^st, 2014 at 11:49am

Hi,

Did you confirm that the GPS are accurate?

what is the symbol offset values of this remote?

Good luck,
Nimrod

Sep 21^st, 2014 at 6:37pm

TDMA Mike put some more information about "iDirect Symbol offset" here:
https://www.satsig.net/topics/satsig-topic-num=1238483992

Best regards, Eric

Sep 25^th, 2014 at 12:02am

The symbol offset for the remote is -56, there are another remotes in the network with SO between -50 and -80 and don't have this problem.

Sep 25^th, 2014 at 1:59pm

TDMA Mike said:
Quote:

Symbol offset (as observed thru iMonitor) is a timing correction value issued by the hub (to the remote) as the spacecraft moves in its station box. It is normally a low number (around 5-10 up to 200-300). The hub literally monitors every burst from the remote and issues offsets to ensure that the remote remains centered in it’s time slot. Adjustments are made (by the network) to the symbol offset every 20 seconds through the UCP (Uplink Control Process) in an effort to keep the burst centered. For reference, SO = ½ Acquisition Aperture.

If you are getting SO warnings, there is a timing issue.

Reading the above I would expect all remotes to have SO values drifting about sinusoidally within the range 5 and 300 during the day, due to satellite movement, and none moving outside this range. If any go outside the range then their lat/long is probably wrong. Sites with wrong timing may have their bursts overlap (i.e. collide) with bursts from other correctly located sites. How often this happens will depend on the traffic from other sites.

Did you really mean -56 i.e. minus 56 ?

What are the SO values for all the other sites ?

Can you log (for a short time, e.g for 30 seconds) all the individual bursts being received at the hub ?

Analogue analysis:
If you look on an oscilloscope or spectrum analyser in zero span mode you can see the stream of bursts arriving at the hub. There should be time gaps between each burst and bursts should never overlap.
If you make the remote under test send a large number of bursts then it should be possible to identify the bursts on the spectrum analyser. Do they have normal envelope amplitude and shape ? Do they ever overlap other bursts ? A poor envelope shape may be due to high DC resistance on the BUC cable.

When you lose a ping response does this coincide with any visible event on the analyser?

What can you see on the opposite polarisation? Is the co-frequency slot occupied by a similar TDMA system. Using max hold is there any cross pol interference visible in the gaps between your receive carrier slots.

Best regards, Eric.