? Voted-Repeated-Simulcast-System w/ Community Rptr CTCSS ?

[psapengineer]

Has anyone seen or heard of others successfully implementing a wide area coverage voted input repeated simulcast output type of system that has multi-user CTCSS like a single site community repater operation? If so, could you please point me their direction? Thanks, PSAPENGINEER

[Bill_G]

What would be the application?

[psapengineer]

On a non-dispatch, secondary public safety coordination channel, allowing the various disciplines (ie: Law, Fire-EMS, Public Works), not to have to listen to each other unless they desired to or chose to use a common CTCSS.

[Bill_G]

That's what I thought. Do they each have adequate channel allocation already, or do they share other channels? Are any other channels simulcast? Normally, this is inherent in a trunking system as talk groups. I have to assume the budget isn't there for a trunking system.

To answer your question, I think someone would have to figure it out. I imagine if you turned off all the high pass filters in the audio processing, and let PL along with voice pass all the way through, it could be done. They will need to use high quality transports like the Harris Intraplex over T1 microwave, or the Harris IP Intraplex over ethernet, the JPS SNV-12 comparator, and the Convex audio distribution panel. I don't know what they would use for base stations unless they already have Quantars or MTRs they could task. Quantars have multi-PL rx capability, but MTRs and most other base stations do not. They would need a community repeater panel at each site to qualify the inbound PL, but not regen the PL, or control repeat.

It won't be cheap, but it would be cheaper than trunking.

[psapengineer]

I've pondered a few ways this could be done but before I even consider going down this rabbit hole I'm trying to find out if anyone gone there before?

Anyone else?

[Bill_G]

Bob - I've asked around, and we have never seen such a bird.

edit to add - others suggested csq rcvrs at all sites - wideband audio back to the comparator - voted wideband audio to a community rptr panel that qualifies the inbound PL - it passes repeat audio and regen PL to the distribution bus.

[d119]

Bob - I've asked around, and we have never seen such a bird.

edit to add - others suggested csq rcvrs at all sites - wideband audio back to the comparator - voted wideband audio to a community rptr panel that qualifies the inbound PL - it passes repeat audio and regen PL to the distribution bus.

That would be the logical way to do it, however any interference or noise on the input frequency that's "louder" than the desired signal could play hell with the voter, resulting in what would essentially be "audio holes" in the final product.

You could do the voted side of it very simply with community repeater controllers on each receiver, all programmed identically for the proper PL. But even with a single transmitter/non-simulcast system, how would you get the proper PL out of the transmitter? If you could figure that out, theoretically you could regenerate it over a simulcast as well. That carries it's own set of issues.

Systems of this nature (voted/simulcast) were never meant to operate in this way, hence the reason it's not an "available" feature. This is one of the reasons we have trunking technology.

You would some how need a way for the remote receiver sites to signal back to the simulcast prime site what PL is in use, and have that information forwarded on so the encoder knows which PL to send. I've no idea how you'd do that. Once again, this is one of the reasons why we have trunking.

Seems like it could be really problematic. Is there that much traffic on the channel that they couldn't live with each other?

[Bill_G]

You could do the voted side of it very simply with community repeater controllers on each receiver, all programmed identically for the proper PL. But even with a single transmitter/non-simulcast system, how would you get the proper PL out of the transmitter? If you could figure that out, theoretically you could regenerate it over a simulcast as well. That carries it's own set of issues.

I wondered about how to send back PL information too until I realized I didn't have to. That was part of my original concept above - to have a rptr panel at each site to qualify the PL before recovered audio was shipped back to the voter. The idea to put a single panel at the prime site would be part of a least cost solution. The danger of that is exactly what you speculated - interference could raise heck with the voter. However, getting tx PL is the simplest part of this, and why I don't need the PL info. Using a faithful transport with the high pass filters turned off all the way through the path, the originating mobile would become the PL generator for the call. At a minimum, the site rptr panel would strip and regen PL before it shipped it to the voter.

What you would lose in a system like this is the console interface on the comparator. Dispatch would have to participate as another user through multiple base stations rather than by wireline to the voter. The voter has a single line out. So, any call on any PL would show up as the same channel at the console. You couldn't distinguish between services. Voters generally do not gen / regen PL. So, console line in couldn't command the correct PL for the call. Dispatch would have to have a separate radio for each resource on the console, or have a scanning mobile in front of them.

I think it is a doable project. No DPL codes allowed. This is strictly PL only system. You just have to take it through the engineering phase, and come up with a cost.

[d119]

You're braver than I, Bill. I wouldn't consider carrier squelch infrastructure in this day and age what-so-ever.

[Bill_G]

(snort) I didn't say I would build it. But, I will put the idea out there for discussion. I would put the repeater panels at each site to qualify the rcvrs even if it added cost.

Unless you think I'm saying no simulcast repeater xmit PL. That's not what I'm saying. I would pass the recovered PL all the way through and right back out the door in the xmit audio. I wouldn't need to signal the central site with PL info so it could somehow generate the correct xmit PL. The originating subscriber unit in each call would be the system PL generator for that call. It would pass through the receiver to the community repeater panel, get qualified, shipped down the transport, through the comparator,through the audio distribution bridge, back down the transport to the transmitter, and back on the air. Single source PL that is aligned with the voice perfectly every time. Crystal clear simulcast with no zub zub caused by PL boards slightly out of phase or amplitude. Every site would have the exact same audio. Should work like a champ.

[d119]

You'd have to have microwave for the transport... Or IP. No way leased lines would pass the required fidelity without being broadcast circuits, and costing an arm and a leg IF you can find anyone left at the telco to install them.

[PETNRDX]

My thot was to use something like a couple TS-64's ( or any other decoder ) at each receiver.
They enable or disable E&M signalling ( we have lots of spare E&M we are not using ) might be cheaper than Community Tone Panel at each RX.
The qualified PL tones toggle E&M, which in turn enables the voter, and the correct TX PL generator. In the case I am thinking of only two or three tones would be used. Likely only two. Fire and Law.
Inbound audio handled normally. ( all RX's that unsquelch drop status tone, send audio down the backhaul )
Voter selects best, sends that to CONVEX delay's then out backhaul to TX's.
Our PL is generated and Enabled/disabled at the head end, goes thru CONVEX delay's out the T1 to each TX where it is fed into the transmitter separately from the VF. We drop the PL about 250 ms before carrier to accomplish STE.
Would have to do something special to make sure the consoles were included in the scheme allowing them to monitor and select either or both.
Would that work?

[Bill_G]

You'd have to have microwave for the transport... Or IP. No way leased lines would pass the required fidelity without being broadcast circuits, and costing an arm and a leg IF you can find anyone left at the telco to install them.

Agreed. Easily attained these days if you build your own backbone. The audio response curves on modern channel banks is excellent.

[Bill_G]

My thot was to use something like a couple TS-64's ( or any other decoder ) at each receiver.
They enable or disable E&M signalling ( we have lots of spare E&M we are not using ) might be cheaper than Community Tone Panel at each RX.
The qualified PL tones toggle E&M, which in turn enables the voter, and the correct TX PL generator. In the case I am thinking of only two or three tones would be used. Likely only two. Fire and Law.
Inbound audio handled normally. ( all RX's that unsquelch drop status tone, send audio down the backhaul )
Voter selects best, sends that to CONVEX delay's then out backhaul to TX's.
Our PL is generated and Enabled/disabled at the head end, goes thru CONVEX delay's out the T1 to each TX where it is fed into the transmitter separately from the VF. We drop the PL about 250 ms before carrier to accomplish STE.
Would have to do something special to make sure the consoles were included in the scheme allowing them to monitor and select either or both.
Would that work?

That probably would work. You would have as many E&M leads as you have DS0's that you could task for PL tones. Sum them at the prime site through a diode bridge to select the correct PL encode. It could get complicated.

A simpler solution might be the Zetron Model 47MT multi-site repeater controller. It is a community repeater panel that talks to all the other panels in a multiple site system. It uses short duration FSK bursts to communicate decoded PL and EOT (end of transmission). Normally it ships the data bursts down the same 4W circuits used for voice transport. But, if you build out your own backbone, you probably will have a DS0 to spare that you could dedicate to tying all these panels together. Then you wouldn't have to worry about getting the FSK through the voter, or the FSK confusing the voter, and you wouldn't ever have the FSK tones get out over the air. You would ship system voice audio down separate DS0's. Each of the remote site panels would signal the prime site 47MT to generate the proper simulcast TX PL.

The only problem I see with this product is a flapping receiver on the fringe. Other rcvrs might be receiving the subscriber perfectly, but one is on the edge. As it opens and closes, it sends out decode and EOT packets that could cause the prime site panel to suddenly stop generating system PL. That would be a mess in the field as all the subscribers chop the voice. If the 47MT could be set to not send EOT, or the prime site set to ignore EOT, then it might be the good solution. There may be a way to use the voter to control a gated audio bridge that routes only the voted remote site 47MT link to the prime site 47MT. That too could get complicated.