Re: [Svxlink-devel] Repeater RF audio not going out internet

[David R. <k9...@gr...>]

* Rob Janssen <pe...@am...> [2015-04-08 18:04]:
> David Rock wrote:
> >
> > So I guess my first question is does svxlink support running in a
> > "remote-link" configuration, or is it designed only for "hard-wired"?
> >
> 
> Aha ok...  I don't have experience with that setup, but it definately is less usable because
> in that setup an Echolink user can only transmit when the repeater has keyed down, while
> in a hard-wired setup the user can transmit as soon as the previous user has released
> the PTT and the receiver timer has expired in his client.
> Even then, some Echolink users complain that they cannot break in because the timer
> takes a second to expire and not sufficient breaks are left on the repeater.  This is another
> reason why the repeater roger beep is not transmitted to the Echolink user, to give them
> extra time to take the mike while the radio users listen to the beep.
> But when you connect like you describe, the Echolink users have to wait for the repeater
> beep (which of course they hear), then for the transmitter to switch off (usually a second
> or two extra), then another second for Echolink to timeout, and only then they can take
> the mike.   This leaves them out of luck most of the time on a repeater here during
> rush hour.
> 
> So, what we do in our repeaters is take away the original repeater controller (we use
> commercial repeaters that can operate stand-alone), and we split them into a receiver
> and transmitter, with audio out, audio in, PTT and SQL, and wire this all up to a PC
> running svxlink that will function both as the repeater controller and the echolink
> connection.
> 
> This works very well, and when the users use Qtel they can break in very quickly.
> 
> For info about the usability of svxlink in your particular setup, I hope others can give
> that information.

I've had a bit of a breakthru working through all of the definitions,
ideas and so-on.  Assuming svxlink's RepeaterLogic is based primarily on
doing a hard-wired setup at the repeater, I came up with the idea of
using the SimplexLogic instead.  At a logical level, that's essentially
what a "remote-link" is; it's just using a radio tuned to a repeater
pair instead of an actual simplex frequency.  The net result ends up
being what I'm shooting for: Echolink audio gets TX'd to the repeater
input, and repeater output gets sent to EchoLink.

I know what you mean about lag between the time someone on the RF side
releases and the time an EchoLink user can TX, but most people in this
area are pretty good about waiting a couple seconds to allow others to
get in, so that's a pretty minor problem for us.  It's certainly an
easier problem to solve than getting internet at the physical repeater site.

I suppose we could use another repeater-class system as the remote, but
that's a bit overkill for our needs.  This is really designed more to be
an extension usable by our local group if they happen to be out of town.
We aren't trying to be the next "Big Thing" in the area. :-)

The next thing I'd like to figure out is how to make the VOX less
sensitive.  I realize a lot of these options are designed for the
RepeaterLogic, but what I'm seeing is any time an RF user pauses to take
a breath, svxlink is reading that as a squelch close and clips their
audio.  Are there any options that apply to the SimplexLogic that will
help it tolerate brief drops in audio?

Thank you very much for helping me get my head around how the model
actually works.  I'm much closer now to having a functional system.  All
I have left is fine-tuning, which is a lot better than fighting with
basic functionality.

-- 
David, K9DWR
k9...@gr...