On Sunday 16 March 2008 12:02:20 Erik Finskas wrote:
> > Remote receivers essentially does not load the SvxLink core anything
> > since all DSP (filtering, DTMF detection, CTCSS detection etc) is done on
> > the remote receiver computer. Note however that a fairly big amount of
> > bandwidth is required since each audio stream is 256kbit/s. As soon as a
> > receiver has been voted, the other receivers will be muted though so only
> > one receiver will send audio to the core. Before the voting, all
> > receivers with open squelch will send audio to the core.
> Interresting, what codec is used in the audio stream, that is quite high
> bandwidth for a voice-channel audio. I just read that now Remote TX is
> supported also, so I might put the repeater logic to a datacenter with
> enough bandwidth and run the TX remotely :)
Well, the codec is the "none"-codec ;-)
I just stream 4 byte float samples (8kHz) over the network. It's a bit
experimental at the moment. Adding a codec is on the TODO list. I probably
could use the GSM codec quite easily since it's already used in SvxLink but
that would give much worse sound quality. In the end, I'll probably use the
Speex codec. It sounds quite good even at 8kbit/s.
The upside of using unencoded samples is that you get the exact same audio
quality with remote receivers as if using a local receiver.
> > There is a big BUT for your intended application. I guess you want to be
> > able to connect the four local RF ports together. At the moment SvxLink
> > only support connection of two logic cores at a time. And also, the
> > latest release of SvxLink does not relay module (e.g. EchoLink) audio or
> > detected DTMF digits to the other cores.
> Ahha, good to know. Can I chain the cores, so that they eventually relay
> audio extensively, or is a RF channel considered a logic core?
I'm not sure what you mean by chaining the cores but if you mean linking l1
<-> l2 <-> l3 the answer is no. L2 will hear the audio from both l1 and l3
but l1 and l3 will not hear each other. And yes, there is one logic core for
each RF channel.
However, I could probably quite easily extend the logic core connection code
so that more than two logics can be connected. This has been made possible by
the new audio infrastructure.
> > The latest experimental release of SvxLink do relay module audio to other
> > connected logics. DTMF is still not relayed and only two logics at a time
> > can be connected.
> > Tell me a little bit more how you intend to use your link. Maybe I can
> > add the features you need quite easily.
> Well I'm after the functionality what I can get with a commercial
> multiport controller. I have several Arcom RC-210 controllers, they are
> eventually three-port controllers with capability to have three
> independent repeaters with common "backbone" to link ports together.
That looks like a really nice repeater controller. If you try SvxLink, I'd be
interested in what features you miss the most when compared to the RX-210.
Maybe there is something I can add to make SvxLink even better.
> Where I was thinking of running SVXLink as a demo is the annual SRAL
> meeting here in Finland in July. I run repeaters mostly and I have
> planned a multiband setup to cover at least 2m, 70cm, 23cm and propably
> 10m/6m combined repeater together. And even in addition a network hookup
> to all this if required.
> But was it so that I can run this number of repeaters in a single box,
> although not being able to link all together?
Yes, that should be possible even if I have never tried more than two. This is
one of the original thoughts with SvxLink, being able to run multiple
repeaters with one application and also linking them together is in the
original plan. I just haven't gotten there 100% yet :-)
Another drawback is if you want to be able to run EchoLink on all repeaters.
The EchoLink module can only be loaded in one core and as I said, DTMF
commands are not transported between logics at the moment. It's not obvious
how this should work. Should all DTMF be transported to a "master logic core"
when the link is active or what? Should all DTMF commands be ignored by
the "local" core? I think this is the reason why I don't transport DTMF
between linked logic cores today. It requires some more thought.
> Little more about the voting process, how many remote RX's is supported
> and how is the voting done? By what criteria I mean, signal to noise
> measurement or RSSI? I suppose a flat audio connection is required to
> the application from the receiver.
In theory the number of remote receivers is unlimited. In practice it's
probably limited by bandwidth at the moment since all receivers send audio to
the core before voting is done. This could probably be improved by not
sending any audio to the core before a receiver has been chosen.
The voter is what one could call a "poor man's voter". It get signal strength
reports upon squelch open. It then wait a while to give all receivers a
chance to report their signal strength and then choose the strongest one. It
will then hold on to this receiver until the squelch is closed.
The signal strength calculation is done by first applying a high pass filter
at like 3.5kHz and then calculating the remaining audio power. The idea being
that most of the speech energy should be filtered away and only the noise in
the audio signal will remain. So:
a lot of remaining energy => a lot of noise => weak signal
small amount of remaining energy => small amount of noise => strong signal
In it's simplicity it actually works quite well but could be further improved.
The audio connection is not critical but the deemphasis/preemphasis filters in
SvxLink are experimental. I guess flat audio would be preferable in a
repeater. The only problem is the EchoLink module. Maybe pre/de-emphasis
should be implemented there instead of in the receiver/transmitter objects.
The DTMF decoder should perform worse if not first doing deemphasis but
strangely enough, my experience is that it performs worse when the filter is
enabled. Maybe the filter have too much ripple in the passband or I just have
made some error.
I have some further ideas for the voter. The problem with remotely linked in
audio is to synchronize it to the point where the receiver could be switched
without causing a repetition or jump in the audio stream. This will make it a
bit more complicated. I'll probably will experiment with this some day but I
guess it's in a distant future.
If not using remote receivers via IP but rather multiple local receivers
things get a little bit easier. At least for two receivers. If sampling two
channels with the left/right stereo channel the two audio streams will be in
sync and switching between them would not be a problem. This is a more
traditional voter and I'll probably implement this as well some day.
I hope I answered all your questions. I'm willing to work with you to get
SvxLink good enough for the SRAL demo. Try it out and see what you think
about all the experimental features :-)
73's de SM0SVX / Tobias
> >>>> Some other VoIP or RoIP software have started to support simple and
> >>>> dead cheap USB audio dongles based on the C108 audio chip. The chip
> >>>> has GPIO pins available for PTT and COS signal lines.
> >>> Can you give an example of a device that use this chip?
> >> The chip is CMEDIA CM108, to be exact and is available through online
> >> shops, for example this:
> >> http://www.geeks.com/details.asp?invtid=CL-SU4CH&cpc=SCH
> > Ah, it was that good old chip. You wrote C108 in your initial mail and
> > that did not give any hits on Google. I should have realized what you
> > actually meant...
> > So you have to get your soldering iron hot and add a couple of wires for
> > GPIO I guess.
> >>> I guess the audio is supported out of the box by Linux/ALSA but the
> >>> GPIO pins would require special support to be added to SvxLink.
> >> Yes, at least CentOS and Debian recognizes the audio device with
> >> standard modules, the GPIO needs special support. Skip WB6YMH is the
> >> author of TheLinkBox, which source code is available for download from
> >> it's Yahoo Group page (Group: Thelinkbox)
> > Yes, I know about TheLinkBox. Never tried it though. Maybe I'll have a
> > look at this in the future but not right now.
> > If you want to try the experimental version, check the source code out
> > from Subversion:
> > svn co
> > https://svxlink.svn.sf.net/svnroot/svxlink/branches/audio_pipe_port/src
> > svxlink
> > 73's de SM0SVX / Tobias
> >> 73
> >> Erik OH2LAK
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Svxlink-devel mailing list
> > Svxlink-devel@...
> > https://lists.sourceforge.net/lists/listinfo/svxlink-devel
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> Svxlink-devel mailing list