JPS SNV-12 comparator questions

[Bill_G]

Slightly off topic, but the voter is tied to an otherwise 100% Moto repeater system.

The Raytheon help site is a bit under utilized, and their tech support is slow to respond. Is there anyone familiar with resolving SVM line faults? I'll c&p my question to them -

I have a question about the SNV-12 voter line fault detection in a COR receiver system. From the manual -

In applications using Hardwired COR rather than pilot tones, a site will be disabled if it has continuous COR activity, but no speech is detected for the set time period.

In our case we have a simple three site system - one repeater driven by three receivers. We use NXU's and DSL to link to the two remote site receivers for SVM modules 2 & 3, and use the local rcvr directly for module 1. Everything seems to be working fine. However, the SNV-12 site statistics show that module 3 has a line fault every time it is voted. I have never seen the fault light on the module during any conversations over the radio. Yet, they show up in the logs on every transmission. I have checked the receive audio levels and they are equal to the others two modules.

Doing some troubleshooting, I came up with some findings. #3 always showed faulted in the logs. #1 & 2 were always good. Several weeks ago I swapped SVM modules around. It did not move the problem or cure the problem. Instead, all three modules would occasionally show a line fault (about 8 times a week each plus or minus a couple). That is a great improvement for #3, but a degradation for #1 & 2. I returned to site today and power cycled the unit. At first that seemed to have fixed the whole problem. However, after a half day of operation, I can see by remote login that #3 has returned to it's original problem of faulting on every transmission, while #1 & 2 remain unfaulted. What is odd, is despite the stats reporting #3 faulted, I can tell by the transmissions that it's receive audio is being voted and repeated.

Short of turning of the #3 fault det period timer so that fault det function is disabled, what should I look for here? It doesn't appear to be a SVM problem. It might be an NXU problem, but audio levels are good. So, I'm not certain where to go from here.

Thanks

[FMROB]

Maybe you are losing your DSL service. If you are using an NXU which is an IP based system through DSL I am suprised it even works that well at all. But my bet, no ip service = no guard tone. - Rob

[kb4mdz]

Do you have the audio levels in/out of the NXU's set properly too? That's very important. What levels are you using for in & out of your NXU's? If you overdrive the input of an NXU, the codec will go crazy, and then you'll get crazy out the other end.



And yes, generally, if using IP networks for audio transport, you need low latency in your network; the voice audio needs to come thru very, very well. As well as if it was coming down copper or equivalent.

[Bill_G]

Maybe you are losing your DSL service. If you are using an NXU which is an IP based system through DSL I am suprised it even works that well at all. But my bet, no ip service = no guard tone. - Rob

Hi Rob - Good thought, but no. The dsl at either end of this particular link is not dropping out or encountering frame loss. DSL carrier loss is detected by the Juniper vpn appliances. Even a momentary loss is logged. So, DSL interruption is not the source of the fault in the JPS voter.

OTOH, I did quickly change from using status tone (Motorola term for 2175 aka pilot tone in JPS Raytheon world) to good old fashioned COR (carrier operated relay aka E&M keying) because intermittent internet frame loss would farble the status tone and cause falsing in the voter. Carrier Det is applied to the COR line at the rcvr end NXU which translates to PTT at the comparator NXU. That PTT is applied to the SVM as Carrier Det along with the recovered audio. Sounds great and works well. Very solid.

[RKG]

You want to reach out to Bennie Hillman at JPS: he is very knowledgeable about both the JPS Voter and the NXU, and very responsive. I used to have an email address, but JPS migrated to the Raytheon website and email addresses have changed.

Edit: try Benjamin Hillmann [[email protected]]

[Bill_G]

Do you have the audio levels in/out of the NXU's set properly too? That's very important. What levels are you using for in & out of your NXU's? If you overdrive the input of an NXU, the codec will go crazy, and then you'll get crazy out the other end.

And yes, generally, if using IP networks for audio transport, you need low latency in your network; the voice audio needs to come thru very, very well. As well as if it was coming down copper or equivalent.

Hi kb - Everything is set for neg ten (-10db) which is well within the range of the NXU and the SVM modules. The NXU's have a very convenient activity light to confirm input levels are both above the minimum level and below the maximum making it easy for techs to eyeball a system before breaking out the heavy equipment to verify. We're using MTR2000 receivers and base station with adjustable line driver cards rather than fixed output mobiles. In the past I have had to pad CDM and other mobiles to get their rx audio down to match the other base stations into a logging recorder. But, in this system it's 100% MTR's. So, I don't have that problem. Level setting was easy.

Latentcy too is very easy to adjust for with the SNV-12 voter. It has a delay line you can set per SVM so that the repeat audio timing matches fairly closely. Once set, the delay between sites has been pretty constant at around 170mS. It rarely deviates more than a syllable off. Every so often you can hear a ma-mild doubling as the voting switches sites. Obviously the local rcvr has the most delay applied, and it's just a matter of experimentation to arrive at the amount to apply to the other rcvr inputs transported through DSL.

Because we are using this for voting, and audio freq response is important, I have everything set for 64k. There is enough high freq content passed for the voter to function properly. In the field it is almost impossible to tell which rcvr is being voted. They use the system about 5 hours every day with hundreds of unsq dets, and thousands of site votes. Not once has anyone complained about artifact, doubling, or acoustic differences between sites. If you listen in the quiet between words you can hear a difference at the bottom that tells me whether it's the local repeater rx audio or one of the satellite rcvrs. There is this teeny tiny clucking in the silence kind of like clicking your tongue off the roof of your mouth to call the cat. Very small and unnoticible to the users and dispatchers. I have to be in a very quiet place to hear it. Normal driving buries it. Totally disappears in picket fencing, and can't be heard in transmissions from the fringe.

This is the third system I've built like this. Rather than the expense of leased lines, I use DSL, and manage the cloud myself with vpn tunnels between sites. It works swell. Except for this wierd fault being logged by this one module. We'll get it figured out.

[Bill_G]

You want to reach out to Bennie Hillman at JPS: he is very knowledgeable about both the JPS Voter and the NXU, and very responsive. I used to have an email address, but JPS migrated to the Raytheon website and email addresses have changed.

Edit: try Benjamin Hillmann [[email protected]]

Yep. I've worked with Benny a number of times. Great guy. But, this one has him scratching his head too. He did respond today, and I have one thing he wants me to check (board rev). He's thinking it may be rf getting into the cpm. I'll go back over the cable workmanship and grounding. There's another SNV-12 just across the aisle from this one, and it is unaffected by site rf. But, rf can be squirrely sometimes.

[Bill_G]

It's looking like the cpm card was the culprit (the cpm being the main brain cell in the voter). I returned to site to get the info Ben asked for and to go over basic workmanship concerns. While there I wanted to visually confirm the settings for the cpm S2-5 & 6, the line fault reporting timer. Remote interogation showed it set to 30 sec which is reasonable and normal for a voter. However, these faults post immediately upon receipt of carrier det. Pulled the card, confirmed all switch settings, reinserted it, cleared the stats, took lunch, and then looked at the logs. Everything was perfect. Returned to base, checked it again remotely (God bless the DSL, eh? comes in real handy), and nada. Running fine. Checked it again from home, and still good after seven hours of up time. Of course, we're going into the weekend when they barely use the system more than a few minutes each hour as opposed to fifteen to twenty minutes usage each hour M-F dawn to dusk rain or shine. I'll continue to monitor it and see what happens.

[Bill_G]

Update on this problem - it seems to be resolved. Slot 3 no longer reports line faults on every transmission, and when line faults do occur, they are on multiple cards indicating very low tx audio level from the user - not unusual if they are reading back a warrant with the mic in their lap. I love the stats this thing accumulates. Very nice.