[aprssig] information of voice repeaters on APRS

[Lynn W. Deffenbaugh (Mr)]

The QRU operator configures objects just as if they would be transmitted 
on a timer, but configures them as Enabled with a zero interval (in 
APRSISCE/32).  The "main" repeater object can be configured with a 
non-zero interval and it will still be used in response to a QRU query 
if configured within the ?RP2M (or whatever) group.

The best place to maintain local information is locally, IMHO. Any 
central location is bound to be out of date shortly after it has been 
created, if it's even correct when first completed.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 4/2/2013 3:18 PM, Andrew P. wrote:
> Ok, so where does the local QRU server get all this information _from_? Is it explicitly configured into the IGate (objects originated by the IGate), or does the IGate discover the data by packet sniffing?
>
> Andrew KA2DDO
> ------Original Message------
> From: Lynn W. Deffenbaugh (Mr)
> To: aprssig at tapr.org
> Sent: Mar 30, 2013 2:08 PM
> Subject: Re: [aprssig] information of voice repeaters on APRS
>
>
> The real idea is that the IGate itself will also be the QRU server and
> will directly serve up the local 2m repeater (and other QRU category)
> objects.  That way it works without the APRS-IS and the object can be
> directly transmitted over RF, but instead of doing it every 10 or 30
> minutes, they're only transmitted on demand.  Of course, the PRIMARY
> local repeater should be transmitted on a timer, but if you want to know
> more, that's where QRU comes in.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> On 3/30/2013 11:01 AM, Andrew P. wrote:
>> The problem with directed queries is knowing who to direct them _to_.
>>
>> Good info about the QRU servers, but it seems like that would that only work for the combination of:
>>
>> 1. The querying station is in range of a bi-directional I-gate (to be able to contact the QRU servers over the APRS-IS backbone);
>>
>> 2. The querying station has already sent out a position report so the collection of QRU servers can decide who is "close enough" to the querying station.
>>
>> On the other hand, since no embedded-APRS radios (Kenwood, Yaesu) seem to have the capability to send non-directed queries, directing a query to the QRU alias might be the only option.
>>
>> Andrew Pavlin, KA2DDO
>> ------Original Message------
>> From: PE1RDW
>> To: aprssig at tapr.org
>> Sent: Mar 30, 2013 10:42 AM
>> Subject: Re: [aprssig] information of voice repeaters on APRS
>>
>>
>> On Sat, 30 Mar 2013 15:29:32 +0100, Andrew P.  <andrewemt at hotmail.com>
>> wrote:
>>
>>> Hmmm....
>>>
>>> That's an interesting idea. APRS already has the generic RF-only queries
>>> ?IGATE and ?WX to find local I-gates and weather stations
>>> (respectively). Maybe we could define a new RF-only generic query ?RPTR
>>> which would cause all stations sending repeater objects to send them
>>> immediately (and thereby let the mobile user know about local repeaters
>>> without waiting for the periodic report).
>>>
>>> Or would this clog the channel from abuse of this query? It doesn't seem
>>> that ?IGATE and ?WX are being too badly abused, but those aren't station
>>> types that a user needs to explicitly know about "right now!".
>>>
>>> Just an idea.
>>>
>>> Andrew Pavlin, KA2DDO
>> a TNC based digipeater night not be able to respond but a DigiNed based
>> digipeater (running on a PI or other small linux dos or windows pc) most
>> definatly can but I am not 100% sure if they can respond to general query
>> or only in directed messages, offcourse being open source and still
>> maintained it can easely be added if needed.
>>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
>
> Sent from my Verizon Wireless BlackBerry
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>