WA8LMF Mirror of WB4APR Website - 21 July 2008
AVRS
Automatic Voice Relay System
Bob Bruninga, WB4APR
AVRS is the perfect marriage of APRS with any of the VoIP ham radio link Programs (IRLP, ECHOlink, etc)! . Think of AVRS as Ham Radio's Cellular-by-Callsign system. It works just like cellphones, but you use your FM radio as your access, and you use CALLSIGNS instead of phone numbers to place the call.
In the year 2000 or so, we introduced this AVRS concept of marrying APRS and VOIP ham radio systems so that end-to-end mobile-to-mobile voice is possible with automatic set-up based only on callsign! There were three long term objectives to reach this goal.
NODE OBJECTS: . As of 2007, we have made substantial progress. . Many Echolink and IRLP nodes now appear on the APRS maps and more importantly the displays of nearby mobiles as shown to the right on the D7 HT. THese photos need to be taken again, since they are not showing the Frequency of the node which is also very important. The proper formatting of these objects is shown in the APRS Frequency Spec.
QSY Transceivers: . Also in 2007, Kenwood gave us the TM-D710 APRS radio that can QSY to a frequency listed on APRS with the push of a single TUNE button as shown to the right. Not only can the radio tune to IRLP/Echolink Frequency objects, they can also tune to any other operator that has his frequency in his position text and they can also tune to the local voice repeater frequency as recommended by the APRS network. Please see the Local Frequency Object concept that we have been pushing for a few years now. . A few examples are shown on the radio to the right.
The only thing still missing from this Ham Radio AVRS Cellular-by-call system is a motivated individual to write the AVRS engine software.
AVRS will allow any APRS mobile to establish a voice link to any other APRS station anywhere on the planet by simply sending an APRS message with the other station's callsign. This is accomplished via the global APRS, IRLP and ECHOlink systems with only the addition of a single AVRS engine on the Internet. This engine will operate stand-alone similar to how the WU2Z Email engine in NJ handles APRS Email. But instead of handing Emails, the AVRS engine handles the logistics look-up and messaging needed to initiate a Voice call between two APRS voice operators with no other knowledge than the callsign of the CALLEE.
Global Autopatch: Of course it is easy to extend this using VOIP interfaces to a global APRS Autopatch system. Instead of listing a callsign in the AVRS message, the sender enters a PHONE NUMBER. The AVRS engine looks at its list of local auto-patch nodes that have the matching phone number area code and sets up the call.
The AVRS Engine:
As seen below, the AVRS engine just interacts with the APRS-Internet system and monitors the status of all IRLP and ECHOlink nodes. Being fully aware of everything needed for end users to find each other, calls, locations, frequencies, PL's and status, the AVRS engine's job is to pass the needed information and messages to the users to help establish the call:
SCENARIO FROM MOBILE TO ANOTHER MOBILE or EchoLink or IRLP NODE:
MOBILE PLACING A CALL: To place a call, a mobile simply sends a message
to AVRS and the first word of the message is the callsign of the
desired contact (the CALLEE). He needs no other knowldege.
AVRS will ack his message via the nearest IGate and will respond with an object
showing him his nearest ECHOlink or IRLP node, its frequency and PL.
And then a message giving the QSY frequency or other status of the call.
RECEIVING A CALL: If the CALLEE is an APRS station on the air
(has been heard recently on APRS),
The CALLEE will receive the message from AVRS saying QSY FFF.FFF Tnnn E123456
for CALLER using #1234. In this case, CALLER is the caller's callsign,
Tnnn is the CTCSS tone, E123456 is the Echolink or IRLP node and #1234 is the
DTMF access code.
All of this information was determined by the AVRS engine looking up the position
of the CALLEE station and the nearest not-busy IRLP or ECHOlink node.
. If the CALLEE is an EchoLink or IRLP station
then it could be automatically connected to the CALLER's
nearby EchoLink or IRLP repeater if IDLE.
If the CALLEE is an APRS station but has not been heard recently, AVRS still sends him an
APRS message saying "Call from XXXXX on E123456 at 1237z.
This is so that if he doesnt get this message until a while later
the callee can initiate the ECHOlink or IRLP call back to node #nnnnn.
User Terminals: .
All messaging for the AVRS system can be initiated and received by any APRS system, but
most importantly, they can be accomplished from the keypad and display of the D7 and D700
APRS radios. Thus giving true global voice capability to dynamic in-the-field users:
FUNCTIONS OF THE AVRS ENGINE: The AVRS engine can be anywhere and is simply
software running on a reliable internet system. It monitors not only all traffic on
the APRS-IS, but also the active node status of both the IRLP and ECHOlink systems.
As such, it is all knowing and all seeing. The following is a description of this process.
For simplicity the term "AVRS node" will be used interchangeably to refer to "IRLP or
ECHOlink or other VOIP nodes". Here are the functions of the AVRS-Engine.
IF CALLEE IS APRS BUT NOT ACTIVE, THEN:
IF CALLEE IS APRS AND ACTIVE, THEN:
IMPLEMENTING AVRS:
AVRS can be implemented by a single software engineer willing to invest the time
in the project.
Small changes to the IRLP and ECHOlink systems might facilitate operations,
but most everything
needed for this global AVRS ham radio QSO system is in place.
Here are several things that can speed the implementation:
INITIATING A CALL:
Caller simply sends a message to AVRS using one of these formats:
MESSAGES to CALLEE: the following messages are delivered to the Callee, depending on whether
he has been heard recently or not. They are shown in the format that would be flashed on the D7
or D700 radio's front panel for dorect viewing by the driver:
This would take compatible code between the EchoLink, IRLP and AVRS systems...
In this scenario, the CALLER is an on-line EchoLink user and he attempts to connect
to a callsign using his EchoLink client. If the CALLEE is another EchoLink station
the connection is made (but an APRS message is generated via APRS to the CALLEE saying
"Station XYZ is calling you on EchoLink"...) This is in case the actual CALLEE is
mobile with APRS but has an RF link from his car to his Home EchoLink station. This
is just a reminbder for him to QSY and talk voice via that system.
If the CALLEE is only on APRS, then the CALLEE side of SCENARIO #1 is followed on
his side of the call. That is, he gets an object and a message informing him of
where the nearest IRLP or EchoLink node is, what its frequency and PL are and
who is calling him... He can QSY and take the call or not... etc...
Bottom line is that we have RF local connectivity via APRS, IRLP and EchoLink
and we have Global connectivity via all three systems (and more). All AVRS is
doing is focusing our efforts to develop a simple global connectivity between
end users using HAM radio while knowning only callsigns. Its only a little software....
de WB4APR, Bob
The remainder of this page are the older ideas on AVRS that have been around since DCC in 2000
HISTORY: The AVRS concept of a Voice interface for APRS was first publshed at the DCC
2000 in Orlando, (see old paper). It went through some name
changes to "IPRS", and then VIPRS, but now we are back to AVRS
as the generic term for using APRS to augment the end-user display of data about the voice systems
and to facilitate end-to-end user voice connections using the knowledge of APRS about where everyone is!
You can see my old IPRS ideas around the July 2002 time frame.
Eventually, with AVRS, we should be able to make a call to any HAM radio operator on the planet by
simply entering his call. But to get to that point, we need to evolve through three
areas:
MOBILE DATA DISPLAY:
The following two images suggest how IRLP or ECHOlink node status should appear from
their APRS object reports on 144.39 (USA) everytime the NODE changes state. This packet
alerts APRS mobiles in the area on the front panel of their radios the status of the node.
These examples used my original concept that all Echolink and
IRLP nodes should have an 8 character geographical name to fit nicely in APRS:
Simply clicking on the node on the radio display will yield additional information
about the link, without even having to QSY to tune it in! That is just Phase 1.
The additional things we can do with APRS for these voice systems are:
Here is the old original AVRS Specification. I need
to update it to the new centralized AVRS concept.
INTERIM PLAN: The above screens assume that we can convince the entire
IRLP and ECHOlink community to define 8 character ALPHABETIC names to all nodes. This
will take a long time. In the interim, we just want to see the existing nodes on our
APRS displays while mobile. In this case, we will use the node NUMBERS as shown below:
Future AVRS Concepts:
The remainder of this page continues with the original concepts about where we should be going
with AVRS in the future.. The new plan (above) of the single AVRS engine to coordinate the
connectivity for users falls under the category I called "ASSISTED" mode below. We can do
STATUS and MANUAL modes now. ASSISTED can be done easily, and FULL-AUTO can be implemented
by someone smart enough to write a PIC processor to implement it in their mobile or by
Kenwood with a new radio.
AVRS is attempting to define how we can use our HAM radio mobiles and HT's like CELL-Phones.
Sinec 10,000 or so of us have the Kenwoods, the Human/Data Interface of the D7 HT and D700 Mobile
APRS rigs and their (Tiny-Web-Pages) are a good target design objective. Even in 2002, we were
predicting growth rates of over hundreds of Voice nodes per month to exceed 999 in the IRLP system
alone by Feb 2003
(See PLOT!).
Or see the Active-Node-List.
AVRS is only a human interface adjunct to existing Voice-Link systems and
does not obsolete existing users or control systems.
(See the plan back in DEC 2001)
In the context of "AVRS", of course, it would be nice to have a non-conflicting numbering system to work across
all systems. To date we could use these as the APRS distinction:
For additional closeups of the front panel showing the types of data that can be displayed on
these "tiny-web-pages" go to my
TINY-WEB-PAGE satellite tracking page
that shows how they are used to dessiminate satellite tracking info LIVE to mobile users.
Now imagine that these lists can also contain IRLP data, and the built-in end-to-end
APRS data exchange can be used to automatically establish end-to-end voice links.
AVRS SIGNALLING ADVANTAGE: Without AVRS, mobiles will find it impossible to fathom all the
potential across the multiple VOIP systems and their unique numbering systems.
Fixed or internet-available NODE-LISTS will simply not work. Such lists are instantly
obsolete the minute they are downloaded. The only way to make this work is to have
them self-identify on APRS to all mobiles in view. This is the new AVRS concept.
Using this LIVE IRLP and ECHOlink node status into APRS then the AVRS engine's FUNCTION is
to be the central clearing house for finding the status and location of the other end of
a desired AVRS QSO. In otherwords, we are not trying to get into the other systems
and muck with their designs. but AVRS will offer a single clearing house for finding
the nearest available system for making cross-system calls.. between end users.
No hardware is needed to add this tremendous capability to any VOICE-IP system, since they
can simply feed their APRS objects into the APRS internet system. Then the local IGate
puts the local IRLP and ECHOlink nodes into its pass-to-RF list.
Note: Back in 2002 I was pushing IRLP and ECHOlink authors to assign 8-character
geographic node names to all nodes that support more than one end user (Repeaters). This was
to make this data fit the existing callsign fields in all APRS data applications.
So I went ahead and edited up a list. (Download here)
Also, for more details, see the OLD original DRAFT AVRS PAPER HERE .
And I was sure that sooner or later they were going to need a new numbering plan:
Besides the signalling defined in the paper above, here were some other concepts that
should be applied to the use of these systems in your area to the end user mobile:
This javAPRS page below displays the 2002 APRS-OVERLAY file of IRLP nodes provided by
James Ewen. Ignore the red lines, they connect repeaters with identical frequencies(LABELS)
and are an artifact of APRS vehicle tracking trying to "track moving objects"...
But no reason why (with a little software) they couldnt show LIVE which repeaters are
linked...
Click for 2002 World Map
Click here to download the 2002 IRLP.POS file
Here are some initial ideas that can be implemented by APRS users to begin recognizing
IPRS nodes and concepts.
These can be implemented now on APRS independent of progress on the IPRS side...
HOW TO PUT YOUR IRLP or ECHOlink NODE ON THE APRS MAP:
Simply put your IRLP node as an APRS OBJECT into one of the LText buffers of your local APRS
digipeater and set its LTPath to direct and set its rate to 10 minutes. Bingo, every
mobile in the area will see it on the front panel of his radio! Here are the formats of
the TNC commands for use at the DIGI site:
In the above the IRLP##### will be the name of the object and the
LAT/LONG must be the exact number of digits, but you can replace
the hundredths of minutes with TWO spaces which will give a position ambiguity of
one mile if you want to protect the exact location of the repeater. The CCCCCC is the
callsign of the repeater, ##### is the IRLP node number, and then the frequency and
tone of the repeater
IPRS SHARED VOICE/DATA CONCEPTS!
The following concept was the original concept for having each VOIP site send
its own data via its own TNC and radio. This was probably impractical becauwse
it required more hardware at the site. But under that situation, it would be
possible to send both
voice and DATA on the same channel so that all of AVRS can be done entirely on
BAND A of the Kenwood D7 and D700 leaving the other band free for all other
mobile ham radio applications. Also, with a combined voice/data channel/ single
channel radios can be used by other experimenters to build compatible systems.
Here is how you could setup your Kenwood:
WOW. We can really do some neat things here!
Remember, we are not trying to re-invent APRS, and
we are not trying to muckup existing IRLP or ECHOlink operating procedures. We are
simply exploring ways to overlay ideas to allow a marriage of
mobile data exchange capabilities built into the Kenwoods, HAMHUDS. MIM's
(and anything else someone wants to cobble up) to facilite long distance
voice/data communications between end users via the internet...
de WB4APR@amsat.org, Bob
You are visitor:
since 4 Dec 2001.
It was 1330 on 30 July 2002 when I changed the name to IPRS.
.
SCENARIO #2, ANY ECHOLINK USER ON LINE TO ANY APRS MOBILE:
Click to see IRLP APRS status
Click to see ECHOlink APRS status (not as many)
zooms up/down (you may also use PGup/dn)
List stations, Show Status or Messages to Java console
Centers or Zooms map on clicked location
scrolls map
WA8LMF Mirror of WB4APR Website - 21 July 2008