Order Tray | Contact Us | Home | SIG Lists

[aprssig] Automatic Voice RFelay System (AVRS) and ALLSTAR

Robert Bruninga bruninga at usna.edu
Tue Sep 18 02:01:24 UTC 2012


The APRS standard for ALL LOCAL info is every 10 minutes.  That is so
important, it is in the spec.

Remember, LOCAL means "sourced from a DIGI or other high location and
DIRECT ONLY".  This way it is zero added load on the network because it is
only sourced when the channel is clear (as heard at the digi).

I'm not following this thread closely, but if these OBJECTS or status are
being sourced from a ground level IGate or user location, then they have
to go 1 hop through a digi, and they DO have collision potential with
other users.  So maybe 15 minutes woiuld be a compromise if channel
loading in the area is a problem.  But any less often, and they are not
going to be of much use to those who need it.

Bob, WB4APR

-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Lynn W. Deffenbaugh (Mr)
Sent: Monday, September 17, 2012 5:16 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Automatic Voice RFelay System (AVRS) and ALLSTAR

On 9/17/2012 5:07 PM, Andrew P. wrote:
> Whoops! Do you have me mixed up with someone else? ;-)

Yes, and my apology!  I can't keep myself straight let alone who has
authored what...

> What about non-periodic messages at state-change times only? Since both
the Echolink/Allstar/IRLP/??? gateways and the AVRS are up 24x7 and
connected via reliable wired Internet links, they don't need constant
beaconing.

Well, if a node doesn't change state while you happen to be driving
through,  you'd never know it was there.  Periodic beaconing is a good
idea for local situational awareness.   Every 10 minutes maybe, but
IMHO, at least every 30 minutes.  Then local IGates have a chance to
pick it up from the -IS and put it out to RF if desired.

> Also, I note that there are several IRLP and Echolink gateways in my
area that are beaconing anyway (not my doing) and being gated to the
APRS-IS. If they put the additional state that AVRS needs in their
beacons, it would be done (just more difficult for the AVRS server to
filter out of the APRS-IS flood).

Seems like the repeater object from the local information initiative
would be an excellent starting point.  Are your local nodes compliant
with that at least?

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
(Yes, that's in my tag line so I don't forget what it is I do...)


>
> Up to $.03. ;-)
>
> Andrew Pavlin, KA2DDO
> author of YAAC, not of AVRS ;-)
> ------Original Message------
> From: Lynn W. Deffenbaugh (Mr)
> To: aprssig at tapr.org
> Sent: Sep 17, 2012 4:45 PM
> Subject: Re: [aprssig] Automatic Voice RFelay System (AVRS) and ALLSTAR
>
>
> That would be wonderful, but when I offered to periodically update APRS
> objects for EchoLink nodes, I was resoundingly shot down because of the
> increased load on the APRS-IS.
>
> I am considering a QRU-like server for these objects that would probably
> be the best hope.  (http://aprsisce.wikidot.com/doc:qru) As a matter of
> fact, since you've already got all the data in your server, and are
> already fielding APRS messages, you'd be a shoe-in for implementing such
> a thing.  Drop me a line for details if you're interested.  It's really
> straight-forward.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> On 9/17/2012 4:37 PM, Andrew P. wrote:
>> Perhaps a new APRS message could be defined specifically to beacon such
gateways with the relevant parameters (most of which are in the standard
position message anyway). Then we wouldn't need a back-door URL to get the
data; AVRS could just use a type-filtered feed to get all the gateway
beacons (regardless of which net they are on).
>>
>> Just my $.02.
>>
>> Andrew Pavlin, KA2DDO
>> ------Original Message------
>> From: Bill Vodall
>> To: aprssig at tapr.org
>> Sent: Sep 17, 2012 1:49 PM
>> Subject: Re: [aprssig] Automatic Voice RFelay System (AVRS) and ALLSTAR
>>
>>
>>> I.e. I need callsign, node number, lat/lon of node, RF characteristics
>>> (freq/offset/tone), and status (connected, listening, down, etc)
>>> Given that data I can poll it, update a local DB, map the nodes, and
make
>>> AllStar part of the AVRS protocol.
>> Will this info be generally available on the APRS-IS so we can easily
>> bring it to the RF domain without doing Internet magic...   (Yes - I
>> know APRS-IS == Internet but there is a subtle difference...)
>>
>> 73
>> Bill - WA7NWP
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>>
>> Sent from my Verizon Wireless BlackBerry
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
> Sent from my Verizon Wireless BlackBerry
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>


_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig



More information about the aprssig mailing list