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@ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of Steve Gladden Sent: Thursday, January 12, 2012 10:05 AM To: app_rpt-users@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@michiganbroadband.com www.michiganbroadband.com
_____
From: app_rpt-users-bounces@ohnosec.org [app_rpt-users-bounces@ohnosec.org] On Behalf Of Bradley Haney [kc9gqr@gmail.com] Sent: Tuesday, January 10, 2012 2:24 PM To: app_rpt-users@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@ohnosec.org> wrote:
Send App_rpt-users mailing list submissions to app_rpt-users@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@ohnosec.org
You can reach the person managing the list at app_rpt-users-owner@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@ntlworld.com> To: <App_rpt-users@ohnosec.org> Subject: [App_rpt-users] Registartion failure -To those who assisted.... Message-ID: <A4EDABEE3C824FBEB8F9CDFAE083E47C@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@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
End of App_rpt-users Digest, Vol 35, Issue 20 *********************************************