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

[Lynn W. Deffenbaugh (Mr)]

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

This is really, really important as it is probably the one consistent 
indicator that a packet was directly injected into the APRS-IS stream 
and not gated from RF somewhere.

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

IMHO, whatever resolves from this discussion, if anything, will be 
unreliable at best if it relies on anything done within the APRS-IS 
client.  It's almost as easy to fire up UI-View on a cellular data 
connection on a mobile laptop with a GPS as it is to run APRSISCE on 
Windows Mobile, IBCNU on an iPhone, or APRSdroid on an Android phone.  
In other words, we can't rely on client-side anything to make this work.

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
>