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

That's a generalisation - that the RPI3 are unreliable.

I didn't say they were generally unreliable. I said that I, and many others, prefer server-grade hardware, such as RAID, redundant power supplies, tight RFI/EMI shielding, cooling that will keep the system running when the HVAC fails, ECC memory, etc., both for the sake of maximizing uptime as well as avoiding trips to the site (those trips possibly being several hours' driving each way).

It'd be nice to throw high-end hardware at everything, but if you had a very large system to build - I don't think you would be doing that.

Well, I've lost count of how many repeaters I have. Somewhere around 40 I think, and maybe another 15 or 20 voted receive-only sites. That's not including repeaters that I've built/maintained for others. So I'm no stranger to building repeaters, nor the costs associated with them, as I eat all of those costs myself. Once you get beyond a couple of repeaters, your available time quickly becomes the limiting factor when it comes to building more repeaters as well as maintaining the ones you already have. At least that has always been the case for me over the years. If I can put some extra money into more-robust hardware (be it radio equipment, controller/server, antenna system, or whatever) knowing that it will save me one or more future trips to a site several hours away, or saving money on repair/replacement costs (both materials and labor) a few years down the road, it seems silly not to. I'm not rich enough to buy cheap.

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.

Well, that's not my goal. I have analog repeater networks that are RF-linked. I have Asterisk systems, some of which are at sites with wireline Internet access, others that rely on point to point microwave for IP connectivity, and other sites that use analog RF link paths to/from the host server site with network connectivity. I have DMR repeaters, both fed by wireline Internet as well as microwave. I have experimental multi-mode repeaters doing D-star, DMR, and Fusion all in one box. My goal isn't to merge them all into one big blob, but rather to have different repeaters, different modes, and different networks for different purposes. Maybe I'm in the minority here, but I can't believe I'm alone in not wanting to build one be-all network.

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

$300 is going to break the bank on a repeater installation?!!?!? Maybe I should move to NZ where things are apparently a whole lot cheaper than they are here :-)

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

I'd love to meet the guy that has both the time to write a new channel driver AND build/maintain a bunch of repeaters. In fact, I'd love to be that guy myself. But I'd have to quit my job in order to have the time, and that's not in the cards yet, and probably won't be for another 10 years. My contribution to the app_rpt code has been infintesimally small compared to the heavy-lifting that WB6NIL, W9SH, WA6ZFT, N4IRR, N4IRS, et al have done, and continue to do. They are the ones enabling us repeater builders to do what we do. While we can give them our thoughts and ideas about what the "best way" is to do it from our perspective as repeater builders, keep in mind that they are time-limited and have to make design and coding decisions that strike a balance between "best" and "time-effecient". One thing that is often ignored, and is something that Scott and Kevin touched on, is the timing issue. There is a bit of a "dirtly little secret" when it comes to the combination of Asterisk/app_rpt, the USB channel drivers, and IAX2 - there is no synchronization. The USB codec (CM108 or equiv) runs natively at 48 kHz sample rate, and is downsampled/upsampled to/from 8 kHz for transport. The codec's clock effectively sets the timing, and there is no synchronization between that clock and any of the other local clocks elsewhere on the network. The CM108's clock is derived from a 12 MHz crystal reference; an on-device PLL generates other frequencies used internally, but it's that crystal oscillator that determines the frequency stability/accuracy of the sample clock. Unless someone knows something that I don't, there is no inherent way to embed or convey timing information in IAX2 such as via adaptive clock recovery based on packet arrival cadence (though I'd be happy to be corrected). To do conventional adaptive clock recovery would require one node to serve as the master clock, with a continuous stream of timing packets sent to all other connected nodes, and a software PLL to recover the clock at each slave. Lacking such network timing synchronization (actually frequency syntonation for you purists), it is important that all clocks across the network be as accurate as possible to minimize slips. When you start to consider mixing and matching other audio subsystems/codecs/drivers/etc., each with potentially less-accurate clocks if they aren't locked to a decent reference, you get into very murky waters. As far as the PTT/COR GPIO goes, the CM108's HID was obviously attractive for this purpose. From an audio performance standpoint, the CM108 series is just fine. The crystal reference seems to have been mostly "good enough" as far as the timing goes, Yeah, there are occasional slips, but it seems to have been pretty well-tolerated and have mostly gone unnoticed. So it's not really a problem with the chosen codec having been a bad one - it wasn't, all things considered (including cost). The complaint, as I'm hearing it, is the dwindling availability of cheap CM108 FOB's with authentic, and un-potted, devices. But there are still plenty of high-quality CM108-based interfaces available from Scott/Repeater-Builder, Kevin/Masters Communications, DMK, et al, albeit not as cheap as a $5 FOB. But is your time worth that little that spending time hacking up a $5 FOB really makes sense in the big picture? I, as a repeater owner (and someone who used to write software for a living), could not, in good conscience, ask those writing the code to develop a new channel driver just to so I didn't have to buy one of these readily-available sub-$100 interfaces. Maybe if I were paying them a few hundred dollars an hour to write the code I might feel justified in asking, but for free, absolutely not. Pony up, buy a decent (and reliable) interface, move on. My opinion anyway. --- Jeff WN3A --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus