Satellite Internet Forum

[patmos]

I would like to know how to check BER (Bit Error Rate) on an IP modem Comtech CDM 570. It is an IBS circuit on a 128 KBPS link. We have packet losses and distorted phone calls/delay. I would like to check the integrity of the link. In a normal set up I use a MARCONI DIGITAL COMMUNICATION ANALYSER 2851S to send PRBS. I checked for errors on a time period. I am new to IP based modem. What tester or software should I use to do this? Any help is welcome.

[matvienko]

It may not be the modem at all. If the outdoor unit is not adjusted to the correct polarization angle, it can produce those symptoms at the digital level. An substandard IFL may produce them as well. You should optimize the antenna pointing angles and validate the cable path. One or both may vindicate the modem.

Given the significant latency inherent to GEO satellite links, 128k isn't a lot of throughput to support quality VoIP. Anything that reduces throughput - particularly on the uplink - will have a negative impact on voice over satellite. Pointing error and IFL faults are near the top of the list when it comes to slowing down uplink speeds. Low output power from the BUC (transmitter) ranks up there too.

[Marshall101]

The CDM-570 has an inbuilt facility to show BER and receive Eb/No. Navigate using the front panel screen to Monitor, then RX parameters. Check at both ends of the link.

During dish pointing aim to maximise Eb/No and minimise BER. For polarisation adjustment set this accurately by calculation, then get your teleport hub or far end to observe a cross pol CW transmit test while you adjust the polarization under their verbal instruction.

If you have the CDM-570 IP module installed and in use there are a wide range of statistics available about IP packet loss etc. Read the handbook. As matvienko says the problem may not be the modem. Check out also the associated routers, switches and the phones, as well as dish pointing.

Is interference a possibility? I would be inclined to fix the satellite link first and then investigate the IP packet and phone aspects.

There are many configuration settings (in modem/routers/phones) involved in getting smooth voice quality over a packet transmission system and it may take anything from a few minutes to several months work/learning to resolve your problem.

[patmos]

Thank you Marshall101 and matvienko.The receive antenna is 2.4m and is optimized. It is not he first service running on it. We just remove the first service and put this IP service. We checked with Intelsat and levels came to nominal Eb/No = 11. This is a 15m antenna uplinking to a 2.4m. Here on main land we have the E1 into RAD Vmux 110 (compression) up to remote place thru satellite. On the remote side there is also Vmux 110 connected to Megaplex 2104 as main telephone switch (ringing tone) is on main land. As per RAD 128K is enough. We have only 4 phone lines on it.
I will check the BER on modem when it degrades. This is only intermittent. I was thinking of possible config problem on modem as I am new to it.

[Marshall101]

If you are in point to point mode over the satellite with SCPC each way then I suggest you use V35 serial instead of IP ethernet via the IP module. This would appear to suit the compressed output from the RAD Vmux 110 and avoids the complexity of added packet overhead and processing delay. Is there a RAD Vmux 110 operating backwards at the Teleport hub to reverse the compression?

In serial mode you could use your 2851 BER test set.

When the problem occurs, do check the circumstances.

If in IP mode: Are your modems managed in a Vipersat network? Does the front panel briefly show RX unlock? We've had instances where the Vipersat NMS has reset the modem tuning periodically due to a home state check in the Vipersat NMS being set to an non zero number. If you have IP and ethernet interfaces we have found that setting the ethernet ports to auto-negotiate at one end causes intermittent short breaks. Setting permanantly to the correct value, 10 or 100, fixed it for us.

Regarding delay, note that 7/8 turbo code, in particular, uses a rather long block length and will add 122mS to the satellite delay (for 128kbit/s). Use 3/4 Turbo or 0.95 Turbo instead.

[Oasis Networks]

Hi,

What is the version of your IP module? Comtech are updating the software version every now and then, as more and more bugs (or "features") are discovered.

It is very easy to upgrade the built and the ip module software. I suggest you to contact Comtech support directly. They are very friendly and will probably reply very soon.

Good luck and please let us know what caused the problem!

[patmos]

My network is not Vipersat. We are in easyconnect mode with ip like xxx.xxx.2.12 ( 13 ) on one and xxx.xxx.2.27 ( 28 ) on the other side for the modems. Yes we have Vmux 110 also at remote site. We changed 10 baseT full duplex on both RAD and comtech. Though turbo enabled we used only an IBS link FEC 3/4, EDMAC. We do not find any unlock on demod. Going thru the modem log we find lots of errors: Server Server Error: Sending Keep Alive Failed. So Manufacturer advised to update ip module firmware (1.5.4 to 1.5.4.2).
They told there were some known bugs when modems in 1:1 connection ( We use CRS 180 ). We updated and find that errors stopped in log. But we do not know if delay will stop. We have to monitor as it is intermittent. Thank you Oasis and Marshall101.

[patmos]

We have not been able to find the cause of this problem yet as it is intermittent. We however noticed that it is more frequent when fax calls are being made. We have more packet loss and distortion. We do not know the correlation. We are still trying to find out.

[patmos]

The problem was fixed by reducing the number of time slots in Vmux. So no latency now. We were new to RAD equipment.