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.
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.
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
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.
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.
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!
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!
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!
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
>
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?
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?
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!
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.
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.
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.
>
> 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.
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.
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.
...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
>
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.
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
...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.
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