[App_rpt-users] usbfobs

[Steve Zingman]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20160706/288c241e/attachment.html>