[CTSARA] [GNARC] Projects and Activites: AnIdea and InformalSurvey
Chris- KB1QXR
kb1qxr at arrl.net
Fri Aug 21 20:58:34 EDT 2009
Hi curt,
Sorry for what is about to become a very long email... hope it's somewhat
helpful. This is a much more complete idea of what I have in mind.
Asterisk in a nutshell-
Asterisk is an open-source soft-PBX program for Linux. It's primarily
designed to deal with telephones, and in that capacity it will take any call
from any type of interface (analog, VoIP, digital, etc), do anything
(literally) to it, and spit it out again on any other interface. It's
highly flexible, easily scriptable, and very, very cool. Most of the stuff
that people are just trying now with Google Voice, has been available for
years to anybody running Asterisk.
However Asterisk also does other fun stuff. For example I have my Asterisk
box running a wake up call script to wake me up in the morning. Before it
sends me a wake up call, it turns on all the lights in my apartment using a
wireless X-10 device.
Asterisk has many plugins including plugins to interface it to different
types of lines. app_rpt allows, with compatible hardware, Asterisk to
interface to a repeater controller or replace the controller entirely.
Aside from doing the usual repeater-controller stuff like identification and
PL tone encode/decoding, it also lets RF-side users access some Asterisk
functions, like voice menus.
On the issue of DTMF, I understand about how a controller always listens for
its sequences. There are two ways around this- one is to make the required
prefix so long that nobody would ever dial it. IE, if the arcom requires
"AB73020492" to make it wake up and listen for further DTMF commands, it's
highly unlikely that anything Asterisk does will involve a user typing in
AB73020492 and thus the two are kept apart.
However a more secure way involves unique tones- tones that are universally
unused by the 'other side'. For example, the 16-tone DTMF that I mentioned
earlier. As you know a standard DTMF keypad has 12 keys- 1-9, 0, * and #.
However DTMF also defines 4 other tones- A-D. From what I've seen most
radios have these keys, but phones do not. Asterisk can handle A-D, but due
to lack of A-D on a phone keypad it's almost never used.
So let's say that the Arcom requires a prefix of A7 to 'wake up' and listen
for command codes (this is the default behavior of an Arcom repeater). If
Asterisk NEVER uses an "A" tone, for anything, then you could bang on the
Asterisk tones until you're blue in the face and never bother the Arcom.
And vice versa- if Asterisk is set to either ignore anything following an
"A7" (it can do this), or has its own prefix code (say, B9), then there's
your solution (as far as I read, none of the Arcom programming sequences use
A-D for anything other than passcodes/prefixes).
In short, if every 'function device' requires a prefix code (DTMF sequenced
entered directly before a command) that's unique and isn't repeated in any
commands for any other devices, you can have multiple DTMF-aware devices on
one repeater that will play nicely together. Using ABCD tones in the prefix
code should guarantee that the prefix codes are unique and will never be
replicated.
As for my proposal, it takes two parts.
1. the Link.
This could be done entirely within the Arcom controller, assuming it has a
free port. Establish a simplex frequency (perhaps in the 900MHz or 1.2GHz
band) to be used as a link (this assumes the 3 links are roughly in line,
oterwise a more complex setup may be required). This simplex freq would
have one radio per repeater on it. If the repeater is linked, then any
audio it repeats is also sent to the link radio, the simplex link is keyed
and audio is broadcast to other links. The repeater also listens on the
simplex radio for other traffic, anything coming in keys the repeater and is
rebroadcast for the users to hear.
Using a publicly-known command, the repeater will simply switch off (ignore)
the port the simplex radio is on (Arcom can do this without giving out
passwords). In this mode, repeater audio doesn't key the link radio, and
signals coming on the link don't key the repeater or get repeated. Thus
turning the repeater into a standalone unlinked machine. This would most
likely be a simple 2-3 digit code, with an equally simple code to undo it
and relink.
The result is a shared link, which each repeater can independently
attach/detach from. The advantage is it's cheap and easy to implement (one
new radio and one new antenna per site, no filters need retuning, just a bit
of Arcom programming), the disadvantage is it's range limited (between the
two farthest repeaters). That however can be fixed with more radios and
frequencies to repeat the link frequency.
This of course also requires other repeater operators who think linking is a
good idea.
2. Make the repeater talk.
Using app_rpt, Asterisk, the Arcom's built in DVR, whatever; allow various
functions and services to be accessed by a repeater user using a DTMF
keypad. The repeater's ID announcement (welcome to the w1ee repeater the
time is...) would also contain something like "press *0 for help". If
someone pressed *0, either the Arcom (from its DVR) or Asterisk would play a
recording announcing the repeater and which options are available. A user
would select an option by transmitting its DTMF sequence.
Possible functions include (but are certainly not limited to):
- a recording explaining what the link is about, how to tell local traffic
apart from link traffic, and how to link/unlink. Like an online help file.
(arcom or asterisk can do this).
- a recording giving info about the club, the website address, and how to
join or donate (arcom or asterisk can do this)
- the current weather report, pulled from NOAA or accuweather by RSS and
read in a computer voice (text-to-speech) (asterisk can do this)
- a 'voice newsletter' advising (by a short recording) when and where the
next club meeting is, any new info, etc. Norwalk (GNARC) as I recall does
this to a small degree- I know I've heard on their repeater a recorded
announcement that advises the next club meeting date. It plays
automatically though, no requesting it. (arcom or asterisk can do this, but
asterisk could do it by pulling a wav file from the club website that can be
easily updated, or pulling a text file and reading it in a computer voice).
These functions require no engaging or disengaging, they only activate when
requested. However Asterisk would probably connect straight into the Arcom,
thus whatever port it's on could be turned off using Arcom admin codes.
I have no idea what the 'political' side is like of things... maybe no
other repeater owners would want to link, maybe nobody in SARA wants a
talking repeater, who knows.
hope that helps and sorry for the LONG email...
chris KB1QXR
-----Original Message-----
From: Curt Seaton [mailto:seaton.1 at netzero.net]
Sent: Friday, August 21, 2009 6:18 PM
To: kb1qxr at arrl.net
Subject: Re: [CTSARA] [GNARC] Projects and Activites: AnIdea and
InformalSurvey
Chris, I am glad several of you folks are showing interest and I will
encourage those thoughts, I for one, will need to learn about this
Asterisk thing, I know nothing about it.... As for simply having the
DTMF codes for whatever you wish to use them for you need to keep in mind
the controller (like all computer units) is just a dumb box. So if the
repeater needs a code of 123 to perform some function such as linking or
unlinking or whatever, you must realize that dialing an echolink node of
231234 with cause the controller to "see" the 123 in
the middle of that sequence and then implement that instruction. The
controller is ALWAYS listening and will evaluate any and all sequences to
see if anything meets its preprogrammed numbers of DTMF tones. It is NOT
smart enough to know that there were leading or trailing digits, it only
"sees" a sequence that it recognizes. Due to the speed variability of
'dialing' from operator to operator there is no way to 'lock out'
certain timing sequences or determine if that DTMF sequence is being
used for something else... The controller MUST evaluate ALL DTMF tones
as any of them are considered by the controller as commands to it.....
I hope you understand this... I can do better explaining in person, so
we will hope for next week or whenever we can arrange a discussion
session...
Suggest that all you guys jot down in writing what it is you think you want
to do and write it down in sequence with discussions for each step so we can
evaluate them in a more fuller way. INclude both engaging and dis-engaging
whatever function you wish. Consider two functions simultaneously if
possible, consider what happens if a simple autopatch is made in one of
these modes, that the telephone number dialed won't
cause a false command... Somebody has to do it anyway to fully
understand and evaluate these ideas from a technical viewpoint. Then there
is the 'political' side of this, that some users may not want this feature
even part of the time, some want it quiet and available for use if and when
needed, not for rag-chewing...others want 'company' while commuting, oh
well, guess it is hard to please everyone all the time, eh???
Later
Curt
Chris- KB1QXR wrote:
> Hello again...
>
> Jon- that wouldn't surprise me if they unlinked during rush hour.
> However I suspect it's at least partially because during rush hour
> there will be traffic everywhere, meaning lots of NY area hams bored
> in their cars, meaning lots of radio traffic. Unlinking allows more
> overall RF traffic to be handled, by letting the NYC people talk on
> one machine while the mid-LI people use another (doubling the
'conversation capacity').
> >From what I've seen of the area repeaters (mainly SARA), a traffic
> >overload
> isn't a problem we're likely to have anytime soon. It is however
> worth considering, as other repeaters may have more traffic than SARA.
>
> On compatibility with controllers-
> from what I know (if I recall correctly) SARA uses the Arcom
> controller. I downloaded the programming guide for it, and upon
> cursory investigation it offers a few useful things that should ensure
> compatibility with an Asterisk/app_rpt system.
> First, certain commands (or all commands) can be programmed to require
> a prefix code, an unlock code, or both, which can be combined to
> require 8-10 digits entered correctly to make the Arcom act on
> anything. Using just the prefix code means a simple 2-digit DTMF is
> required to make the arcom act on the following sequence, then
> sensitive commands can be protected additionally by a longer password.
> Some commands (such as link/unlink) can be programmed to not require
> any codes at all, only the prefix or nothing, to allow their use by club
members.
> Public functions can be combined into macros which have 'simple'
> command codes Additionally, the Arcom recognizes all 16 DTMF codes
> (including A-B-C-D) and they can be used in the access/prefix codes,
> making it even more unlikely that users sending app_rpt requests would
> trip up the Arcom- simply make none of the app_rpt commands include
> A-D.
>
> On meeting to discuss this- the 27th at 6-7 works for me...
>
>
> On another note there is a rather important question-- does anybody
> who actually manages the repeater think this idea doesn't suck? I
> know this list goes out to more than just the few of us that have been
> talking about this, I don't know who exactly is in charge of what really
yet...
>
> It's one thing to imagine easily controllable linked repeater networks
> with Asterisk boxes reading weather reports, but if the people in
> charge have no interest in doing it (or letting someone else do it)
> then I/we are just wasting our time...
>
>
> 73s
> Chris KB1QXR
>
>
> -----Original Message-----
> From: Jon Perelstein [mailto:jperelst at yahoo.com]
> Sent: Wednesday, August 19, 2009 6:27 PM
> To: 'ctsara Mailman'
> Subject: Re: [CTSARA] [GNARC] Projects and Activites: AnIdea and
> InformalSurvey
>
> Just to add to what Curt said -- you should be aware that the LIMarc
> repeaters are NOT linked during prime drive time (morning and afternoon).
> They in unlink them during those times to open up more local
> communications during those periods -- the idea being that someone who
> is talking about the traffic in Western Queens will not be of interest
> to someone out in Suffolk County, and vice versa. I don't know if
> it's something that is done manually or if they have their linking
> system programmed to drop the links during those times.
>
> Jon, KB1QBZ
>
> ______________________________________________________________
> CTSARA mailing list
> Home: http://mailman.qth.net/mailman/listinfo/ctsara
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:CTSARA at mailman.qth.net
>
> This list hosted by: http://www.qsl.net Please help support this email
> list: http://www.qsl.net/donate.html
>
> ______________________________________________________________
> CTSARA mailing list
> Home: http://mailman.qth.net/mailman/listinfo/ctsara
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:CTSARA at mailman.qth.net
>
> This list hosted by: http://www.qsl.net Please help support this email
> list: http://www.qsl.net/donate.html
>
>
>
More information about the CTSARA
mailing list