March 2006 - App_rpt-users - lists.keekles.org

Re: [App_rpt] Radio Interface Question
by James Harfield 08 Mar '06

08 Mar '06

Steve Rodgers wrote: "A couple of things to note here: Tying speaker audio to RXA is not the preferred method. RXA should be tied to the receiver's discriminator output, or to a point where the audio levels are less than a couple of volts peak. Pin 8 should be tied to DC ground. If that is the same as RF ground, that's fine. Microphone inputs tend to be very sensitive. You might need to add some attenuation resistors to the microphone input to knock the audio level from the card down so that you can easily adjust the level. If there is a line level input to your transmitter you'd be better off using that." Measuring the levels of the speaker audio, regardless of volume level on the radio, the voltage does not break 1.5v. Looking at the documentation for the card I felt that this was appropriate. I'm using regular Ground as of now. Grounding PTT with "Ground" and not "RF Ground" keys the radio as it should. So I'll just move my ground pin to there and leave PTT where it is. What I'm doing now is making a small circuit to work as COR. I can't seem to find a working version of the COR in the radio pin out, so I've taken a MOSFET and 5v battery to switch the level from 5v to ground when a signal is present and stay at 5v when no signal is present. Unless I'm blindly missing something to pull off the radio that will work the same way. Something like: +5v | 10k _ |--------------to PCI card >from radio-- |_ | | gnd ASCII art may be butchered in the post though. The level from the radio should be enough to activate the FET and pull that output to ground, while allowing the 5v to pass to the card when there is no signal. Just for reference so you know where I'm coming from, I found a couple of Motorola HT600s on eBay with charger for pretty cheap and am playing with those since they seemed to have easy access to signals with the 13 pins on top. I thought this would be good to learn with while not investing tons of money in expensive radios to break. Thanks for the help while I struggle through this process. -JRH

3 2

[App_rpt] Voters
by Charles Suprin 06 Mar '06

06 Mar '06

Howdy, Has anyone tried to use asterisk as a voting receiver? It seems that if all the receivers are in the same conference bridge then it should work ok. Atleast at first. There may be some enhancements to be made in terms of passing SNR measures either as part of the vocoder stream or as part of the IAX2 metadata to make it a true voter. Charles

3 6

[App_rpt] Motorola MDC-1200 decode supported
by Steve Rodgers 06 Mar '06

06 Mar '06

Group, Jim and I added initial MDC-1200 decode support for app_rpt.c. To use, download the following files from zapatatelephony.org: app_rpt-0.45.c mdc-1200.tar.gz Copy app_rpt-0.45.c to your /usr/src/asterisk/apps directory untar the mdc-1200.tar.gz file and copy the files in the newly created mdc-1200 directory to your /usr/src/asterisk/apps directory Edit app_rpt-0.45.c and make sure the line containing "#include mdc_decode.c" is uncommented. Recompile and install asterisk. Now, when your radio sends a MDC1200 data burst, it's unot ID will be sent immediately following the courtesy tone. Obviously, this is just a start. There are other things we can do with this. Steve, WA6ZFT

1 0

Re: [App_rpt] Radio Interface Question
by James Harfield 04 Mar '06

04 Mar '06

Sorry for the delay, my list subscrption settings may be wrong. I was not receiving the digest or any other e-mails to reply to, or know that anyone had responded. . . moving on: > That assumption isn't correct. It is E&M for zaptel configuration only (not in > hardware). The card interface 4 wire audio even though only a single Zap > channel is specified. In zaptel.conf you should specify: > e&m = 1 > .... > And in zapata.conf you should specify: > signalling=em_txrx > channel = 1 > .... > And in rpt.conf you should specify only ONE zap channel: > [100] ; Name of First Repeater > rxchannel = Zap/1 ; Rx audio/signalling channel > ... Thank you Steve. We do have all of that setup or as you suggested. Went back and double checked after reading your post just to make sure. > Please elaborate on how you are trying to connect. When do you get the "Unable > to create channel Zap" error? Was it when you tried to run Asterisk with > app_rpt compiled in? I'll try to ASCII out how we're connecting to our radio: Radio PCI Side Card Ext Spkr => 1 RXA CVC Sense => 2 COR --not used-- => 3 UIOA --not used-- => 4 Subtone PTT => 5 PTT --not used-- => 6 UIOB Ext Mic => 7 TXA RF Ground => 8 GND With that attached, just through an RJ-45 cable, we load up Asterisk. Then after connecting to Asterisk via a Softphone we try to dial the radio. Our extensions.conf file looks like this for dialing the Zap channel: exten => 205,1,Dial(Zap/1/1999) 1999 was the channel name we gave it. It is at this point, when we dial it, that the "Unable to create channel type Zap" error. > Your concern is true. It isn't true E&M at the hardware level. COR is a input > which accepts voltages from 0 to 13.8V and PTT is an open drain output from a > power MOSFET. See the quadradio_pci_installation.pdf file on app-rpt.qrvc.com > for more information on how to interface to the board. > As stated above, It is E&M only at the software configuration level. > Hooking the signals of the Quad Radio Card to a real E&M interface could > damage the board as -48V exceeds the component ratings of the parts in the > input and output circuits. Hopefully you didn't do this?! That makes a lot of sense. I knew something was up and the -48V thing wouldn't pan out. That's why I wanted to make 100% sure before actually hooking up the base station we had laying around. Thanks again Steve.

4 3

[App_rpt] TDM400 + Feature Requests
by Eric Tichansky 04 Mar '06

04 Mar '06

Steve Awesome! After cleaning up the abondoned modules and other crud from the distribution install, stability seems to be solid. I'll know for sure after letting it set for a few hours and hitting it with an incoming autopatch. I was in contact with Jim Dixon a while back (Dec?) which basically resulted in the duplex=3 mode where incoming RF audio is never retransmitted. He had asked a question during our email exchange, <----- Do you want the audio (Rx->Tx) severed during all times, or just while in autopatch mode? (Obviously, severing it always does not make for a good repeater, but Im not sure thats what you want here). -----> and I attempted to respond, but the email must not have gone through... <----- I still havent gotten your response yet from the last question, but If what you want is to not repeat Rx audio EVER, then try this version with duplex=3. -----> Anyways, to build upon the duplex=3 mode and answer his inquiry... It would be more practical if this mode where modified to only block incoming RF audio during an autopatch. That way the system functions like a normal repeater most of the time, and a full-duplex compatible autopatching sytem during an autopatch (useful for full-duplex crossband autopatching, obviously not wanting to hear yourself). Last feature request: perhaps a way to integrate CallerID in CW during an incoming autopatch announcement. If you could push these upstream to Jim, that would be appreciated. -- Eric Tichansky NI3S eric(a)lylix.net LYLIX.NET

2 1

[App_rpt] TDM400
by Eric Tichansky 03 Mar '06

03 Mar '06

I finally acquired all the RF components for my new 2M/440 crossband repeater, using app_rpt of course! Anyways, just wanted to get a better idea and perhaps more details concerning the problems surrounding the use of the TDM400 series cards with the Analog Radio Interface Board (ARIB). It seems to work fine as long as the system is active. Once idle for an extended period of time, an almost certain segfault results. Using the safe_asterisk script to respawn asterisk after a crash works OK to recover for continued RF communications, but is useless when an incoming phone patch call triggers the segfault -- the call is dumped and just simply annoying. Just wondering what debugging has been done and conclusions as to what aspect of the system seems to be the culprit (TDM 400 hardware, Asterisk, app_rpt)? Are there any other Zaptel compatible FXS cards available for a modest price? -- Eric Tichansky NI3S eric(a)lylix.net LYLIX.NET

2 2