SDR Based Voter System (experiment)

[kc1efx]

Hello All!

I rarely post however, I wanted to see if anyone has tried or worked on a similar concept.

The system I am working on utilizes Kenwood receivers tied to old RTNA lines (or otherwise Plain Old Telephone Lines) to create a multi site, voted, receive only network. It's a PIA to maintain these and I have run into constant issues with repairs on said system.

That being said, I've messed around a lot with SDR's and have recently thought 'why not have an IP based (ISP provider and/or Microwave linked) system utilizing SDR's as receive only pipes to a centralized software based voting system?'

Simply we have one main issue, talk in ability. Broadcasting wise we have near 100% street coverage.

So as I write this I've been experimenting with three different sites testing latency and reliability based off of consumer based ISP networks (Comcast). I've used P2P internet radio software and Cloud-SDR to just see what the QOS is. There are area's I have identified that can be improved regarding network speed and latency.

What I'm looking to see is if anyone knows of a piece of software that can take multiple SDR's tuned to the same frequency (or multiple audio streams), vote it, and pipe it to a single output. All that based on VOIP.

If this is simply impossibly can anyone point me in the direction of IP based VHF voter hardware?

73's
-Tony

 

[RFI-EMI-GUY]

Hello All!

I rarely post however, I wanted to see if anyone has tried or worked on a similar concept.

The system I am working on utilizes Kenwood receivers tied to old RTNA lines (or otherwise Plain Old Telephone Lines) to create a multi site, voted, receive only network. It's a PIA to maintain these and I have run into constant issues with repairs on said system.

That being said, I've messed around a lot with SDR's and have recently thought 'why not have an IP based (ISP provider and/or Microwave linked) system utilizing SDR's as receive only pipes to a centralized software based voting system?'

Simply we have one main issue, talk in ability. Broadcasting wise we have near 100% street coverage.

So as I write this I've been experimenting with three different sites testing latency and reliability based off of consumer based ISP networks (Comcast). I've used P2P internet radio software and Cloud-SDR to just see what the QOS is. There are area's I have identified that can be improved regarding network speed and latency.

What I'm looking to see is if anyone knows of a piece of software that can take multiple SDR's tuned to the same frequency (or multiple audio streams), vote it, and pipe it to a single output. All that based on VOIP.

If this is simply impossibly can anyone point me in the direction of IP based VHF voter hardware?

73's
-Tony

While not an SDR solution, there is an IP based voting software that could replace the existing dedicated circuits with IP. . Check out RTCM ALLSTAR in Yahoo Groups and Google for more sites. There are some commercial products as well.

If you do decide that an SDR solution will work, consider that you might wish to add antenna diversity to the system so that you can have two receivers and antennas at each site and gain reliability.

 

[kc1efx]

While not an SDR solution, there is an IP based voting software that could replace the existing dedicated circuits with IP. . Check out RTCM ALLSTAR in Yahoo Groups and Google for more sites. There are some commercial products as well.

If you do decide that an SDR solution will work, consider that you might wish to add antenna diversity to the system so that you can have two receivers and antennas at each site and gain reliability.

(In reference to the RTCM ALLSTAR module)

Very interesting, thank you for that!

I'm reading up on RTCM (and will continue to) as I write this. If you have experience with these what is the centralized software/hardware component of this system? I read up on a java based monitoring software but I'm a bit confused on what component does the actual 'final audio pipe' of that system?

 

[RFI-EMI-GUY]

(In reference to the RTCM ALLSTAR module)

Very interesting, thank you for that!

I'm reading up on RTCM (and will continue to) as I write this. If you have experience with these what is the centralized software/hardware component of this system? I read up on a java based monitoring software but I'm a bit confused on what component does the actual 'final audio pipe' of that system?

There are several ways to implement the system. The common way is a PC at each site and a "dongle" that is basically a sound card chip with added interfaces for COR and PTT logic. Those run the gamut of real cheap DIY to a moderately priced production item. The other is the RTCM ALLSTAR Thin Node Client which combines all of the interfaces and CPU in one appliance.

Simulcasting is also a feature of the Thin Node Client, however there are some technical challenges and bugs that have not been fully ironed out, though some are using it successfully for ham radio.

Micro-Node AllStar RTCM

 

[freddaniel]

I presume you are using analog radios. I will share with you some of what I have learned relating to this subject. I am sure you probably already know much of this, but for the benefit of other readers, I will explain.
First, to improve a repeater [or base] talk-in performance, start with a second receiver and antenna, as suggested by RFI-EMI-GUY, like what every cellular site does. This alone will add about 13 dB improvement if you can space the second receive antenna at least 4 wavelengths [8 ft on UHF] or more from your main receive antenna. Some people have had greater success using a different polarization.

Next, proper receiver voting using real s/n voting like the GE/Macom, which works the best. The hardware is still available on Ebay occasionally. I love this stuff. It will work on analog PL circuits, T1 channel banks, or RoIP [like VoIP but 4-wire] hardware. I just sent off 30 used Multitech MVP410 VoIP terminals to the junk yard. These work 4-wire with E&M signaling over most any IP connection. There are lots of RoIP terminals on the market to haul the audio, if you already have a voting system like the GE, or are happy with summing the audio. The most common terminal from China is called the ROIP-102 sold on Ebay and reported to be a bit of a challenge to get running, due to the poor instructions.
The RTCM ALLSTAR Thin Node Client does the RoIP function, but as I understand it, the initial design did not vote the audio, but simply summed it together using a conference bridge. With fast & tight squelch on all receivers, this could work OK. I heard a later software version switched to RSSI comparison to vote, but maybe not.
There is a flaw with the RTCM ALLSTAR transmitter simulcast where it loses sync and cannot be regained without a hard reset across the system. However, a daily reset could resolve the problem.
Many wide-area systems would actually work better if they were converted from a network of repeaters to a simulcast system.
Digital systems use a completely different concept for voting.
Let me know if I can assist with other ideas.

 

[kc1efx]

I presume you are using analog radios. I will share with you some of what I have learned relating to this subject. I am sure you probably already know much of this, but for the benefit of other readers, I will explain.
First, to improve a repeater [or base] talk-in performance, start with a second receiver and antenna, as suggested by RFI-EMI-GUY, like what every cellular site does. This alone will add about 13 dB improvement if you can space the second receive antenna at least 4 wavelengths [8 ft on UHF] or more from your main receive antenna. Some people have had greater success using a different polarization.

Next, proper receiver voting using real s/n voting like the GE/Macom, which works the best. The hardware is still available on Ebay occasionally. I love this stuff. It will work on analog PL circuits, T1 channel banks, or RoIP [like VoIP but 4-wire] hardware. I just sent off 30 used Multitech MVP410 VoIP terminals to the junk yard. These work 4-wire with E&M signaling over most any IP connection. There are lots of RoIP terminals on the market to haul the audio, if you already have a voting system like the GE, or are happy with summing the audio. The most common terminal from China is called the ROIP-102 sold on Ebay and reported to be a bit of a challenge to get running, due to the poor instructions.
The RTCM ALLSTAR Thin Node Client does the RoIP function, but as I understand it, the initial design did not vote the audio, but simply summed it together using a conference bridge. With fast & tight squelch on all receivers, this could work OK. I heard a later software version switched to RSSI comparison to vote, but maybe not.
There is a flaw with the RTCM ALLSTAR transmitter simulcast where it loses sync and cannot be regained without a hard reset across the system. However, a daily reset could resolve the problem.
Many wide-area systems would actually work better if they were converted from a network of repeaters to a simulcast system.
Digital systems use a completely different concept for voting.
Let me know if I can assist with other ideas.

Thank you for the suggestion! It is analog (VHF). The second receiver is certainly a good proposition. I've been pushing for that the past few weeks to see if it will improve reception on a channel that does not utilize the voting system we have in place.

The system we have now uses Rayethon SNV-12's. Currently, it's using just one pair of copper lines per site. Is it possible to use ROIP with that hardware doing the voting? Would a GPS receiver at each site resolve the latency issue with signal input? Any suggestions on hardware (besides the RTCM Thin Node)?

 

[RFI-EMI-GUY]

My understanding is that the RTCM Thin Node uses RSSI voting. S/N voting like the JPS SNV is preferred method as you can have a high RSSI in the presence of strong interference. You might was to contact Don Scott at JPS regarding IP transport for the receivers to the SNV voter.

Sent from my SM-T350 using Tapatalk

 

[speedway_navigator]

Any thoughts on Raven voters? I worked with a PE doing an install in Texas, it's an easy system to install.

 

[RFI-EMI-GUY]

Any thoughts on Raven voters? I worked with a PE doing an install in Texas, it's an easy system to install.

I have seen them advertised but never seen one in a system. How does it work, and how well does it work?

Sent from my SM-T350 using Tapatalk

 

[speedway_navigator]

Ive only worked on 2 systems using them, one had a software bug which might have been fixed by now.
Tech support was able to duplicate the problem I saw and came up with a work around.

One thing I found odd is that a config file can't be loaded unless the device is connected, unlike a radio
codeplug.

 

[R8000]

The system we have now uses Rayethon SNV-12's.

JPS is coming out with the SNV IP. Should be out soon. Add IP voting to your SNV without homemade gimmicks.

https://jps.sugarmapleinteractive.c...17/08/JPS_DataSheet_4Page_SNV12IPBack_web.pdf

 

[freddaniel]

The Rayethon SNV-12 is the successor to the GE/Macom s/n voters. They are very good. These are designed to work with 600 ohm balanced audio lines. All of the RoIP equipment also operates with 600 ohm lines, so you should not have any trouble using RoIP hardware over a IP connection.
The issue of latency with all packet type of transport like IP over the internet is sometimes a problem. There are several ways to deal with the delay. The first is to reduce the jitter buffer to the minimum setting. This is a packet delay scheme that holds all packets a minimum time so late arriving packets can still get in line. Unless your path is very poor, you will not need a jitter buffer.
Another idea is to also transport your local receiver through a RoIP terminal, so ALL AUDIO entering the voter has the SAME latency. Or you could use a simple audio delay on the local receiver so all latency is the same. There are probably other ideas out there to resolve the latency issue.

The best idea for you is to simply buy the IP backhaul module from Rayethon and let them solve any problems.

Last, you said you were tinkering with Comcast as a ISP. Just try to stay with ONE ISP for all your receiver locations. the trunking within an ISP is usually good and latency is also OK, but there is always a "choke-point" between ISPs so any connections from other vendors may exhibit inconsistant performance. The exception to this rule is if the two ISPs use the same wholesale backbone. Using traceroute between locations will tell you a lot, real fast.

 

[RFI-EMI-GUY]

The JPS SNV-12 has an audio delay built in the software. Not sure what the resolution is, but it is there for long circuits.

But there could be some audio bandwidth differences between the ROIP and local circuits, so a back to back ROIP connection might be the way to go with the local
receiver.

Sent from my SM-T350 using Tapatalk

 

[speedway_navigator]

We had a simulcast paging system with one IP link and 3 or 4 RF links. We never could get enough delay in the RF links to offset the IP link.

Have you guys looked at buffer bloat and CoDel?
https://www.grc.com/sn/sn-359.htm

 

[Project25_MASTR]

So the system I'd actually recommend for doing this is manufactured by a company called RF Technology. Uses software defined repeaters which can be setup for P25 trunking, conventional voting, conventional simulcast or even trunking simulcast (as long as it is single site). Many know the equipment as the Eclipse 2 repeater has been relabled and offered by Icom for several years now. The Eclipse 3 (which isn't into full production yet) is fuly softwared defined (the TX/RX unit has a lockable VCO range from VHF-Lo through 800 MHz) and is supposedly going to be relabled by EFJ at some point to fill the gap created by the expiration of their contract with Simoco relabling the SB2025NT (which means it'll be available to Kenwood dealers). Oh yes, DMR operation is a software release being developed for both Eclispe 2 and 3.

Voting/simulcast operation is based off of ping latency and BER/SNR depneding on whether or not we are talking about digital or analog. Once you get to the IP side of things, it's all routing (leased or owned PTP circuts are best for this though). All analog audio is carried using SIP standards (and there is direct SIP PBX integration available).

 

[speedway_navigator]

Have you had any problems with Eclipses needing to be reset every so often?
A friend of mine has run into this in a paging xmtr.

 

[Project25_MASTR]

Have you had any problems with Eclipses needing to be reset every so often?
A friend of mine has run into this in a paging xmtr.

We have not. I even talked to one of my friends at TxDOT about it and they've had one pulling next-to continuous duty for nearly 4 years in Galveston for ferry operations. I know they've been pushing the Eclispe 2 for paging over the actual paging transmitter they offer. Sounds a bit like a firmware bug.

 

[kb5udf]

Keep dialog going

I have been pondering cheap remote receivers as well like the original poster. I'd love to have a 900mhz repeater with a "blowtorch" transmitter and blanket the city with cheapo receivers (SDR dongles with modest height antennas sending back receive data over the internet to a computer/voter). Like the original poster,
so far, a cheap, off the shelf solution currently eludes me. But, I notice that current versions of SDR# include
S/N ratio indicator. If this could be run on cheap hardware, coordinated with software and include the S/N reading for voting that would rock. There are alot of buts here. I'm not sure if you can get such data/pipe it
out of SDR #, but the idea intrigues me.

 

[RFI-EMI-GUY]

So the system I'd actually recommend for doing this is manufactured by a company called RF Technology. Uses software defined repeaters which can be setup for P25 trunking, conventional voting, conventional simulcast or even trunking simulcast (as long as it is single site). Many know the equipment as the Eclipse 2 repeater has been relabled and offered by Icom for several years now. The Eclipse 3 (which isn't into full production yet) is fuly softwared defined (the TX/RX unit has a lockable VCO range from VHF-Lo through 800 MHz) and is supposedly going to be relabled by EFJ at some point to fill the gap created by the expiration of their contract with Simoco relabling the SB2025NT (which means it'll be available to Kenwood dealers). Oh yes, DMR operation is a software release being developed for both Eclispe 2 and 3.

Voting/simulcast operation is based off of ping latency and BER/SNR depneding on whether or not we are talking about digital or analog. Once you get to the IP side of things, it's all routing (leased or owned PTP circuts are best for this though). All analog audio is carried using SIP standards (and there is direct SIP PBX integration available).

What is SINGLE SITE simulcast trunking? That is an oxymoron..

Sent from my SM-T350 using Tapatalk

 

[Project25_MASTR]

What is SINGLE SITE simulcast trunking? That is an oxymoron..

Sent from my SM-T350 using Tapatalk

The reason has to do with how it's built. RF Technology has a single site trunking card (for multi-site you interface with an Atlas controller). It's setup similarly to the way the older Intellirepeaters were setup and there is no authentication. You can go in and add the simulcast option to those repeaters and create a simulcast system (de-centralized). You can't expand it to multi-site wide area without hooking it up to the Atlas controllers. This, single site (controller) simulcast (option).


Sent from my iPhone using Tapatalk