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@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users