[aprssig] APRS Digipeter Design Questions

[Greg Noneman]

I have a couple comments on some of these recommendations.

On Apr 29, 2005, at 5:50 AM, Robert Bruninga wrote:

>> I've implemented 4 beacons,
>
> Only ONE is needed.  In fact if there are 4 then they
> all have to be indentical, since nothing in APRS can have
> more than ONE position (and position comment) at a time
> and we dont want "cycling" positions reports because the
> constant change FILLS up all position logs...

I wouldn't be so quick to cut this (and beacon texts) down to one.  
Especially if you're using UIDIGI-ROM as a model.  I find the four 
BLT,LT, LTP (plus one for UNPROTO, BEACON and BEACONTEXT) options of 
the KPC-3 to be more flexible than the three options available under 
UIDIGI.  While under normal conditions the initial setup with identical 
LT's may be a little tedious, the three BT's under UIDIGI are the only 
beaconing mechanisms available (no BTEXT like KPC-3).  On my UIDIGI 
installations, this allows one beacon for a local beacon, one beacon 
thru one digi and one status beacon.  When we initially set up the new 
n-N paradigm in Southern California, the four beaconing options of the 
KPC-3 allowed us more flexibility to send bulletins announcing the 
changes.  While this may not be needed very often, they're nice to have 
when you need them.  My vote is to be more like the KPC-3 (the more the 
better).


>> Is there any reason for me to include support for TRACE?
>
> Be very careful with terms.  There used to be TRACE
> and TRACEn-N.  Both are totally different processes.
> "TRACE" is completely obsolete.  "TRACEn-N" using
> the UITRACE paramete is being replaced by SSn-N
> where SS is the state or section abbreviation.

I think the key thing here is that UIFLOOD and UITRACE must be 
supported.  The confusing thing is that in the new paradigm, WIDE is 
typically being used in the UITRACE parameter and "SS" is being used in 
the UIFLOOD parameter.

>> 4.  UIDigi ignores packets that are not UI frames.
>
> Should be sysop configurable.  And even ideally,
> remote configurable.  So it can be "monitored" and
> controlled...

I believe this is configurable in newer versions of UIDIGI (UIOnly 
parameter).  I personally leave it in UI only mode.  Even in the UI 
only mode, UIDIGI does allow connections for sysop control.  Under 
normal APRS operation, processing of UI frames should be sufficient, 
but I could imagine instances where allowing connections might be 
desirable (e.g. hopping through one digi to configure another).


Greg
WB6ZSU