[App_rpt-users] usbfobs

Steve Zingman szingman at msgstor.com
Wed Jul 6 16:45:15 EDT 2016

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 
> 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

"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.allstarlink.org/pipermail/app_rpt-users/attachments/20160706/288c241e/attachment.html>

More information about the App_rpt-users mailing list