[App_rpt-users] Some newbie questions

Stephen Rodgers sales at qrvc.com
Sat Aug 28 03:52:23 UTC 2010


See my comments below

Steve
WA6ZFT


Nils Prause wrote:
> Hi to everyone,
> 
> I'm trying to set up two nodes here in Germany with a static connection and
> the ability to connect to Allstar and EchoLink. I'm already familiar with
> Asterisk as professional pbx but new to app_rpt. Right now I have some
> issues with the configuration and hope that I can get help on this list.
> I've already read a lot of messages in the archive and also took a look at
> the source code but - as Bono said - I still haven't found what I'm looking
> for. :-) 
> 
> 1. I bought a URI board from DMK, assembled the cable and connected it to
> two Motorola GM 900 transceivers (1x rx, 1x tx). As described in the
> Motorola schematics I used pin 24 on rx and 25 on tx to get flat audio and
> give full audio to tx. If I look for the signals coming from the rx on a
> spectrum analyzer I can see flat audio with a potential of about 500 MV. But
> as I start the analyzing procedure with "radio tune rxnoise" I always get
> the error message that the audio is "too loose". 
> "radio tune rxvoice" seems to work correctly but detecting of CTCSS tones as
> described on the website also fails without any additional error messages. 

Not sure what the actual problem is but if these are narrowband (8K03FE) radios
there could be issues with the DSP squelch and the DSP CTCSS decoder. There was some talk of adding a narrowband switch
to the chan_usbradio config file, but that hasn't happened yet. IMHO, With narrow band radios, you're probably better
off not using the DSP routines for COR and CTCSS and instead configure the URI to use the inputs for COR and CTCSS.

> 
> I adjusted the squelch manually to a value of about 800 but I'm not sure if
> this is the right direction to go. Is anyone else using Motorola GM
> transceivers and can report the same issues? 
> I think that 500 MV should be enough for an URI board. Am I wrong with that?
> 
> 2. My test repeater has an audio delay of about 200 ms. Some guys told me
> that this is much longer than it seems to be on their systems. So, is there
> a way to reduce or manipulate the delay produced by dsp? Which parameters
> can affect this? 

This may be able to be reduced by using chan_simpleusb instead of chan_usbradio, but the bulk of the delay is
probably due to the TDM multiplexing going on in zaptel and asterisk.

> app_rpt runs under Debian on a Core2 Duo machine with 4Gig of memory and a
> fast SATA hdd.
> 
> 3. Most of repeaters in Germany are opened using 1750 Hz burst tone. To
> activate this I set the desired parameters in rpt.conf as described on the
> website <http://app-rpt.qrvc.com/node/156>.
> 
> ----- Tearline begin
> rxburstfreq=1750
> rxbursttime=500
> rxburstthreshold=10
> ----- Tearline end
> 
> I also played around with the values but every time I activate
> rxburstfreq=1750 the repeater just doesn't do anything.
> If I enable debugging I can see ptt keying in the CLI but every time I press
> the 1750 call tone the CLI shows exactly nothing. On the spectrum I can see
> the 1750 hz tone very well so I know that there is a strength signal on the
> input.     
>  
> On the archive I saw that this error was already reported some weeks ago but
> it seems that no one did have a solution for it. I'm not sure what to do now
> because without this feature the whole software is just useless for me. :-(

Jim WB6NIL might be able to answer this as he wrote the tone burst code and did a lot of collaboration
with other German Hams to get it working acceptably.
> 
> 
> 4. In Germany nearly 90% or more of the repeaters work like the following
> scheme:
> - Repeater is opened using 1750 Hz burst tone.
> - When the repeater opens it first plays its id (regardless of its last id).
> 
> - Now the user makes his call. After the user releases ptt the repeater
> stays open for a while (maybe 20 or 30 seconds).
> - At the moment the repeater opens a timer starts. If this timer exceeds the
> id is played again (beaconing). Usually this happens every 10 minutes (the
> timer is set to 600 seconds).
> - If the qso ends before the timer has exceeded the repeater closes and
> that's it.
> - Some operators like to have an id every 10 minutes regardless if the
> repeater is open or not. But most of them only want to have an id played if
> the repeater is still open.
> - Some repeaters have the ability to be opened using ptt only
> (carrier-detect) some seconds after the repeater has been used. For example,
> if the repeater closes a timer of 30 seconds starts. If the user presses the
> ptt within these 30 seconds the repeater opens again (usually without
> playing his id). If the timer exceeds and no one had pressed the ptt the
> repeater goes back to "normal operation mode" and reacts only on 1750 burst
> tone as described above.

> 
> Setting the id timer to 10 minutes is no big deal and setting the hang timer
> to 30 seconds is also done easily. But I can't see how to be sure that the
> id is played every time the repeater opens?

This is not currently in the code.

> 
> If not implemented yet, this could be a good moment to test out the
> facilities of Mantis. :-)

Mantis should be used to log all potential issues so that they don't get lost
in the mailing list forest.

> 
> 
> Thanks for any help in advance.
> 
> 
> 
> --
> 73s, Nils, DO6NP
> 
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at qrvc.com
> http://qrvc.com/mailman/listinfo/app_rpt-users
> 




More information about the App_rpt-users mailing list