[aprssig] IS-to-RF proposal (rev b)

Bob Bruninga bruninga at usna.edu
Thu Dec 29 16:16:06 EST 2011


As I said:

> I certainly do not want to break anything in the APRS-IS.  
> But I am confused as to why this change was made and why 
> all the server code is now vulnerable to the original spec.

So, to move on.... 

Since this limits us from any future expansion of the APRS-IS, I have
revised the proposal to be compliant with this new APRS-IS restriction.  Now
any implementation of the RGATE function will have to be done by new authors
entirely within new RGATE code.

But this is ok, it just places more burden on the RGATE author to filter,
trap or throttle packets  that he might want to inject into his local RF.
It also places responsibility for vigilance on all local users to be aware
of their local RGATE operation and to react to any unwarranted channel load.

We still need to standardize this function so that it does not evolve
willy-nilly... I still want to imply standards on APRS-IS injecting
stations, and mobiles in particular, to use only the existing APRS standard
rates.  And to use the original DECAY algorithm that decays the rate when
not moving.

I'd also like to see standards for implementing the RGATE SETTINGS so that
they can be consistently applied where desired.  

So here is the updated proposal.

http://aprs.org/aprs12/IS-to-RF-b.txt

Bob, Wb4APR







More information about the aprssig mailing list