[App_rpt-users] usbfobs

[Jeff DePolo]

> 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