Quoting Graham Norbury <gnorbury(a)bondcar.com>om>:
On 9/7/20 11:19 AM, op25(a)zellners.com wrote:
OP25 doesn't work that way , and with out a major rewrite to do that
you are better to just set a smaller bandwidth/sample rate as the rest
is wasted processing.
I set my op25 setups to be about 1MSPS or so as thats more than enough
for things.
Sorry to disagree but op25 can and does work that way if correctly
configured under either rx.py or multi_rx.py. In fact the multi_rx.py
implementation is designed to support an arbitrary number of trunking
systems and voice channel decodes using 1-to-/N/ SDR devices.
Maybe this will settle this. ** I AM WRONG. ** Period.
So where is the MULTI_rx.py documented???
I've never seen or even heard of this. Or documented at all really.
Its all just letting it trunk from a CC like a scanner......Or this
mode with a center freq...
So lets discuss what it can do... you mention multiple CC and multiple
audio feed...
liquidsoap...
Yuck not really a fan.. ....but anyway....
So lets start with 1 CC and doing MULTIPLE FEEDS????
How is all this plumbed together to get this my IceCast server???
Audio losses from "scanning" or this is queued up to feed in serial
fashion?????
One CC would need at minimum 5 feeds.... and how is all this audio
held/queued up??? So if say 2 TGID's are active???? I can see issues
trying this on a PI with the writes to an SD card right there.
, but the
penalty for going that route is having to deal with multiple antennas
(or a splitter) to try to capture an already marginal signal.
I have a dedicated yagi to point to one system. And fed through
LMR400, low noise distribution amp to provide plenty of ports.
Same with my setup for more localized system on an omni, LMR400, low
noise dist. amp and multiple ports. More than I need really.
Basically its the same setup you would see at the rx end of a site.