[App_rpt-users] USB Sucks Yay! The Sequel!

[David McGough]

I want to comment as well that the USB woes seen with asterisk/app_rpt are
NOT a systemic linux issue, in my experience. I am running a hacked
version of the linux "soundmodem" software packet MODEM that interfaces
with CM108 USB soundcards.  Specifically, I'm using DMK URI cards.
Soundmodem controls the PTT signaling and can monitor COS, etc. Note that
as Doug mentioned, if ANY USB sound related drops/pops/clicks were to
occur, the result would be trashed data packets. I'm using the URI's on
busy APRS nodes and see outstanding results. These systems have been so
reliable that I've got them in difficult to reach locations (like 900 ft.
up a tower!) and they just sit there an run.

Anyway....

73, David KB4FXC


On Thu, 12 Jan 2012, Doug Bade wrote:

> I would have to say that the issue discussed with USB drops/pops/clicks  is
> NOT an issue that "has to be".  I use USB sound interfaces (CM108) for my
> D-Star repeater(s) running dstarrepeatercontroller software. One of my
> system production tests is to generate a dtmf character from my dstar
> portable and listen to the recovered dtmf on the far end. If you are
> familiar with AMBE and dtmf issues, the AMBE codec handles dtmf as a command
> string and sends it through as a command sequence to be regenerated on the
> far end. If there is *any* breaks in the data stream encoded through the usb
> sound fob, it will be manifested in a break in the dtmf recovered
> presentation on the far end. In many setups along the way, this was a
> problem, however it *CAN* be tweaked and time slicing corrected to allow no
> drops. I have a production system that does not have drops for sustained
> PTT's up to/in excess of 3 minutes of a sustained dtmf character that are
> clean for that time frame. The data rate of Dstar would seem to exceed any
> analog presentation that Allstar may build.
> 
>  
> 
>                 So. It CAN work, it may be that some tweaking of Allstar
> and/or the linux code may need to happen, but to say with certainty that
> sound fob repeaters are not production quality is unfair at least in my
> world. As I can demonstrate otherwise.. uptimes in excess of months are
> typical and no USB hangs or dropson both of my dstar GMSK repeaters 
> 
>  
> 
>                 I would also suggest that certain issues may be present in
> USB sound fob systems of Allstar that have a problem I/We detected in the
> dstar world of implementation that may have to do with some issues in usb
> sound implementation. All CM1xx chipsets were designed for telephony and as
> such have a sidetone function built in. There is an internal audio loop from
> the mic side to the headset side. It is designed to provide comfort audio to
> your ear while you are talking but in our repeater world provides a direct,
> low level direct analog loop between rx audio and the transmitter. Depending
> on series resistance vales and coupling, these levels can become an issue,
> it definitely is to GMSK modem data of our dstar implementations.. What
> happens is you have 2 loops out of time, one direct and one through the
> computer dsp. This is problematical in things that are sensitive to phase
> shift and can result in cancelleation etc. A quick and dirty solution is to
> use 2 sound fobs for repeating. as one for tx and one for rx. The circuits
> are isolated and no dual audio path.. Using 2 DMK URI's might be cost
> prohibitive for the most part. but sound fobs can replace maybe one end or
> the other on TX or RX. I am not sure how the Allstar implementation would
> handle that but it could be done,as  my USB URI implementations for Allstar
> are working quite well. 
> 
>  
> 
>                 Where I am going with all this is "glitchiness" of the
> systems may be resolvable issues as we HAVE resolutions in dstar. so flat
> out bad rapping sound fobs is  maybe not really appropriate..
> 
> A significant issue and problem using FXO/FXS cards is you need to deal with
> line supervision issues and ptt/cor which are not part of the FXO FXS
> "normal" implementation. It can be done but I did some work on a system for
> work where we tried to use a pair of Multitech FXO/FXS units to link 2
> radios and it was a lot more cumbersome than was worth.. We ended up opting
> for Multitech's  E&M versions as audio and signaling are not directly linked
> and E&M signaling translates to PTT and COR a lot easier. CTCSS is still
> going to be an issue as that would be out-of-band audio for Telco class
> FXO/FXS/E&M hardware.
> 
>  
> 
> E&M is used for microwave analog radio linking because it foots the bill
> very well.. but it does not carry CTCSS either way directly. 
> 
>  
> 
> Doug
> 
> KD8B
> 
>  
> 
>  
> 
>  
> 
> From: app_rpt-users-bounces at ohnosec.org
> [mailto:app_rpt-users-bounces at ohnosec.org] On Behalf Of Steve Gladden
> Sent: Thursday, January 12, 2012 10:05 AM
> To: app_rpt-users at ohnosec.org
> Subject: [App_rpt-users] USB Sucks Yay! The Sequel!
> 
>  
> 
>  My understanding is that you can use *any* digium FXO/FXS (and possibly a
> less expensive clone) card it will work well and skrew the piece of crap USB
> interfaces.
> I further understand/think that it *MUST* be a two port card with both FXO
> and FXS present is this true?
> Or can you somehow get away with a single port FXO or FXS card?
> 
> Single port cards are cost comparative to a ready made DRI USB which is
> --->>>>>*NOT*<<<<<--- production remote repeater site quality/capable and
> good only for testing experimenting etc.
> Even if such a card is TWICE the price of a DMK URI..  This is the way to go
> for a production system..
> Which is *ALL* that I would ever run at a site..
> And home I'll still maybe d*** around with USB interfaces which truly suck
> with app_rpt in ALL of my testing I've done in 3 years.
> 
> Am I clear in this understanding?
> 
>  
> 
> Any suggestions on cards/Interfaces that work well?
> 
> Any that don't?? stick with Digium?
> 
> I should have asked this bundle of questions 2 years ago *sigh*
> 
>  
> 
> I realize newer boards will not have PCI slots..  
> "USB sucks + is unrealiable"
> 
> -->as I have been assured both through my own testing and the developers of
> app_rpt.
> 
> If you tell me you have a perfectly working sytem I'll have you do *my test*
> sit & listen locally at the system to the TX on continuously with PL encode
> and you *will* hear the audio pops & interruptions in the trasnmitted audio
> that I am confident are present in ALL usb installed systems :-).. but has
> been proven liveable for most.
> 
> If you absolutely have to go with USB for whatever reason beagleboard etc..
> small low power controller
> then it's time for a different controller if you require production/site
> performance & reliability.
> 
>  
> 
>  
> 
>  
> 
> 
> Michigan Broadband Systems
> Connecting Your Business!
>  
> 
> 
> +1 734.527.7150 Direct
> +1 248.327.4389 Fax
> steve at michiganbroadband.com
> www.michiganbroadband.com
>  
> 
>   _____  
> 
> From: app_rpt-users-bounces at ohnosec.org [app_rpt-users-bounces at ohnosec.org]
> On Behalf Of Bradley Haney [kc9gqr at gmail.com]
> Sent: Tuesday, January 10, 2012 2:24 PM
> To: app_rpt-users at ohnosec.org
> Subject: Re: [App_rpt-users] App_rpt-users Digest, Vol 35, Issue 20
> 
> I thought i would get the server set up and then get the USB to radio
> interface.. what is the best and cheap one to buy.  I don't want to roll my
> own  as if everything works out well we will move the unit to the repeater
> site in the Spring. But for now  i was going to put it on a simplex node.
> I just didn't want to buy the adapter then stuck with it with no way to
> configure the server..    for the time being i will hook it to the ft2600
> yaesu ..
> 
>  
> 
> any thoughts on usb to radio interface?
> 
> On Tue, Jan 10, 2012 at 11:00 AM, <app_rpt-users-request at ohnosec.org> wrote:
> 
> Send App_rpt-users mailing list submissions to
>        app_rpt-users at ohnosec.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
> or, via email, send a message with subject or body 'help' to
>        app_rpt-users-request at ohnosec.org
> 
> You can reach the person managing the list at
>        app_rpt-users-owner at ohnosec.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of App_rpt-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Registartion failure -To those who assisted.... (DougH)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 10 Jan 2012 12:00:58 -0000
> From: "DougH" <specialq.que at ntlworld.com>
> To: <App_rpt-users at ohnosec.org>
> Subject: [App_rpt-users] Registartion failure -To those who
>        assisted....
> Message-ID: <A4EDABEE3C824FBEB8F9CDFAE083E47C at DougLaptop2>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>        reply-type=original
> 
> ....in my 'Registration Failure' question. Thank you.....situation has been
> resolved due to a combination of your inputs.
> 
> Help much appreciated,
> 
> Regards,
> Doug - MM0BJA
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at ohnosec.org
> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
> 
> 
> End of App_rpt-users Digest, Vol 35, Issue 20
> *********************************************
> 
>  
> 
>