Hey Guys; I need to execute a couple of scripts when a connection is first established and then disconnected. I have the following in rpt.conf: connpgm=full_path_to_script/name_of_script discpgm=full_path_to_script/name_of_script This doesn't seem to be calling the script - I don't see any attempt to call the script when monitoring CLI either. Any ideas? Thx! Ramesh.
Hi Everyone, Before I start hacking on the code, I though I'd ask if there is any current way the to perform a disconnect operation for all echolink or IRLP nodes??? I know about (and am currently using) ilink command 6 to perform an "all disconnect"....But, I need to be more selective. Thanks in advance! 73, David kb4fxc
Outside of disconnecting manually, I don't think there is a way to disconnect only echolink stations. IRLP one is easy since you can only have a single node connected. Jim, K6JWN On Sep 23, 2009, at 2:51 PM, David McGough wrote:
Hi Everyone,
Before I start hacking on the code, I though I'd ask if there is any current way the to perform a disconnect operation for all echolink or IRLP nodes??? I know about (and am currently using) ilink command 6 to perform an "all disconnect"....But, I need to be more selective.
Thanks in advance!
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
James Nessen wrote:
Outside of disconnecting manually, I don't think there is a way to disconnect only echolink stations. IRLP one is easy since you can only have a single node connected.
Jim, K6JWN
On Sep 23, 2009, at 2:51 PM, David McGough wrote:
Hi Everyone,
Before I start hacking on the code, I though I'd ask if there is any current way the to perform a disconnect operation for all echolink or IRLP nodes??? I know about (and am currently using) ilink command 6 to perform an "all disconnect"....But, I need to be more selective.
Thanks in advance!
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
Here's a way it could possibly be done without changing any C source code... <Rube_Golberg_mode = on> 1. Use the autopatch to invoke a context in extensions.conf 2. Use the system command in the context to call a script 3. Have the script do an asterisk -rx rpt nodes xxxx and parse the output for nodes beginning with a 3 or 4. (After throwing out the leading R.C, or T) 4. Have the script send disconnect commands for each matching node: asterisk -rx rpt fun *1node 5. Exit the script <Rube_Golberg_mode = off> You may run in to some snags. I haven't tried this myself it's just an idea. Steve WA6ZFT
On Wed, 23 Sep 2009, Stephen Rodgers wrote: <snip>
Here's a way it could possibly be done without changing any C source code...
<Rube_Golberg_mode = on>
1. Use the autopatch to invoke a context in extensions.conf 2. Use the system command in the context to call a script 3. Have the script do an asterisk -rx rpt nodes xxxx and parse the output for nodes beginning with a 3 or 4. (After throwing out the leading R.C, or T) 4. Have the script send disconnect commands for each matching node: asterisk -rx rpt fun *1node 5. Exit the script
<Rube_Golberg_mode = off>
You may run in to some snags. I haven't tried this myself it's just an idea.
Steve WA6ZFT
Hey! That's an intereting idea! I just tried tests from the command line and I think it'll work GREAT! ...I'll put together a script and report back. This kind of scripted approach would be very very useful for remote base controls, too, IMO---Rather than hacking on app_rpt.c to add an another radio type or features, etc....Then, hooking in a "do it all" library (eg: hamlib) would be painless--AND, it would be a completely separate module that doesn't introduce show-stopping bugs or have to be directly maintained as part of the app_rpt codebase. The reason I bring this up is that I'm very successfully using an Icom M-710 radio for HF remote base. But, it uses NMEA-0183 control sentences. And, right now I have to hack, hack everytime I upgrade app_rpt.c... Separate scripts/modules would be SOOOO much easier! ....And Ole Rube would be prowd, too! 73, David kb4fxc
app_rpt is quite flexible like that. Using a completely silent autopatch call, coupled w/ dialplan + a couple bash scripts allows us to change almost every node stanza parameter, cw attributes, and build new courtesy tones in rpt.conf as well as zaptel.conf parameters using just DTMF over the air, with changes activated in realtime. We've even implemented a 100 slot "DVR" using silent autopatch for playback, record, delete. The messages can then be used as tail messages, which, again, are added/removed from a silent autopatch -> script tail messages parameter "editor" using over-the-air DTMF commands. There is also a "command mode lock and unlock" function to avoid unauthorized use of the above. Just a simple Asterisk DB entry that is toggled by a command + security code, and checked prior to every command call. We may eventually consider mashing together a distributable AGI script to eliminate the dialplan ugliness. There's quite a lot of flexibility and functionality that can be squeezed out of app_rpt if you don't mind getting dirty. 73 - eric - no3m
Hey! That's an intereting idea! I just tried tests from the command line and I think it'll work GREAT! ...I'll put together a script and report back.
This kind of scripted approach would be very very useful for remote base controls, too, IMO---Rather than hacking on app_rpt.c to add an another radio type or features, etc....Then, hooking in a "do it all" library (eg: hamlib) would be painless--AND, it would be a completely separate module that doesn't introduce show-stopping bugs or have to be directly maintained as part of the app_rpt codebase.
The reason I bring this up is that I'm very successfully using an Icom M-710 radio for HF remote base. But, it uses NMEA-0183 control sentences. And, right now I have to hack, hack everytime I upgrade app_rpt.c... Separate scripts/modules would be SOOOO much easier! ....And Ole Rube would be prowd, too!
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
I would be curious to see this (if you don't mind sharing). This is one part of asterisk that has baffled me. Jim, K6JWN On Sep 24, 2009, at 11:47 AM, Eric Tichansky wrote:
app_rpt is quite flexible like that.
Using a completely silent autopatch call, coupled w/ dialplan + a couple bash scripts allows us to change almost every node stanza parameter, cw attributes, and build new courtesy tones in rpt.conf as well as zaptel.conf parameters using just DTMF over the air, with changes activated in realtime. We've even implemented a 100 slot "DVR" using silent autopatch for playback, record, delete. The messages can then be used as tail messages, which, again, are added/removed from a silent autopatch -> script tail messages parameter "editor" using over-the- air DTMF commands. There is also a "command mode lock and unlock" function to avoid unauthorized use of the above. Just a simple Asterisk DB entry that is toggled by a command + security code, and checked prior to every command call.
We may eventually consider mashing together a distributable AGI script to eliminate the dialplan ugliness.
There's quite a lot of flexibility and functionality that can be squeezed out of app_rpt if you don't mind getting dirty.
73 - eric - no3m
Hey! That's an intereting idea! I just tried tests from the command line and I think it'll work GREAT! ...I'll put together a script and report back.
This kind of scripted approach would be very very useful for remote base controls, too, IMO---Rather than hacking on app_rpt.c to add an another radio type or features, etc....Then, hooking in a "do it all" library (eg: hamlib) would be painless--AND, it would be a completely separate module that doesn't introduce show-stopping bugs or have to be directly maintained as part of the app_rpt codebase.
The reason I bring this up is that I'm very successfully using an Icom M-710 radio for HF remote base. But, it uses NMEA-0183 control sentences. And, right now I have to hack, hack everytime I upgrade app_rpt.c... Separate scripts/modules would be SOOOO much easier! ....And Ole Rube would be prowd, too!
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
Hi Eric, I'm very interested in your enhancements! Would you mind sharing this code? I'll be glad to contribute my changes, too! 73, David kb4fxc On Thu, 24 Sep 2009, Eric Tichansky wrote:
app_rpt is quite flexible like that.
Using a completely silent autopatch call, coupled w/ dialplan + a couple bash scripts allows us to change almost every node stanza parameter, cw attributes, and build new courtesy tones in rpt.conf as well as zaptel.conf parameters using just DTMF over the air, with changes activated in realtime. We've even implemented a 100 slot "DVR" using silent autopatch for playback, record, delete. The messages can then be used as tail messages, which, again, are added/removed from a silent autopatch -> script tail messages parameter "editor" using over-the-air DTMF commands. There is also a "command mode lock and unlock" function to avoid unauthorized use of the above. Just a simple Asterisk DB entry that is toggled by a command + security code, and checked prior to every command call.
We may eventually consider mashing together a distributable AGI script to eliminate the dialplan ugliness.
There's quite a lot of flexibility and functionality that can be squeezed out of app_rpt if you don't mind getting dirty.
73 - eric - no3m
Hey! That's an intereting idea! I just tried tests from the command line and I think it'll work GREAT! ...I'll put together a script and report back.
This kind of scripted approach would be very very useful for remote base controls, too, IMO---Rather than hacking on app_rpt.c to add an another radio type or features, etc....Then, hooking in a "do it all" library (eg: hamlib) would be painless--AND, it would be a completely separate module that doesn't introduce show-stopping bugs or have to be directly maintained as part of the app_rpt codebase.
The reason I bring this up is that I'm very successfully using an Icom M-710 radio for HF remote base. But, it uses NMEA-0183 control sentences. And, right now I have to hack, hack everytime I upgrade app_rpt.c... Separate scripts/modules would be SOOOO much easier! ....And Ole Rube would be prowd, too!
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
Jim/David/et.al. I'll try to sanitize and consolidate the randomness in the next few days and elaborate more on the dialplan/scripts/etc. used to accomplish live config changes. - no3m David McGough wrote:
Hi Eric,
I'm very interested in your enhancements! Would you mind sharing this code? I'll be glad to contribute my changes, too!
73, David kb4fxc
Hi Everyone, I just noticed an oddity related to the ID timer. I have a new simplex 10m FM node setup in rpt.conf as a "standard node" (not as a "remote base") with duplex=0. In the usbradio.conf file, duplex=0 is set for this node as well....This node won't ID unless its TX is already keyed when it is time to ID. But, the asterisk screen indicates that it IS IDing properly--it shows: "Playing 'xxxxx' (language 'en').......It just doesn't key the 10m TX. Note that this node is fully functional, otherwise. And, I'm using app_rpt.c version 0.201 from svn. Oh, and I'm using an idrecording ulaw audio file config'ed for the node in rpt.conf. Any ideas? 73, David kb4fxc
David McGough wrote:
Hi Everyone,
I just noticed an oddity related to the ID timer. I have a new simplex 10m FM node setup in rpt.conf as a "standard node" (not as a "remote base") with duplex=0. In the usbradio.conf file, duplex=0 is set for this node as well....This node won't ID unless its TX is already keyed when it is time to ID. But, the asterisk screen indicates that it IS IDing properly--it shows: "Playing 'xxxxx' (language 'en').......It just doesn't key the 10m TX.
Note that this node is fully functional, otherwise. And, I'm using app_rpt.c version 0.201 from svn. Oh, and I'm using an idrecording ulaw audio file config'ed for the node in rpt.conf. Any ideas?
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
Does its behaviour change when you use duplex=1? duplex=0 turns off ALL telemetry including voice ID;s. Also curious why you want to use duplex=0 and not duplex=1. Steve WA6ZFT
On Thu, 24 Sep 2009, Stephen Rodgers wrote: <snip>
Does its behaviour change when you use duplex=1? duplex=0 turns off ALL telemetry including voice ID;s.
Also curious why you want to use duplex=0 and not duplex=1.
Steve WA6ZFT
Oops!! I originally had set duplex=0 because I couldn't seem to disable the linked courtesy tone or unlinked hang time....That is, immediately after a signal in received and then COS drops, the TX instantly keys up with the telemetry... I have now set duplex=1 and the CD ID issue seems resolved. But, I can't leave it this way with the remaining telemetry active--it'll certainly cause undesired interference on 10m when the node is unlinked and not in use and the band is open.....Note that with duplex=0 everything is perfect; except for the lack of the required ID. Ideas? 73, David kb4fxc
David McGough wrote:
On Thu, 24 Sep 2009, Stephen Rodgers wrote:
<snip>
Does its behaviour change when you use duplex=1? duplex=0 turns off ALL telemetry including voice ID;s.
Also curious why you want to use duplex=0 and not duplex=1.
Steve WA6ZFT
Oops!! I originally had set duplex=0 because I couldn't seem to disable the linked courtesy tone or unlinked hang time....That is, immediately after a signal in received and then COS drops, the TX instantly keys up with the telemetry...
I have now set duplex=1 and the CD ID issue seems resolved. But, I can't leave it this way with the remaining telemetry active--it'll certainly cause undesired interference on 10m when the node is unlinked and not in use and the band is open.....Note that with duplex=0 everything is perfect; except for the lack of the required ID.
Ideas?
73, David kb4fxc
Search for up nounkeyct= on http://app-rpt.qrvc.com Steve WA6ZFT
On Thu, 24 Sep 2009, Stephen Rodgers wrote: <snip>
Search for up nounkeyct= on http://app-rpt.qrvc.com
Steve WA6ZFT
BINGO!!! PERFECT!!! Thank you! ....BTW, the 10M FM radio is an old GE Rangr running 100W from an antenna up about 80ft. It has been fantastic during some of the sporadic-E openings this summer....A 6m 100W Rangr will be available shortly, too. 73, David kb4fxc
thats cool.. the GE RANGR is a most amazing radio!
Date: Fri, 25 Sep 2009 01:20:02 -0400 From: kb4fxc@inttek.net To: sales@qrvc.com CC: app_rpt-users@qrvc.com Subject: Re: [App_rpt-users] CW ID issues
On Thu, 24 Sep 2009, Stephen Rodgers wrote:
<snip>
Search for up nounkeyct= on http://app-rpt.qrvc.com
Steve WA6ZFT
BINGO!!! PERFECT!!!
Thank you! ....BTW, the 10M FM radio is an old GE Rangr running 100W from an antenna up about 80ft. It has been fantastic during some of the sporadic-E openings this summer....A 6m 100W Rangr will be available shortly, too.
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
Hummm...Well, I thought my 10m simplex FM node problem was resolved. But, setting nounkeyct=1 stopped the IDer proper operation, too. In fact, I don't even see the Playing 'xxxx' messages for the node on the console....To verify for certain, I removed the nounkeyct statement and left duplex=1. The IDer again works fine. But, the other undesired telemetry is back too, of course. 73, David kb4fxc On Fri, 25 Sep 2009, David McGough wrote:
On Thu, 24 Sep 2009, Stephen Rodgers wrote:
<snip>
Search for up nounkeyct= on http://app-rpt.qrvc.com
Steve WA6ZFT
BINGO!!! PERFECT!!!
Thank you! ....BTW, the 10M FM radio is an old GE Rangr running 100W from an antenna up about 80ft. It has been fantastic during some of the sporadic-E openings this summer....A 6m 100W Rangr will be available shortly, too.
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
...Okay, here's some additional feedback. I've been monitoring the system for the last hour and a half, and the IDer isn't working any more, at all, for this simplex node. It ID'ed properly about 3 times. This is with duplex=1 and nounkeyct removed from the config. All telemetry is still present on the 10M simplex and it otherwise appears properly functional. Also, note that this same box is controlling a second node--a full duplex 2m repeater. Everything about the 2m side is working great--no problems with the IDer, etc. And, both of these nodes (the 2m & 10m) are linked together. This box also has chan_echolink enabled on it. Thanks for any ideas! 73, David kb4fxc On Fri, 25 Sep 2009, David McGough wrote:
Hummm...Well, I thought my 10m simplex FM node problem was resolved. But, setting nounkeyct=1 stopped the IDer proper operation, too. In fact, I don't even see the Playing 'xxxx' messages for the node on the console....To verify for certain, I removed the nounkeyct statement and left duplex=1. The IDer again works fine. But, the other undesired telemetry is back too, of course.
73, David kb4fxc
On Fri, 25 Sep 2009, David McGough wrote:
On Thu, 24 Sep 2009, Stephen Rodgers wrote:
<snip>
Search for up nounkeyct= on http://app-rpt.qrvc.com
Steve WA6ZFT
BINGO!!! PERFECT!!!
Thank you! ....BTW, the 10M FM radio is an old GE Rangr running 100W from an antenna up about 80ft. It has been fantastic during some of the sporadic-E openings this summer....A 6m 100W Rangr will be available shortly, too.
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
More info....the nounkeyct statement doesn't seem to effect this issue after all. I added nounkeyct=1 back to the stanza and the IDer is now (still) working, so far. So, nounkeyct does work as expected and something else is going on...I'll keep investigating. I guess I should ask if this is the right place for this thread, or, should it be moved to mantis? 73, David kb4fxc On Fri, 25 Sep 2009, David McGough wrote:
...Okay, here's some additional feedback. I've been monitoring the system for the last hour and a half, and the IDer isn't working any more, at all, for this simplex node. It ID'ed properly about 3 times. This is with duplex=1 and nounkeyct removed from the config. All telemetry is still present on the 10M simplex and it otherwise appears properly functional.
Also, note that this same box is controlling a second node--a full duplex 2m repeater. Everything about the 2m side is working great--no problems with the IDer, etc. And, both of these nodes (the 2m & 10m) are linked together. This box also has chan_echolink enabled on it.
Thanks for any ideas!
73, David kb4fxc
David McGough wrote:
More info....the nounkeyct statement doesn't seem to effect this issue after all. I added nounkeyct=1 back to the stanza and the IDer is now (still) working, so far. So, nounkeyct does work as expected and something else is going on...I'll keep investigating.
I guess I should ask if this is the right place for this thread, or, should it be moved to mantis?
73, David kb4fxc
On Fri, 25 Sep 2009, David McGough wrote:
...Okay, here's some additional feedback. I've been monitoring the system for the last hour and a half, and the IDer isn't working any more, at all, for this simplex node. It ID'ed properly about 3 times. This is with duplex=1 and nounkeyct removed from the config. All telemetry is still present on the 10M simplex and it otherwise appears properly functional.
Also, note that this same box is controlling a second node--a full duplex 2m repeater. Everything about the 2m side is working great--no problems with the IDer, etc. And, both of these nodes (the 2m & 10m) are linked together. This box also has chan_echolink enabled on it.
Thanks for any ideas!
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
Asterisk CLI command "rpt stats 2285" is your friend Steve WA6ZFT
Hi Stephen, Yes about rpt stats <node>....The node num is 29--I'm still testing the system before taking this box live. Initially, everything was working great. Now, however, after disconnecting the node, leaving it idle for a while, and reconnecting it, the IDer is dead again. The "Identifier state" remains "CLEAN" no matter what happens. Also, an rpt dump 29 always shows "myrpt->mustid = 0" ....But, the node is otherwise completely functional. The 2m repeater node (currently node #28) on the same box still works properly, though--no IDer problems, etc. I'm still poking around studying the source code-- 73, David kb4fxc On Fri, 25 Sep 2009, Stephen Rodgers wrote:
David McGough wrote:
More info....the nounkeyct statement doesn't seem to effect this issue after all. I added nounkeyct=1 back to the stanza and the IDer is now (still) working, so far. So, nounkeyct does work as expected and something else is going on...I'll keep investigating.
I guess I should ask if this is the right place for this thread, or, should it be moved to mantis?
73, David kb4fxc
On Fri, 25 Sep 2009, David McGough wrote:
...Okay, here's some additional feedback. I've been monitoring the system for the last hour and a half, and the IDer isn't working any more, at all, for this simplex node. It ID'ed properly about 3 times. This is with duplex=1 and nounkeyct removed from the config. All telemetry is still present on the 10M simplex and it otherwise appears properly functional.
Also, note that this same box is controlling a second node--a full duplex 2m repeater. Everything about the 2m side is working great--no problems with the IDer, etc. And, both of these nodes (the 2m & 10m) are linked together. This box also has chan_echolink enabled on it.
Thanks for any ideas!
73, David kb4fxc
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
Asterisk CLI command "rpt stats 2285" is your friend
Steve WA6ZFT
Hi all there, at the moment I operate a dual band NBFM repeater (both bands 2m and 70cm hard linked together) that has a special feature: it passes not only FM, but also APCO25 and D-Star. Of course I do not want to loose this feature, but want to expand its capabilities with an AllStar Link connection. So my approach would be, let the local control unit be in charge for audio path switching (digital voice through the PC probably will not work), the link PC does nothing else but feed the audio into the net and vice versa, and control the PTT when smth. from the link has to be transmitted locally. I assume the configuration options would allow this? Next problem, I am not very experienced with Linux; I am able to use an editor like vi or nano, but manually installing devices and such probably will be very difficult with my limited knowledge. What CD image is the best to go with for a beginner? The hardware will be an mini-ITX board, Intel Core 2 duo with standard 945GM chipset amd the CM108 audio USB interface. It will be a headless system with only a CF card instead of a hard disk, and I still wonder if I will have to buy an CDROM drive for first installation, or if there is some other useful way... What about the future? Passing digital modes over the internet would be an exciting challenge... The Motorola radios I am using work clean enough for local use without regenerating the digital modulation, maybe it will even be possible passing that through the internet?! Seems to depend mainly on the quality of the interfaces, and on the way the stuff is digitized and compressed...and even demodulation and regeneration of the protocols (demodulate and modulate GMSK and 4FSK, regenerate the frames, the checksums) should be an fairly easy task for todays hardware - if there was not the problem that somebody would have to write the software :-) With best regards Ralph, dk5ras http://www.db0fue.de/
participants (7)
-
David McGough -
Eric Tichansky -
James Nessen -
Jim Duuuude -
Ralph A. Schmid, dk5ras -
Ramesh Dhami (VA3UV) -
Stephen Rodgers