Radio Over IP Issue

[TenleyOlivia]

I have a general question and hope someone can point me in the correct direction. The company I work for has a Motorola radio system, with radio receivers at a remote location. The connection between the system and the receivers is Ethernet/IP. At random times, the radio system will transmit a "clicking" noise that renders the system useless. You can manually disable the system temporarily, then re-enable the system and everything is fine. Does anyone have advise on who might have more technical knowledge on troubleshooting this problem?

Thanks,
Tenley Olivia

 

[DPapay]

Can you rely on the company that put the system in? How often does the problem occur?

 

[TenleyOlivia]

The company that installed the system has tried to correct the problem, but with no luck.

 

[comsec1]

IP or T-1

in one of the motorola classes I was in a while ago for system networking I can remember the instructor saying that alot of system users employ "IT" people to manage their systems rather than radio techs and many try this with similar failures, the radio systems require the full T-1 bandwith to function properly and cannot share bandwith with other users. the system has to be a closed system and should be a microwave link or at a minimum a T-1. the class was a few years ago so I don't remember it verbatim but it was something like that, I'm sure someone will fine tune my statement.

 

[zz0468]

in one of the motorola classes I was in a while ago for system networking I can remember the instructor saying that alot of system users employ "IT" people to manage their systems rather than radio techs and many try this with similar failures

This is becoming a major issue, especially in regard to the transport side of a system. A corporate or government end user might still employ "radio techs" to maintain the actual two-war radio systems, but the "IT" types are increasingly more responsible for transport of circuits between site locations.

...the radio systems require the full T-1 bandwith to function properly and cannot share bandwith with other users. the system has to be a closed system and should be a microwave link or at a minimum a T-1.

Yes and no. There are grades of service that can be provided. So, while dedicated T1 service is preferable, it IS possible to do it on a WAN. It just never seems to be done properly. Horror of horrors, there are systems attempting to simulcast this way.

To the OP, this really translates to a suspicion that the problem lies in the transport system, not the radio system. Frame slips, bit errors, packet loss, latency, ATM switches, and routers can all cause varying qualities of service on voice grade circuits. Internet data doesn't care. A lost packet will be resent. A 500 millisecond delay will cause a measurable - but unnoticeable - hesitation in a web page to load. On a voice grade circuit, even minor problems can translate to clicks, pops, and garbled audio. That can happen on a T1, too, but it just seems to come with the territory on an IP network.

Radio over IP is cheap and easy, but that doesn't make it better. Explaining that to a competent IT manager who understands the issue will be orders of magnitude harder than actually fixing the problem. First, you have to find one. Good luck with that!

I'm sure someone will fine tune my statement.

Hey... I guess that was me. But your statement was fine as it was. It just triggered a rant... this issue is a personal pet peeve of mine.

 

[studgeman]

We still havent asked the important questions.

Analog or digital radio system?

is the recieve voted?

are the IP connections microwave, cable modem or what is the transport method?

who is supplying the RoIP equipement? Catalyst? Cisco? someone else?

 

[shaft]

You should find out what else is running on the circuit besides radio traffic. If it is a shared connection, then implementing some sort of QoS to prioritze the traffic will help out significanly. If its just a dedicated circuit, it sounds like there might be some errors on the circuit.

Contact your provider and work with them on it.

 

[shaft]

We still havent asked the important questions.

Analog or digital radio system?

Doesn't matter, its all digtal along the transport medium until it reaches the end point.

is the recieve voted?

Not really a factor in this scenario

are the IP connections microwave, cable modem or what is the transport method?

Its an ethernet link.

who is supplying the RoIP equipement? Catalyst? Cisco? someone else?

Catalyst is a switch made by Cisco.

 

[talviar]

Doesn't matter, its all digtal along the transport medium until it reaches the end point.



Not really a factor in this scenario

Its an ethernet link.


Catalyst is a switch made by Cisco.

Sure about all that?
If it is an analog base station that has a RO-IP adapter connected to it and audio levels are screwed up then is different than if it is a digital base station with a network cable plugged into it.

If it is voted and there is a problem with the voter system --anything could be happening-- and be wrong

IP transport on a private network whether WIFI, Microwave or Public Internet each have different issues. Private microwave with no other services running on the IP backbone isn't going to need much in terms of "tweaks" to ensure reliability of packets getting from Point A to Point B. Running RO-IP over the public internet even in an encapsulated VPN tunnel has a whole different set of problems. Latency Delay and QOS on the internet path between the radio and dispatch points are major factors that are out of the immediate control of the person handling the radio and network equipment. You are litterally at the mercy of your ISP(s)

Sure about Catalyst being a Switch from Cisco? While that is true, try
http://www.catcomtec.com/content/view/20/42/
Appears to be a RO-IP system called Catalyst.

Particulars are definately needed--type of base make/model for starts. How is it generating RO-IP? type of ro-ip equipment.
Is RF platform voted and if so type of equipment?
How is it getting to the other end? Public Internet or Private IP Network. Regardless of answer configuration of network? Private IP on switched carriers (AT&T MPLS Network as one example) will have different issues than a Private IP Network on a Microwave Back-bone owned operated by client

Audio file of what the problem sounds like "over the air"?

Too many variables, too many points of problems, not enough info.

Tony

 

[Lukeradio]

ROIP connections

We are trying to set up our first ROIP with an XTL5000 100W model. In reading these threads on the subject there is much to consider. Our interconnect from the E&M module to the radio has a lack of transmit audio but receive is good. We are PTTing fine but no still no TX. An O'scope has shown that there are is no TX audio on any of the pins at J600. Does anyone know if there is a jumper set that will direct a set of mic-in pins to the TIB at J600 or J626? Is anyone doing this with the XTL5000 100W model? I see the pinouts at J2 for the lower watt model has mic-in pins. The 100W model has something called DAC out on that pin. As far as I know, I cant make use of that if its a digital signal. Any help would be appreciated.

 

[RKG]

in one of the motorola classes I was in a while ago for system networking I can remember the instructor saying that alot of system users employ "IT" people to manage their systems rather than radio techs and many try this with similar failures, the radio systems require the full T-1 bandwith to function properly and cannot share bandwith with other users. the system has to be a closed system and should be a microwave link or at a minimum a T-1. the class was a few years ago so I don't remember it verbatim but it was something like that, I'm sure someone will fine tune my statement.

I take it from the OP that this is a voted system with multiple receivers and a voting selector.

The RX lines back to the voter do not require a T1; any good audio-grade two-wire circuit will do.

The problem with using ROIP to haul back voted receivers is that the voter has to hear all of the receivers in real time. IP-based systems, however, can introduce delays that are differential, and this can lead to anomalous behavior by the voter. As a result, while we tend to tolerate ROIP for a low-use remote controller (i.e., in the Chief's residence), it is considered verboten for voted receiver back haul.

 

[Packetpeeker]

RO-ip

Just a suggestion, I'm not sure how big your system is but you could ask your isp if fibre optic service is available, you may be able to get a dedicated pair between your controllers, then you don't have to worry about bandwidth or interference or lost packets.

We usually set up public safety systems this way and the also use a 2 channel microwave link between the sites in case the optic cable goes down.

As the earlier gentleman said The IT stuff has to be set up exactly right or it wil have stability issues, if your going through a router and your using a vpn, you may have to select a dedicated port on the computer (Controller) and then set up port forwarding on the router and manually insert that port number, the firewall could be another issue.

Try pinging the controllers and see what the packet time is, it will be in milliseconds, the less time the better, if you notice different or longer times, bandwidth could be a problem, also have a tech check the "BEC" on the line be it dsl, cable, fibre whatever. BEC is Bit Error Correction, basically bits or packets of info are sent and then analyzed for arrival time in milliseconds, comparison what was sent verses what actually arrived, this all speaks to the integrity of the line. Hope this info is helpful.

 

[littona]

This is where the radio and IT guys need to cooperate. In my case, I'm a radio guy that went to networking classes. At my current employment, we've been using RoIP for years.

Using Raytheon NXU-2A's or ARA-1's, we have successfully done radio links using a simple DSL or cable modem connection at the radio site. All of our sites feed into our MPLS network. All network components need to be configured for QoS (quality of service) and other ways of ensuring full bandwidth to the radio equipment.

With our equipment, the radio links should use no more than 80K of bandwidth for full-duplex communication, which really isn't much. Most RoIP equipment will also let you adjust the compression codec to drop the bandwidth required even further. Good equipment will also buffer the audio, so if there are latency issues, they will be unnoticeable to the end user.

 

[jim202]

We are trying to set up our first ROIP with an XTL5000 100W model. In reading these threads on the subject there is much to consider. Our interconnect from the E&M module to the radio has a lack of transmit audio but receive is good. We are PTTing fine but no still no TX. An O'scope has shown that there are is no TX audio on any of the pins at J600. Does anyone know if there is a jumper set that will direct a set of mic-in pins to the TIB at J600 or J626? Is anyone doing this with the XTL5000 100W model? I see the pinouts at J2 for the lower watt model has mic-in pins. The 100W model has something called DAC out on that pin. As far as I know, I cant make use of that if its a digital signal. Any help would be appreciated.

I don't have the manuals in front of me so can't remember what the connector number is. However, on the high power XTL5000, you can use the DB25 connector to be able to inject the TX audio, use the PTT and get RX audio at a fixed level. Now here is the next step. You will have to go into the radio software and make some simple changes.

Found some info:

DB25 pins
1 = PTT

8 = TXAH (AUX-TX audio input) cap couple due to bias voltage

9 = RX filtered audio - cap couple this pin due to bias voltage

10 = audio ground

13 = EMGY (ground this pin)


You will need to go into the software under the radio wide tab, go into the TX audio per mode. Near the bottom you will see a selection for TX audio input. I can't tell you which will be the correct setting, because the dumb Motorola software tweeks keep changing their setting for this. One version of the software is one way and the next update it is the other way. This one you will have to try. Just above this selection is the AUX audio input gain settings. The default is with the AGC selection checked. I have always unchecked this and manually set the gain to use depending on what my input level was. Again this will be a trial and test.

You need to ground the Emergency pin to keep the radio from going nuts. Yea I know there is a software selection for it. Just ground the pin and go along your way. Most applications never use it.

The RX fixed audio is a point where the volume control on the head doesn't change this level. There is a software selection if you need to change emphasis or de emphasis. I always just leave it in the default selection.

Hope this gets you on your way. There are the same connections on the mid and low power XTL radio. It just uses that funky 26 pin connector on the rear of the radio. Don't use the same style connector on the rear of the trunk mounted radio version of the control head as there is no PTT there.

Jim

 

[Packetpeeker]

Very well written Gentlemen !!

Sounds like someone (Radio dealer) perhaps or tech did a rush install or maybe just did not know in either case.

We have done many roip installs and they are used for voice or data sent to a mobile mdt in simulcast and/or broadcast mode, depending on the circumstanse, in any event these systems work flawlessly if set up correctly.

I remember a few years ago setting up controllers and always having a intermittant problem at one site, we finally narrowed it down an ip address issue, we assigned a new ip address and never had another problem.

This was on an extended lan,fibre optic pair, not open to public internet, anyhow i was just trying to point out that for some reason the equipment just did not like that particular ip address on that controller??

Strange!