<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div><div>To answer some of your questions about APRS Bulletins:<br><br></div>1) The original spec limited the total Public Bulletin board to 40 lines (one full screen at a time on the original PC). That limit was arbitrary and does not need to be implemented. But if bulletins get so many and so big, it defeats the purpose of public information...<br><br></div>2) If there are 30 lines of bulletins that have all decayed to the once every 30 minute default rate (so late comers will get a copy) then that is one packet per minute and a very small load on the network while keeping everyone informed.<br><br></div>3) I wonder about your statement: "Or,
are BLN messages not passed beyond an "n" hop range (i.e. not
injected into APRS-IS for possible retransmission elsewhere)?" Bulletins or all APRS traffic in a given local area should only use an N hop suitable to the local area. In most cases that is a hop of ONE. Our local EOC's are by city and county and usually one hop from any EOC can cover its area of interest. Further, APRS was not designed or intended to be re-injected back to RF from the APRS-IS. Though of course it can be done if needed.<br></div><br></div><div>4) I wouild think that reporting of open/closed gas stations and food storew would best be handled with objects rather than text in a bulletin.<br><br></div><div>5) What goes into a bulletin is a judgment call, weighing urgency with latency, and with network load.<br><br></div><div>6) APRS was designed from the gt-go to allow anyone to take over reporting responsibility for any positions and objects. But unfortuately it does not provide for one station taking over another stations bulletins. But that is one advantage of the overall 40 line limit. If an EOC or net op goes off line and his bulletins begin to age, then they can be forced off the bulletim board by another net op uploading enough new info to push the abandoned bulletin off the page. Or the new net control operator can momentarily use the originators call and send overwriting BLNx line numbers to earase the originals. THen take over as net operator with his own new bulletins.<br><br></div><div>7) There are lots of features of the original APRSdos that were left out by many follow-on clients. They are enumerated on this page:<br><a href="http://aprs.org/APRS-tactical.html" target="_blank">http://aprs.org/APRS-tactical.html</a> but please take that page with a grain of salt. It was written in 2008 at the depths of my frustration of APRS only being viewed as a tracking system. And not being used for rapid real-time community on-air information resource.<br><br></div><div>Hope that helps.<br></div><div>Bob<br><br></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 1, 2020 at 12:37 AM Greg D <<a href="mailto:ko6th.greg@gmail.com" target="_blank">ko6th.greg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
Hi Bob,<br>
<br>
Thanks for taking the time to weigh in. Much appreciated.<br>
<br>
So, trying to understand first, before reacting...<br>
<br>
BLN messages can be multi-line, which is great, but I presume it's a
client implementation topic for how many lines, and how long they
might be. I don't know what the limits are of the applications I
use, and need to check this out. Thanks for bringing it up. <br>
<br>
But if I understand their use, an example might be assigning BLN1 to
be the status of gas station outages, BLN2 the availability of ice
(to save refrigerator contents), BLN3 power status by area, BLN4 for
grocery stores open/close, etc. So if there are a half dozen gas
stations being reported on, would that mean a half dozen lines of
BLN1 information that would be repeated every, say 10-30 minutes?
Multiply that by, say, a half dozen bulletin types, with repeats,
and I'm thinking this could get unwieldy rather quickly. Do I have
this right? <br>
<br>
I've been assuming that we'd be using a local simplex channel for
this, in order to not QRM the entire region with our troubles.
Going without a Digi, however, could be problematic depending on
where the NC stations are located, as the terrain here is very
hilly, and there are a lot of shadowed areas. We do not have the
luxury of putting a digi at our club repeater site, at least not at
the current time, so we may be forced to use the 144.390 channel
(which does have a high level Digi support). That means whatever we
come up with must be compatible with that broader scope, including
the Internet IS backbone. How do BLN messages that collide with
other events doing the same thing in other areas get handled? Or,
are BLN messages not passed beyond an "n" hop range (i.e. not
injected into APRS-IS for possible retransmission elsewhere)? I'm
trying to understand how this kept local, yet scale at the same
time.<br>
<br>
As I noted originally, the need is for a shared, but geographically
distributed, Net Control function, and the ability to hand NC duties
off from one operator or operators to another over time. Last year
we had power outages that lasted for several days and covered a wide
area. With it went much of our internet and cell phone service. So
this needs to be able to operate in an RF-only environment, but
where operator equipment isn't available 24x7 (to conserve battery
power). The ability for a new NC to quickly get brought up to speed
when their shift starts is important. That means distributed
storage, and the ability to get it sync'd from the current NC staff,
without waiting for the network update time to get refreshed by the
usual methods, and without a centralized repository. <br>
<br>
I think that all of the normal APRS message types, including perhaps
bulletins, can apply. They're well understood and cover pretty much
all the bases. It's just that we need a way to hold and pass on the
situation map and chronological log from one set of NCSs to the
next, in the absence of the usual infrastructure. Andrew's idea of
using News might provide that foundation, instead of reinventing the
whole thing. Are there any other utilities that provide a similar,
light weight, multi-node data storage and sync function?<br>
<br>
Greg KO6TH<br>
<br>
<br>
<div>Robert Bruninga wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Actually existing APRS can
provide a lot of your
suggested Public Bulletin
functionality as-is depending
on whether Clients properly
implemented the original APRS
spec Bulletin protocol. Here
is how bulletins were SUPPOSED
to work (as in the original
APRSdos). so that everyone got
a maintained copy of any
multi-line bulletin from any
source.<br>
</div>
<br>
</div>
1) Bulletins are numbered BLNx
where X is numeric or alphabetic
to establish a -sequence- to the
lines in the bulletin.<br>
</div>
2) The local EOC (or anyone) could
maintain a multi-line bulletin that
is captured by EVERY APRS station in
real time, or for late comers too.<br>
</div>
3) BLNx lines are repeated ad nausium
but at a decaying rate.<br>
</div>
4) Thus every station gets every line
and they are always displayed as sorted
by line number<br>
</div>
5) The EOC can edit or change a line
(number of beds, number of ambulances,
etc) and it will REPLACE the previous
same-numbered line.<br>
</div>
6) Thus everyone in APRSdom always has the
latest full copy of the multi line bulletin
(worst case every 10 minutes or 30 minutes
depending on the overall timeout plan for
the given situation...<br>
<br>
</div>
The PROBLEMS with some implementations after
APRSdos that undermines the beauty of the
design I think are some of these:<br>
<br>
</div>
a) Many clients did not implement the decaying
algorithm. They transmit at fixed intervals and
then quit. This prevents all lines from being
continuously updated even after a few hours for
new commers on the frequency. The original was
transmitted once, then 15 sec later, then 30 sec
later, then one minute later, then 2 minutes
later, then 5 minutes later and then ten minutes
later and then every 30 minutes forever (though
a 12 hour or 24 hour time out wouild be nice).
Also, a decay to 10 minute or 30 minute cycle
could be set depending on the urgency and
dynamics of the situation.<br>
<br>
</div>
b) Many clients just logged each BLNx line as
received instead of always sorthing the ones from
the same sender always in sequence. This makes
multiline contiguous bulletins worthless.<br>
<br>
</div>
c) Same as b) in that replacement of a new BLNy
should overwrite an old BLNy was not implemented.
Thus to update a bulletin, the entire thing would
have to be sent again. Thus exploding the needed
bandwidth in a dynamic situation. Insatead of the
single refreshed line protocol.<br>
<br>
</div>
Can we at least identify any clients that fully
implemented the original Bulleting protocol?<br>
<br>
</div>
- Kenwood - NOT. TX's 1 per minute for 5 minutes and
stops. Does not sort on receipt. Does not replace
identical line numbers.<br>
</div>
- WinAPRS - Not. Same as above<br>
</div>
- YAAC - ?<br>
</div>
- APRSIS32 - ?<br>
</div>
<div>- XASTIR - ?<br>
</div>
<div><br>
</div>
Curious... Bob<br>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
<br>
</div></div></div></div></div></div></div></div></div></blockquote><br></div>
</blockquote></div></div></div></div>
</div></div>