[aprssig] DIGI ID rates for UIDIGI's now updated on WEB page
bruninga at usna.edu
Tue Nov 9 13:40:40 CST 2004
>> 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....
> 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'?
Yes, I am happy to make that recommendation and defend it
in the court of common sense and spirit of the law.
The purpose of the FCC requirements for ID are so that stations
that may be causing problems or improper operation may be
identified, located and fixed or turned off. There is no question
in my mind that a digi that sends out its *exact* position and status
every 10 minutes 5 out of 6 times per hour 24 hours a day 7
days a week, is in compliance with the spirit of the law of making
it easy to locate and identify and can be easily found if need be.
>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 packets by 90%. It
>satisfies the FCC regs, plus only 4 additional packets each
Yes, that is on average 8.7 packets per hour compared to the
original 5 per hour or a 74% increase..
Rick goes on to say.....
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
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.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety."
aprssig mailing list
aprssig at lists.tapr.org
More information about the aprssig