[aprssig] DIGI ID rates for UIDIGI's now updated on WEB page

[Rick Green]

On Tue, 9 Nov 2004, Robert Bruninga wrote:

> That will get you a local packet every 10 mins, a WIDE
> every 30,  and a WIDE2-2 every hour on the hour.
> The only problem is that once every hour on the halfhour,
> you wont get one.   But 5 out of 6  ain't bad.  And if you are
  Do you really want to go on record making a reccomendation that is
technically not in compliance with the regs?  Does the FCC use a standard
of '5 out of 6 ain't bad'?
  How many extra packets would be generated by a setting of:
  #1 every 10 minutes starting at 0 DIRECT
  #2 every 31 minutes starting at 31 VIA WIDE
  #3 every 91 minutes starting at 91 VIA WIDE2-2

...the odd numbers  reduce simultaneous transmissions by 90%.  It
satisfies the FCC regs, plus only 4 packets each 90 minutes.

  If you used something like:
  #1 every 18 minutes starting at 0 DIRECT
  #2 every 30 minutes starting at 10 VIA WIDE
  #3 every 90 minutes starting at 90 VIA WIDE2-2

Then you get 9 packets in 90 minutes, so the average interval complies,
but you'll get some intervals as long as 18 minutes...  Which way do you
want to stretch the regs?

  This is all just theory.  For me, I'll use a single 10 minute DIRECT
only ID.  Your argument for a user's knowledge of the network over the
hill applies only to a user of the 'directed message' feature of APRS.
IMHO, APRS is best used for local, situational awareness as it
was originally designed.  Messaging is the feature that broke the camel's
back.  There are other modes, on other frequencies, that are better suited
to point-to-point communication.  If you're going to reprogram your
TNC to use a specific path whenever you want to send a directed
message, is it too much to ask the user to QSY to another frequency
and use a more appropriate mode? Rather than trying to graft an
inappropriate feature onto an otherwise good protocol, we would better
serve the community by educating the users on using the right tool for the
job.
  And yes, the network should work for 'appliance operators'.  Think about
it:  No matter how much experience we have, or knowledge of our local
network, we are all reduced to newbies in an instant when we get into an
actual disaster relief scenario.  Either we've relocated into another
area, or we're working with a quickly built, constantly changing, ad-hoc
network, or both.  We must work to develop protocols for the digi sites to
discover their own place in the network, and develop workable routing
tables.  Only with this kind of intelligence in the digis will we get to
the point where a usable network can be built in a disaster area by simply
dropping black boxes in high locations, and let the users get on with
business without having to take time to learn the local network.

-- 
Rick Green

"They that can give up essential liberty to obtain a little
 temporary safety, deserve neither liberty nor safety."
                                  -Benjamin Franklin