[App_rpt-users] Changes in new version?

[Matt Beasant]

Hi all,

I apologies in advance for this epic email but it is necessary for me to
describe my setup here to accurately detail the issues I am seeing!

I have two repeaters linked with app_rpt nodes but they are set up in
different ways. Essentially the two repeaters are the same in that they have
Arcom RC210 controllers with audio delay boards to remove squelch tails. I
use CTCSS ( PL ) exclusively and my hardware decoders have longish mute
times and the audio delay boards take this right out - I have about 600 or
700ms of audio delay to take out the squelch tail.

My first repeater has the app_rpt node connected to port 2 of the RC210 and
the repeater on port 1. I have linked the two ports via the RC210. The
app_rpt node is running duplex=1 and hangtime=0 as the hangtime is taken
care of by the RC210. This is node 2250. This node has yet to be upgraded to
the latest app_rpt build.

On the next repeater, (2237) I needed to find a way of interfacing the USB
fob with the RC210 without using the second port and linking them together.
The reason for this was that at both sites I have two other (UHF) repeaters
that I need to link together using app_rpt too and as the RC210 has only 3
ports, thats not enough to do it via the RC210. So I tried to find a way of
directly connecting the USB fob to the repeater radio.

So, I picked off the Rx audio on the output of the delay board, T'd off the
COS point and connected the PTT output of the fob to the PTT output of the
RC210, so it can key the Tx.

I was running duplex=3 in my rpt.conf  on this new repeater and had a hang
time of 5 seconds, with CT's setup and everything was fine. It was possible
for a user on the repeater to jump in before the CT had finished and/or
 during the hang time of the node. This was great as I had the CTs set up to
send a "K" on the RC210 ( local activity ) and the app_rpt node send an "R"
for remote activity, everyone could tell whether a signal had come in from
the local repeater or across the link. Effectively the app_rpt was emulating
the RC210.

I updated the software yesterday using a fresh ISO downloaded yesterday
morning and rebuilt the node software to the latest version.

I then copied across my old usbradio.conf file from a backup I made before
the install. This then caused a segfault anytime there was any COS activity.
I used a default usbradio.conf instead of mine and the segfault stopped. I
then changed some of the values to suit my setup and it seems to be working
now.( I will have to go back and visit this again as I dont currently know
which setting I changed in usbradio.conf that stopped the segfault. ( sorry
))

However, things seem to be behaving differently. It seems that the node
ignores any COS signals until the hang timer has expired. I tried using
different duplex settings in rpt.conf and any hang time I have seems to
cause the node to ignore COS until it has expired.

To overcome the problem I am currently running zero hangtime, in duplex mode
1 so the CT plays and the carrier drops right away, Its the only way I can
get the system to operate without loosing the first 5 seconds of rx audio /
COS signal. Duplex mode 3 seems to work in exactly the same way, I cannot
tell the difference but mode 3 seemed to work fine before.

Has something changed in the way the duplex settings are working or the way
in which COS is handled?

Again, apologies for the long email but I didnt want to put a bug report in
as I am really not certain if what I am seeing is a bug or I am not
understanding something right or doing something wrong here, which is most
likely!

I have seen this segfault behaviour before on nodes we built for a
motorsport event's safety comms a couple of weeks ago. Again the pressure
was on as it was a live system and I didnt have time to fiddle about with
usbradio.conf to see what causes it or fixes it. I need to do more work on
this but I am wondering if I am the only one who is seeing this?

Thanks for your patience!

BTW, I am really interested in some of the features that are currently
commented out in the default rpt.conf file - presume some sort of analogue
input / data aquisition device is needed to implement these features?

Thanks to all the developers for all their hard work and hours of effort, it
is really appreciated here!

Best 73,

Matt
G4RKY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20091103/3360d4e4/attachment.html>