Voting System - Recommendations?

[marcspaz]

 

Hey folks.  I am trying to hammer out a problem with an internet voting system for repeaters.  Hopefully you folks can point me in the right direction. 

 

I am helping build a receiver-node linked repeater system.  We have a legal limit transmitter on a tall tower and the repeater can cover a vast area as far as where it can be heard.  However, handheld radios and low power mobiles that are far out... maybe 40% plus out from the center of the coverage area... they can hear the repeater fine, however, they don't have enough power to get into the machine reliably, if at all.

 

We have a bunch of repeaters around the region that we could use as a receiver voter system.  We are trying to put it in place over public internet service (we would consider wireless P2P links like Aironet, etc., too) and we are having an issue with networking latency causing the wrong receiver to win.  I have read a few places that there is a GPS time sync tool that causes a brief delay for the signals to sync at the voter and re-transmit the proper SNR source.  However, I am not finding any device brands or models listed and my Google-Fu seems to be dramatically lacking.  All I am finding is new systems well over $7K per system.

 

Do any of you have this type of setup working successfully?  Could you make recommendations on either the proper GPS time source model or a proper voting system that accounts for network latency, and won't cost me a kidney?

 

Thanks in advance.

Marc

[wayoverthere]

https://web.psrg.org/psrg-voting-system/

Here is something I stumbled across on the ham side of the table, that seems to provide a good description of what's going on behind the scenes and the gear they're using..don't know if it's any help

[JohnE]

GPS would be for simulcasting to sync the transmitters timing. Also said transmitters would have to have a high stability XO to lock it on frequency.
You are need a comparator or something that works like one. seeing as you are using IP everything should come back to one "computer" and select the site w/best RSSI and as it moves it goes to the next. IIRC there was a HAM that had some you tubes on it. I think it was in relation to a simulcast set up.
hope this was some help

[SteveShannon]

Marc,

I’m sure you have already seen this but maybe it will help provide background.  This is from repeater-builder:

“A good voting system is completely transparent when it's working properly - you can't tell it's there except by the superior coverage.   Obviously the voter has to be voting identical simultaneous signals, which is why using VOIP (voice over IP, a.k.a. the Internet) as a link to bring in the audio from one or more outlying receive sites usually does not work - there is too much delay and jitter, causing the voter at one instant to be voting the noise between two words on channel one and voting the middle of the previous word on channel two. Manually adding a fixed delay to the one receiver in an IP network does not work either, as the per-path internet packet switching delay is not consistent, even within one transmission, and definitely not from one transmission to the next.   Note that there is a lot of incentive to "fix" this characteristic, and a revision of this paragraph may be needed at some point as the technology advances.”

[SteveShannon]

50 minutes ago, JohnE said:

GPS would be for simulcasting to sync the transmitters timing. Also said transmitters would have to have a high stability XO to lock it on frequency.
You are need a comparator or something that works like one. seeing as you are using IP everything should come back to one "computer" and select the site w/best RSSI and as it moves it goes to the next. IIRC there was a HAM that had some you tubes on it. I think it was in relation to a simulcast set up.
hope this was some help

Gps could also be used at each receiver to time tag signals as received, which could then be used to ensure the comparator is comparing synchronized portions. 

[tweiss3]

I think that all the multi-site multi-receive systems (ham, not commercial) around here are linked via RF. You could do IP link, but use 5GHz Ubiquity dishes to link, instead of public ISP. If I knew of a successful one to reference, I would send you that direction. The simulcast/statewide systems typically have fiber connections, GPS sync, high stability XO and plenty of other things going on. It is also a bit more simple since they are digital trunking as well, I would think analog could be significantly more complicated. 

 

You could try reaching out to the guys of the big F2 repeater system, I think it's RF linked, but they have 17 receive sites online at the moment, they should be of some help.

[marcspaz]

So, unfortunately, it appears we can't legally RF link the repeaters outside of GMRS frequencies.  Three of the people on the project are FCC licensed General Class commercial engineers with several decades of experience each, and they all agree that the rules significantly restrict open air relay, as we have to adhere to the GMRS frequencies and pairing requirements for any transmission to be legal.  Short of using every pair (we have a receive site on every pair) and getting really creative on the voting, the closet we can do is wireless networking, but not every site has the LOS needed.  That is what has brought us to the internet option.

 

If we could RF link, I think we would be good to go.

 

I appreciate all the feedback so far.  This is good conversation that we can discuss. 

 

 

[WRKC935]

OK, voting receive on a subscriber is NOT anything to do with multisite single frequency simulcast.  Nothing to do with audio launch time, GPS or any of that stuff.

What subscriber level voting receive is for, is a system that is broadcasting the same intelligence on multiple frequencies from multiple sites.  Which of course it JUST like what we are doing with the linking. 

So the way it works is if you were in southern Indiana, you would program the radio to scan between all the LINKED repeaters in that area.  The radio will then when receiving a signal from any channel in that scan group look at the signal level of the channel it's currently receiving and the other channels in that scan group and steer the radio to any channel with a better signal.  I am not sure if it will also change the output frequency of the radio to that site, but I believe it will do that as well. 

Understand that since the system we are on has active display of where you are at. And is linked via the internet and latency in those links can vary greatly, you may experience audio jumps when changing from site to site as it's NOT a true simulcast system and the audio launch time is NOT synced.  So be aware of that and don't setup your radio for receive voting scan and then wonder why you hear repeats and lost words as the radio bounces from site to site.

 

 

Now, if you ARE looking to put up a true single frequency simulcast system with voting (about has to have RX voting).  There are some options that are not killer expensive.  I will say right out of the gate, NO INTERNET LINKING.  The connected Internet doe NOT have the stability in latency even with a true IP based simulcast system.  You will fight it, and it will ultimately beat you. 

The RTSM units CAN perform voting for the receive and handle the audio launch time stuff you need and I understand that someone did figure a way to get them to create synced PL generation which can cause you to rip out your hair trying to run PL generated from teh individual base stations.

Second thing to know is this.  What ever repeater you are going to use for one site needs to be used at ALL the sites.  DO NOT mix repeaters.  DO NOT mix repeater firmware either.  The audio passing through the processing from the back connector to the air has delay.  The firmware revision can and does change that  delay in some repeaters.

DO NOT attempt to run MTR3000 repeaters for analog simulcast.  Motorola by their own admission has specifically created code in the firmware of those repeaters that VARY the audio delay time through the station.  This was specifically done to force the purchase of GTR8000 repeaters that are 10 times the cost of an MTR when they were new.  It would only make sense that the SLR5700 and SLR8000 have similar code in them as well. 

You will need a repeater that will natively accept a reference signal to sync the frequency output of the stations.  So we are again back to MTR2000's and Quantars unless your pockets are REALLY deep and you can swing the 30K plus dollars for GTR8000 repeaters if you believe they need to be Motorola. 

I don't know about other manufactures gear.  I work at a Motorola shop and that's what I am knowledgeable on.

[WRKC935]

15 minutes ago, marcspaz said:

So, unfortunately, it appears we can't legally RF link the repeaters outside of GMRS frequencies.  Three of the people on the project are FCC licensed General Class commercial engineers with several decades of experience each, and they all agree that the rules significantly restrict open air relay, as we have to adhere to the GMRS frequencies and pairing requirements for any transmission to be legal.  Short of using every pair (we have a receive site on every pair) and getting really creative on the voting, the closet we can do is wireless networking, but not every site has the LOS needed.  That is what has brought us to the internet option.

 

If we could RF link, I think we would be good to go.

 

I appreciate all the feedback so far.  This is good conversation that we can discuss. 

 

 

I would call the FCC and ask.  If they say it's OK I would get them to put in in writing, but I don't know how they could keep you from using part 15 linking radios for the paths.

 

[tweiss3]

I think you have two options for RF linking. Though you do mention that LOS is troublesome for some RX sites, but you can do GMRS linking via simplex, but then you fall under the definition of fixed station and are limited to 15 watts. The second option would be IP linking over RF (using commercial dishes with type acceptance) but that is 100% LOS driven.

[JohnE]

29 minutes ago, tweiss3 said:

I think you have two options for RF linking. Though you do mention that LOS is troublesome for some RX sites, but you can do GMRS linking via simplex, but then you fall under the definition of fixed station and are limited to 15 watts. The second option would be IP linking over RF (using commercial dishes with type acceptance) but that is 100% LOS driven.

like a microwave backbone

[tweiss3]

14 minutes ago, JohnE said:

like a microwave backbone

Yes, like microwave, except you don't need a license, they are designed as network extenders, except they can go miles and miles.

[marcspaz]

2 hours ago, WRKC935 said:

I will say right out of the gate, NO INTERNET LINKING.  The connected Internet doe NOT have the stability in latency even with a true IP based simulcast system.  You will fight it, and it will ultimately beat you. 

The RTSM units CAN perform voting for the receive and handle the audio launch time stuff you need and I understand that someone did figure a way to get them to create synced PL generation which can cause you to rip out your hair trying to run PL generated from teh individual base stations

 

So, I found this today and was thinking about trying this system.  They state their device resolves a lot of that stuff.

 

https://jps.com/products/qmt-1b/

 

I'm a little gun shy because I have heard what you stated above from basically everyone.  I don't trust online reviews either.  What are your thoughts on this?

 

2 hours ago, WRKC935 said:

The RTSM units CAN perform voting for the receive and handle the audio launch time stuff you need and I understand that someone did figure a way to get them to create synced PL generation which can cause you to rip out your hair trying to run PL generated from teh individual base stations.

Second thing to know is this.  What ever repeater you are going to use for one site needs to be used at ALL the sites.  DO NOT mix repeaters.  DO NOT mix repeater firmware either.  The audio passing through the processing from the back connector to the air has delay.  The firmware revision can and does change that  delay in some repeaters.

 

This is good to hear.  I read about this today.  I may go further down that rabbit hole before spending money, now that a second person is mentioning it.  But, isn't a retimer essentially what the GPS clocking devices I read about would do?  It's a stratum 1 device that syncs the signals to counter the network latency. 

 

2 hours ago, WRKC935 said:

So we are again back to MTR2000's and Quantars unless your pockets are REALLY deep and you can swing the 30K plus dollars for GTR8000 repeaters if you believe they need to be Motorola.

 

I believe all the repeaters are Quantars. 

 

I used to think I had money until I started playing radio.  Then I realized I am dumb and poor.  LOL

 

2 hours ago, WRKC935 said:

I would call the FCC and ask.  If they say it's OK I would get them to put in in writing, but I don't know how they could keep you from using part 15 linking radios for the paths.

 

 

I thought about doing this myself... but I am not sure I trust them.  I found that most of the time, you get an opinion instead of cited code or rules. 

 

2 hours ago, tweiss3 said:

I think you have two options for RF linking. Though you do mention that LOS is troublesome for some RX sites, but you can do GMRS linking via simplex, but then you fall under the definition of fixed station and are limited to 15 watts. The second option would be IP linking over RF (using commercial dishes with type acceptance) but that is 100% LOS driven.

 

I would love to go the RF linking route.  But I am concerned about LOS as well as the tower space and extra hardware expenses. 

[SteveShannon]

1 hour ago, wayoverthere said:

https://web.psrg.org/psrg-voting-system/

Here is something I stumbled across on the ham side of the table, that seems to provide a good description of what's going on behind the scenes and the gear they're using..don't know if it's any help

I have a friend who is on that system and who has good results. 

[marcspaz]

4 hours ago, wayoverthere said:

https://web.psrg.org/psrg-voting-system/

Here is something I stumbled across on the ham side of the table, that seems to provide a good description of what's going on behind the scenes and the gear they're using..don't know if it's any help

 

I sent this to the team. This may be the way we go. Thanks for the link.

[WRKC935]

Well, first off, the JPS box.  That WILL work, but it's expensive, and if you are looking at the RTCM, it will do the same thing for FAR less money.  I would expect a single box would be 2 grand.  And you would need one for every site.  It's also only compatible with an SNV-12 voter that's gonna be a couple grand for the chassis and cards.  So again LOTS of money.

So a brief explanation of how simulcast actually works.  And what the GPS is doing.

The first function of the GPS is frequency reference.  There is a 5/10Mhz output on the GPS unit that feeds that reference signal into the base station radios (they are NOT repeaters by their configuration in simulcast operation).  This keeps the transmit frequency synced with all the other sites.  Because we are dealing with FM, a difference of 100 Hz on the transmit frequency between two transmitters will generate a 100 Hz tone and harmonics of that tone in the receiver of the subscriber radios.  Obviously if there is any variance in the frequency, you will hear that in real time as it happens.  So rock stable frequencies are required.

Second thing the GPS generates for all this to work is a 1PPS (1 pulse per second) signal that the channel bank, or audio control circuitry relies on to 'launch the audio at the same instant.  I spoke about latency of the signal and how that could screw things up.  Well here's how the 1PPS and the simulcast audio controllers deal with the latency issues.  A system will have a 'PRIME' or MASTER site.  That is when the audio comes out of the voting system and gets sent out to the other sites.  Now those links can be direct to each  site or a ring where the audio gets shipped along one after the other.  So the MASTER site tags the audio traffic in a sense so that the far end and all the nodes in between know to 'hold' the audio (buffer it) Until all the sites have it and then release it at the same instant.  In the days of TDM, there was also a 'jitter buffer' that kept things in the buffer to deal with the changes in latency of the connecting circuits.  With IP and computers, it's done differently but the result is the same.  The audio gets held up until the next pulse or the one after, before it's launched.  Now there is also timing adjustments for overlap where more than two sites can be heard at the same time.  Those adjustments are to deal with multi-site overlap and actually move the locations of contention, where the received audio is distorted.  The timing adjustments MOVE the area's of contention that are unacceptable or very undesireable to other locations that are more acceptable for poor audio reception.  Basically you move them into some corn field and you are done with it. Now of course you find those area's of contention two ways.  First is through testing of the system during implementation and tuning.  The second is wait on people to point out the area's of contention and move them then and hope the go the right direction as you tune the launch timing.

I have designed, build, rebuild and added to a number of these systems.  Mind you, the stuff I was dealing with was all analog FM both wide and narrow band and I was dealing with channel banks that were 20K each for handling the audio launch timing and shipping of the audio back to the voting system for the receive.  This was all broadcast quality gear that would ship audio at FM broadcast bandwidths (100 Hz to 19Khz to haul the 19Khz Stereo pilot tone) not just 300 to 3000 Hz for two-way FM.

I have NOT specifically worked with the RTCM units, but i do know how they HAVE to work in order for them to do simulcast.

The last piece is the PL tone.  That has to also be generated locally to the transmitter or not at all.  If you can get away with it, don't run a transmit PL tone at all.  It will make things easier in the long run.  If you choose to run a PL, the base station can NOT be used to generate it.  The Quantar and MTR base stations both have multiple audio inputs and one of them can be used to take in a PL tone and out it ion the air.  With the systems I dealt with, This was handled with a Spectracom product that interfaced into the Spectracom GPS units and provided the PL.

One of the other things you will need to be able to do is controlling the sites individually to interrupt the PTT signal from the RTCM or whatever you are using to key and ship the audio.  The audio levels for each site have to be adjusted independently of each other.  And that have to be spot on.  The only way to do this is a receiver in a location that can hear all the sites.  So placement of the MASTER site is important so you can monitor the TX audio and adjust it.  THis has to be done with an O-Scope, an audio volt meter, or a TIMS set that measures down to the 10th of a dB.  Three tenths is ALL you get before you start screwing up the audio.  And you don't get that much with the PL tone because where the audio maximum deviation is 5Khz for wideband, the PL tone should never go above 700 Hz of deviation, and with narrowband that is reduced to 300 Hz.  So that has to be SPOT on.  Have a GOOD radio not a CCR to do this.  And program it for flat audio out so you can hear the PL tone or it will be a mess. 

 

 

 

 

Edited October 13, 2022 by WRKC935
double posted the text in the answer

[kidphc]

Love this thread!

[marcspaz]

1 hour ago, kidphc said:

Love this thread!

 

No doubt!  The members have a lot of knowledge and great feedback.  I'm thankful, for sure.

[WRKC935]

Mark, if you are serious about doing this and need assistance let me know.  There are a number of things that are specific even to the way the codeplug has to be done in the radios that will need to be done correctly to get this working.  MTR's are typically easier to program than the Quantar's.  But I have done both.  I will say this up front.  You will need wireline cards in either of the stations to get it working right.  There is no way around it.  So doing an inventory of the stations to be used will need to be done to verify there are wireline cards in them and if not they will need to be located and installed. 

Quantars require some wildcard programming that is NOT documented anywhere.  I looked.  The only documentation I ever found used tone remote commands to control the PTT and my setup would not support that so I had to work out the programming to turn on the second audio input for the PL and some other things. 

Another thing to realize.  While the RTCM can act as the interface for the linked system I don't know that it will do both at the same time and you MAY need to have another RTCM configured as a site on the simulcast that would act as the interface.  For a voted channel bank system, I would use the console input and an RTCM or PI interface to bring in the system audio but that's a JPS voter configuration and I am gonna guess you will want to try to avoid the costs on that sort of setup.

Let me know if you run into questions and I will try to help you the best I can.

 

[gortex2]

I use the MLC8000 on my repeaters. But requires Ethernet transport between each site. I use MPLS to do this but in your case I'm not sure who you could get point to point ethernet. 

The old way of using a Digitac, SpectraTac, JPS or even GE voter shelves will work but requires either a 4W RTL line or some way to get that voted audio to the comparator. I was using T1 circuits previously for channel banks with the audio feeding along them. It worked and worked well with a mix of MTR, Quantar receivers. We really only upgraded to be able to simulcast. 

[wrtq652]

On 10/12/2022 at 1:47 PM, wayoverthere said:

https://web.psrg.org/psrg-voting-system/

Here is something I stumbled across on the ham side of the table, that seems to provide a good description of what's going on behind the scenes and the gear they're using..don't know if it's any help

Agreed the PSRG system works extremely well in the Seattle area.  Worth taking a look at.