[aprssig] Weather Station Path/Rate Recommendations

[Robert Bruninga]

>> 30 minutes is too slow for most situations. ...
>> rates of five minutes are desired by many ...
> 
> Sounds obvious to me.  This suggests a Wx 
> station "Smart Beacon" algorithm.  Wx condition 
> change rate handled just like vehicle speed.

That was fundamental to the original APRS!  Here was the
algorithm:
1) Basic WX period was 5 minutes  -but-
2) WX period decayed (doubled) if unchanged (to a max fixed
period)
3) on Change, a packet was sent immediately and rate restored to
5 min.
4) The definition of "change" was a temp change of more than 1.0
degree
   - change in average wind speed more than 3 MPH
   - any change in rain

This required no user settings.  Changing weather was basically
updated every 5 minutes, and decayed to a maximum of 10, 20, or
30 minutes depending on how many HOPS were in the user path.  If
direct or 1 hop, then 10 minutes.  If 2 or 3 hops, then 20 or 30
minutes.  Again, nothing for the user to set, nothing to screw
up, and consistent expectations from all WX stations.

Again, this was the original design of APRS back in the 90's.
Most follow-on clones ignored the decay algorithm in not only
weather packets but ALL packets and took the simplistic constant
packet rates, and gave users control over those fixed rates.
Hence we do not have rapid reporting of rapidly changing weather
and we have some very low rate reports, and as Steve points out,
we don't have any consistancy.

I know this sounds like sour grapes, and it is.  There was
NOTHING using fixed rates in the original APRS concept.  NEW
data always took priority over old un-changing data.  Old data
(unchanging) was refreshed less and less often.  Though it all
did default to a final fixed low rate depending on the length of
the path to maintain the background picture.  These simplistic
fixed rate approaches burden the network with old stagnant data
by a HUGE factor and delay the delivery of fresh data.  This is
disappointing to me...

That is why a keyboard message or updated objects between
APRSdos, XASTIR, APRSscs or APRS-SA and some others is like
lightening compared to some other programs with low fixed rates,
or excessive QRM if set to high rates.  Plus dependence on an
overwhelming variety of user settings that can be screwed up.
These simplistic fixed rate implementations in these other
programs have turned APRS into a slow background or high QRM
system, instead of a FASTER real-time COMMUNICATIONS system
between operators..

Bob, Wb4APR


> 
> No change -> 30 min _or more_
> Rapid change -> 5 min.
> 
> 73, Steve, K9DCI
> 
> 
>       
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>