Hi, I've been on the fence between using app_rpt and getting an analog controller such as the RC-210 for awhile now; I'd really love to have the flexibility of app_rpt, but there is one feature that the rc-210 gives me that I don't see a way to do with app_rpt. What I eventually plan to do is to have a 440, a 220, and a 2m repeater all linked together more or less permanently -- this is so that members of our club (many of whom are beginners) can try out different bands and learn to use them but still for sure have someone to talk to (220 in particular is pretty dead around here). Anyway, I'd really like to have some easy way for everyone to be able to tell which repeater the transmission came in on; with the RC-210 my plan was to have a different courtesy tone depending on the source. e.g. 2m repeater originating transmissions would have CT1, 440 CT2, 220 CT3. Another need I have is to be able to send a DTMF command code to change the basic CT of the repeater to a double beep to indicate that a net is in progress; I think I can do that using a macro which runs a shell script, changes the config file, and runs "rpt reload". So, my question is this: is it possible to trigger a macro or function or something that I could use to run arbitrary code every time a transmission started which would know which node that transmission came from? Then I could set the CT based on which node is originating the transmission each time. Other ideas for solving the problem would also be welcome. =] I'm a developer with C experience and some background in asterisk so I'm willing to do some work in the app_rpt.c code as well if needed, but I've found diving in without asking first often means solving the problem in a non-ideal way =] Thanks, Richard KD7BBC
Hi, Le 12/09/2016 à 07:22, Richard Bateman a écrit :
Anyway, I'd really like to have some easy way for everyone to be able to tell which repeater the transmission came in on; with the RC-210 my plan was to have a different courtesy tone depending on the source. e.g. 2m repeater originating transmissions would have CT1, 440 CT2, 220 CT3.
You can't. At least, I didn't find how to do that ;-) I just managed to get two separate CTs : - One CT for the users coming from the "radio" (those who are received on the radio directly attached to the node) - Another CT for the users coming from the "link" (any other user, connected to any other node elsewhere, and coming through an IAX2 connection) There are also other drawbacks with CTs : no CT at all for VoIP users (IAX/SIP), and no differentiation also for Echolink users
So, my question is this: is it possible to trigger a macro or function or something that I could use to run arbitrary code every time a transmission started which would know which node that transmission came from? Then I could set the CT based on which node is originating the transmission each time.
I've got such a "work in progress" : a daemon that opens a shell on Asterisk (asterisk -r), switches to "debug" mode, parses the output to gather information, and can send instructions. All that is driven by a Python controller (where I'll implement my specific needs : take the appropriate action when conditions are met). A tiny WEB interface allows for basic remote monitoring and control. But that's still in an early stage (ie, nothing usable). I'll post it there as soon as it becomes usable in other situations than mine. But I'm not sure I'll be able to change CTs according to the "origin" of the audio flow...
I'm a developer with C experience and some background in asterisk so I'm willing to do some work in the app_rpt.c code as well if needed, but I've found diving in without asking first often means solving the problem in a non-ideal way =]
I don't understand C, I never enjoyed it, thus I never managed to learn it, HI :-) I already had a look at the source of app_rpt, but that's far out of my skills. That's why I choosed to write a "companion" software in Python, to be able to write some kind of "macros" at an upper layer. But if you have the skills to dive into the source, I think it would be a great idea. There are lots of things that may benefit from new developments/enhancements. 73 de TK1BI
participants (2)
-
Richard Bateman -
Toussaint OTTAVI