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