On 07/06/2016 04:03 PM, Steve Wright
wrote:
Lists aren't about one person building one machine,
lists are about system-builders assembling a nation - and that
process being doable with quality dividends, so it is easy for one
person to announce costs being minimal for one system, but if that
single device were implemented globally, that would be six or
seven figures. That'd be nice for those who supplied that device,
but I don't think they'll get it.
Lists are for people to exchange ideas. Not all people agree what
the right way to accomplish a task. Calling people "
Millionaire Hams" does not encourage polite discussion. With the
current tools available building a single board controller with a
CPU and a couple of Codecs is quite doable.
I mean to say, app_rpt can, and should, be on every
transmit and receive interface on every mountaintop. Be honest -
conversion of all systems is our goal, not because we might, but
because of the immense flexibility it would forward, without
really any effort at all. So how to actually get that? Using a
$300 box for every TX and RX? No, it's not going to happen.
Using a <$100 box with four TX and four RX interfaces? Just
maybe..
If a single group is installing EVERY mountaintop, I can see them
choosing app_rpt. Put 5 groups or 1000 groups in charge and you will
get differing opinions.
That's quite a jump from a $300 box for one TX / RX pair to $100 for
four TX / RX pairs. Some people are advocating 1 hardened computer
for each site, not each pair.
I suggest finding
a way to replace the I/O lines with something else because ANY
dsp should work fine for the audio. I think the PI itself has
them. Just have to write the code to replace it OR use
"ON-EVENT" programming to read/write to them to follow ptt/cos.
Since Asterisk and app_rpt are open source, feel free to "just write
the code"
The Pi is already good to go, and some of the channel drivers will
already use the onboard I/O.
There just isn't a driver that does ALSA audio, DSP, generic GPIO,
and voting. If there was, we'd never be having this discussion
ever again. Also, it'd be dead trivial to write a config script
to set the whole thing up.
Actually, there is a ALSA driver that does DSP I suggest you look at
the SVN. For the voting, just port the code from XIPAR.
drivers? hardware?
integration with existing codebase? takes time and (unpaid)
effort. -- Bryan
All the really great ideas get implemented at some stage. The
person who WANTS to do it, notes it and puts it on the back burner
- to be implemented NEXT. All visionaries implement the BEST
idea, not their own idea. Discussions like this only pave the
way, or is it 'a' way..
As Bryan says, All it takes is time.
Or maybe, digital is better...
Digital has some advantages, audio quality is not one of them. There
is Open Source digital code, so implement what you want.
73, Steve N4IRS
INAD
--
"Anything is possible if you don't know what you are talking about."
1st Law of Logic