[aprssig] Why Not "Gate in Vicinity" (phones)

Bob Bruninga bruninga at usna.edu
Mon Dec 26 14:52:15 EST 2011

I think there is a misunderstanding.
> APRS-IS has no concept of "path".  According to
> http://www.aprs-is.net/Connecting.aspx
> Packets originating from the client should only 
> have TCPIP* in the path, nothing more or less 
> (AE5PL-TS>APRS,TCPIP*:my packet).

The PGATEn-N is not in the IS-to-RF packet.  It is a source path from the Phone APP which implements proportional pathing.  The local PGate sees that "PGATEn-N request" and then matches it with it's own settings and path to determine if this is a packet to be gated to RF.  Once that decision is made, on that one packet, then that packet is actually gated to RF following all existing rules.

Just wanted to clarify that.  The other SPAM issues remain.
Bob, Wb4APR

> And I'm really not keen on having a cell-phone APRS
> user configuring something that is driving the RF
> rates/paths out of my IGate. 

He doesnt.  He originates packets with a request.  The PGATEn-N nomenclature lets him designate which packets are 1 minute ones, which are 2 minute ones, and which are 4 minute ones.  That is all they do.

Then it is your IGATE SYSOP who then maps that to his local situation.  If he is IGATING direct (an ideal IGate at a high site) then he can chose to Igate the 1 minute packets like any other loacl mobile.  If he is a valley IGate using one hop, then he only Igates the PGATE1-1 and PGATE2-2 packets that occur only once every 2 minuets.   If his IGATE normally uses a 2 hop path in a rural area, then his PGATE would only pass along the PGATE2-2 packets that only came along once every 4 minutes.

Seems fair.  The Phone mobile is no different than any other HAM mobile using the channel-friendly proportional pathing algorithm.


> cellphone user is likely to be blissfully unaware of
> coverage areas, hops, aloha circles or anything 
> remotely related to those packet/APRS concepts and 
> simply turns on the app and drives cross-country.

As he should.  The app simply is on or off.  If on, it beacons his posit using the above proportional pathing format.  The local IGate that enables PGATING, has the local knowledge to enable it based on the 1 minute, 2 minute or 4 minute copies tht it sees.

> IMHO, whatever resolves from this discussion, 
> if anything, will be unreliable at best if it 
> relies on anything done within the APRS-IS
> client. 

I think we should be ablee to come up with rules and defaults that could make this work.

> In other words, we can't rely on client-side 
> anything to make this work.

With all the new code being writen, I think we can.  If we just agree on the limits...

Bob, Wb4APR

>Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>On 12/26/2011 1:24 PM, Bob Bruninga wrote:
>> Again, not having read all the discussions..  Here is my knee jerk idea for how to get Ham smart phones seen on local RF LOCALLY.
>> Can the APP be required to inject packets using the Proportional Pathing Algorithm.  That is:
>> Packets once a minute.  But every other packet is DIRECT with no path.  And every other one with a path is one hop, and everyother one of those is 2 hops.  This is what we call Proportioanl Pathing and is what I got Kenwood and Yaesu to implement.
>> It allows for 1 minute rate for those that are close.  And 4 minute rate in the area.
>> IGates could implement an algorighm to only pass to RF, those packets that meet my previously mentioned rates based on the IGATES own RF path.
>> So the Proportional PATHING is set at the source (the phone APP)  but the IGate then implements it based on ITS path setting. (see below quoted message).  Now to make this tighter, we might have these paths for the Phone APPS:
>> VIA PGATE0-0  (a simplex packet)
>> VIA PGATE1-1  (a 1 hop packet)
>> VIA PGATE2-2  (a 2 hop packet)
>> These new Igates would only pass PGATE0-0 packets if their IS-to-RF Igate path was direct.
>> These new Igates would only pass PGATE1-1 packets if their IS-to-RF Igate path was 1 hop or less.
>> These new IGates would only pass PGATE2-2 if their iagte-to-RF Igate path was 2 hops.
>> Ayother PGATES would be ignored.  Oh, and of course, ALL OF THIS ASSUMES that the phone APP is within local RF mileage range! (as best determined by the IGate owner).
>> Pete can probably tell us what is wrong with this idea...
>> Bob, WB4APR
>> ---- Original message ----
>>> Date: Mon, 26 Dec 2011 13:03:30 -0500 (EST)
>>> From: aprssig-bounces at tapr.org (on behalf of "Bob Bruninga "<bruninga at usna.edu>)
>>> Subject: Re: [aprssig] Why Not "Gate in Vicinity" (phones)
>>> To: "TAPR APRS Mailing List"<aprssig at tapr.org>
>>> OK, I tuned in late.
>>> Now I see the issue.  Ignore my other general rants...
>>> A smart-phone AP in use by a ham should be seen on local RF in my opinion.  So to answer the question of how-often, I'd propose this rule:
>>> If the IGATE-to-RF path is SIMPLEX Direct (no hops) then I agree with Pete that 1 per minute would be fine.
>>> If the IGATE-to-RF path is one hop (the preferred optimum use of an IGate), then I'd say once every 2 minutes is appropriate.
>>> But if the IGate is set for 2 hops or more, then I would suggest a 4 minute max rate.
>>> Of course, the AP should be in use by a valid Ham Radio operator only.
>>> Bob, Wb4APR
>>> _______________________________________________
>>> 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
>aprssig mailing list
>aprssig at tapr.org

More information about the aprssig mailing list