Batboard

Have a local PD system here that is running a conventional/voted/analog. IIRC Quantars and XTL and APX radios. I am awaiting some details back, but apparently some of the APX radios and/or system is causing a "studdering" of the first second of voice on TX. IE... Char-Charlie 49. Its not a fleet of studdering cops, but no one seems to know where this is occuring. Only happens from the field side, nothing on the dispatch side. The studdering is not always there, but its noticable every-so-often - usually from the car radios.

One theory is that there might be some sort of delay from a voter site data line (IP) but the local shop did a bunch of recent upgrades and updates so no one is really sure what is going on.

Just curious if anyone has heard of this or know of something similar.

Again, very little detail, I've never heard of something like this myself.

If they are using an ip transport for the rx audio, then they need to compensate for delay especially if there is a one site with no transport delay. It's something that the JPS SNV-12 has adjustments for, but I don't think anything else does.

sounds like for a brief moment more than one rx site is being repeated at the same time. how many voters are there? can you narrow it down to an area where it's happening and what sites are closest?

It's the SNV-12 voter. We used one for 6 years or so and our system would do the same thing. It's been so long since I've messed with one I forgot the exact settings but it has to do with delay/buffer settings.

PJ hasn't stated that they are using an SNV12, so lets not make any assumptions quite yet.

More likely, as Bill said, it's IP transport. We have a system set up using a DIGITAC, and all sites except for one are IP based (the oddball is Telco due to not being able to get a microwave shot to the site).

We were getting this when we had the delays in the multiplexers set wrong when we initially set the system up. Once we ironed out the issue, the transition between the IP sites and the wireline site is noticeable only to a very trained ear, to the layperson it's unnoticeable.

Now, if IP is the transport method and has been all along, and other things are on the IP link, you might have a traffic loading problem causing this.

If something was legacy transport and recently cut over to IP, it's possible this is causing it as whomever cut it over didn't do a very good job of setting up QOS and minimizing the delay, resulting in a very noticeable switch between transport methods.

It is also possible that they may have replaced some receivers with newer units that have a DSP involved. Even in analog mode, there's still a noticeable delay getting audio off the air and out of the wireline using DSP-equipped receivers such as Quantar and AstroTAC.

This problem is one reason why it's recommended that all of your transport be identical, and all of your receivers be identical.

You wouldn't hear this occurring on the dispatcher's transmissions because there's no switching of receivers involved (voting comparator) and the type of transport to the transmitter is fixed, not variable as could be the case with multiple receivers being hauled back to the comparator. The stutter is occurring because audio is arriving at different times to the comparator over different transport methods, and the "cleaner" audio is arriving later, resulting in the comparator voting the "cleanest" audio when the subscriber initially keys up, then "cleaner" audio shows up later than the initially voted audio, which is out-of-sync with the initial key-up, resulting in exactly what you hear.

Another solution to the problem could potentially be to configure the comparator to "Vote-Lock" mode, where the initial voted site is locked in for the duration of the transmission, but that somewhat defeats the purpose of voting, in my humble opinion. It's a band-aid solution.

Guaranteed it's in the system, and not the subscribers. And I'm going to move this to infrastructure.

And, if it its IP transport, the latency not only has to be "equal" on all legs (or adjusted in an SNV12 input delay change) but it also has to be consistant regardles of other traffic on the same layer 1 routes. Regards, Bob