WA8LMF Mirror of WB4APR Website - 21 July 2008 AVRS

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.

  • Make Echolink and IRLP objects show up on APRS maps
  • Make these objects show their operating frequency and node numbers
  • Have mobile radios that can easily QSY to these frequencies
  • Have an AVRS engine running somewhere on the APRS system to act as the "connection messenger".

    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.

  • Monitors the APRS-IS and accepts APRS CALLER messages from mobiles
  • Compares location of CALLER to nearest IRLP or ECHOlink node
  • Generates OBJECT to CALLER's Igate showing nearest AVRS node, its Freq and Status using decaying algorithm
  • If nearest is BUSY, then also sends back additional next-closest available AVRS node using decaying algorithm
  • Compares location of CALLEE to nearest IRLP or ECHOlink site
  • If CALLEE is an IRLP or ECHOlink node itself, it could set up the link automatically via the IRLP or EchoLink system
  • If CALLEE is an APRS station, it Generates OBJECT to CALLEE IGate showing his nearest AVRS node and frequency
  • If nearest is BUSY, then also sends additional next-closest available AVRS node object
  • Checks availability of CALLEE stations. Chooses best SSID (Mobile, else portable, else home.

    IF CALLEE IS APRS BUT NOT ACTIVE, THEN:

  • Sends message to CALLER saying "CALLEE heard XX hours ago near AVRS node #xxxxx"
  • Sends message to CALLEE saying "CALLER called from AVRS node #xxxx at time TTTT.

    IF CALLEE IS APRS AND ACTIVE, THEN:

  • Sends message to CALLEE saying "QSO CALLER on FREQUENCY ffffff, PL ppp calling from #nnnnnn"
  • Sends message to CALLER saying "Call CALLEE on AVRS node #xxxxx PL ppp"

  • "Nearest node" is determined by a combination of node distance (D) and PHG range (R). The node with the highest ratio of R/D will be chosen. Also, the AVRS engine has to decide on IRLP or ECHOlink or other system based on what is available at both ends (including distances at both ends). (I have not detailed how this choice is made. More thought needed here)...

    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:

  • Implement a consistent format for the real-time status of IRLP and Echolink nodes in their APRS position packets
  • Design AVRS object's status to show up well on the 20 text bytes of the D7 and D700 two 10 byte lines
  • Design AVRS messages to show up well on the D7 and D700 message screens, 45 characters (12+12+12+9)
  • Have all IGates automatically PASS-THRU to RF any traffic originated from their OWN callsign.

    INITIATING A CALL:

    Caller simply sends a message to AVRS using one of these formats:

  • C CALLEE - Initiates the full call process
  • ? CALLEE - Generates all messages & objects except messages to CALLEE (this is for info and test)
  • ? . . . . . . . . - Returns nearest local AVRS nodes

    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:


    SCENARIO #2, ANY ECHOLINK USER ON LINE TO ANY APRS MOBILE:

    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:

  • Display of the NODE status in the mobile . . . . . . . . . . . . . . . . . . . . <== this is now being done in most areas>
  • Node NAMING that does not require memorizing node numbers . . <== never took off...>
  • Radios that facilitate these features . . . . . . . . . . . . . . . . . . . . . . . . .<== future..>

    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.

  • STATUS: All nodes send out their STATUS on APRS when they change state
  • MANUAL: Send an APRS message to the other fellow saying CQ and your IRLP node#. He calls you!
  • ASSISTED: IPRS locates nearest nodes to both and sends APRS message to both end users.
  • FULL AUTO: PIC processor on radio sees QSY message and automatically tunes radio to IRLP node at both ends!

    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:

  • I##### (for IRLP)
  • L##### (for I-Link)
  • E##### (for Echo-Link)
  • Q##### (for eQSO)

    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.

  • MORE and SHORTER RANGEs: As popularity continues to grow these VOIP nodes will NOT be on big repeaters but will gravitate to smaller and smaller nodes with limited local coverage. Individuals will put them up to cover their local commute only... This is just like cellular. Growth simply means smaller cells. This makes more frequencies available.

  • ACTIVITY STATUS: We want these AVRS nodes to idenfity their status LIVE on the APRS-IS. This is the only way to have cross-platform consistency so that AVRS routing processes have a single point of access to the instantaneous status of each node no matter what its affiliation. To see the status of the "AVRS" system, just look (for now) on APRS-IS... These two links use FINDU's SYMBOL.CGI to find them by their symbol:
    Click to see IRLP APRS status
    Click to see ECHOlink APRS status (not as many)

    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:

  • PERSONAL STATIONS: All stations serving only one user by callsign should chose a node number which is simply the Touch-Tone hash equivalent of his CALL.
  • REPEATERS: Similarly the Repeater stations should adhere to a geogrpaphically logical 5 Digit Numbering Plan that includes Country Codes. That idea didn't catch on. The next best idea was to use the T-Tone hash code equivalent for the geographical node name. See the original AVRS SPEC noted above.

    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:

  • AVRS end users can exchange APRS messages prior to, during or after a QSO.
  • STATION list can show up to 40 users on line in the normal format.
  • STATION list can show current ACTIVE NODE STATUS web page for most recently used nodes
  • STATION LIST can also include bearing and range to each Voice node. (see FORMAT)
  • APRS messages can help establish the VOICE link between any 2 users worldwide via the AVRS engine
  • APRS Messages can Query worldwide for Station X's currently nearest node (see FORMAT)
  • Single press PM button can configure D700 totally for AVRS operations
  • Front panel command can eventually set-up AVRS link directly from station list using the AVRS engine

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


    javAPRS Commands (Case Insensitive)
    U or D
    zooms up/down (you may also use PGup/dn)
    L, S, or M
    List stations, Show Status or Messages to Java console
    CTRL or ALT-click
    Centers or Zooms map on clicked location
    Arrow keys
    scrolls map

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

  • All IRLP/I-LINK/ECHOlink users should put "IPRS" or "ECHO" in their MESSAGE GROUPS
  • All IGates or IPRS gates should put "IPRS" or "ECHO" in their pass-to-rf-always list
  • The APRS Icon for IPRS nodes is "I0" and for ECHOlink is "E0" (thats a zero)
  • The APRS TOCALL for any special AVRS software is "APVxxx" for "Voice"
  • Mobiles use "Innnnn" or "Ennnnn" in their status to show their current node.
  • The above IRLP data base should be added to all APRSdata servers for Queries
  • The term "AVRS" will distinguish this generic concept from specific IRLP or ECHOlink implementations

    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:

  • LT 2 ;IRLP#####*111111z!DDMM.hhNIDDDMM.hhW0CCCCCC 44X.XXX PL YYY
  • LTP 2 APRS
  • BLT 2 E 00:10:00

    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:

  • Kenwood radio sets Band A to the IRLP VOICE channel. He configures his interntal TNC to BAND-A and sets CTCSS decode ON. THis way, Band A can serve as BOTH an IRLP data exchange channel with the radio front panel and also as the VOICE channel! The speaker is muted for all data, and only opens when the IRLP node sends CTCSS and voice.

  • The user can now fully use BAND-B for any other purpose and Band A handles both IRLP voice operations and APRS data exchange with the node..

  • At the IRLP node site, the TNC listening and sending acts like an APRS "IGATE" in all other respects. Thus the APRS user is injected into the world wide system for tracking and messaging just as if he was on 144.39. He is tracked on all web pages and he can send/receive APRS messages worldwide.

  • The above user, however, cannot see other local APRS activity. Thus the IGate must be smart enough to listen for other "local" activiy on the APRS internet system and forward any packets originating in the vicinity of the IPRS user, back out on the common IRLP channel othe IPRS user. This is actually GOOD news in the sense, that the "smarts" in this IPRS_IGate code can "filter" as the locals decide so that they only have to watch what they want to watch...

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


    WA8LMF Mirror of WB4APR Website - 21 July 2008 there are some Voice Calls that can be placed even now, without the AVRS engine as follows:

    EchoLink-ON-LINE-USER CALLING AN APRS MOBILE: In this scenario the on-line APRS operator is running both an APRS client and can see the EchoLink and IRLP node status on-line so that he can see where the CALLEE mobile is located and since all IRLP and EchoLink nodes are now injecting their STATUS objects into the APRS-IS, (click for IRLP) (click for ECHO) the on-line user can zoom in on the mobile and can see what IRLP or EchoLink node is nearby. Displaying the PHG circle can confirm the reliability of the link. TO call the mobile, the operator sends an APRS message to the mobile operator saying "I am calling you on IRLP or EchoLink node on FFF.FFF MHz with PL of PPP. Pse QSY, tnx". If the mobile gets the message and QSY's, then the call is a success.