[aprssig] APRS Bulletin/Announcement Format?

[Robert Bruninga]

>>> "Curt, WE7U" <archer at eskimo.com> 05/26/06 10:32 AM >>>
>> Bulletins are supposed to be replaceable and over-writeable.
>> THat means that BLN1 should be REPLACED and OVERWRITTEN
>> by an updates or subsequent BLN1's from the same station.
>
>Xastir _does_ this overwriting based on bulletin/announcement
>number. ...

Thanks Curt!

But I wonder how you display it?  Overwriting and replacing only
makes sense if the "Bulletin DIsplay" is a fixed "window" that
retains all active bulletins, sorts them by call and by line nummber.

THe worst travesty on the bulletin concept is just a chronological 
log of bulletin packets received.  Some software does it that
way, and that makes bulletins just running spam with no
sense of present value, tactical significance nor editability.

THe original concept of BULLETINS and ANNOUNCEMENTS was
just like a wooden Bulletin Board in the EOC where the LATEST
bulletins and announcements were placed, maintained,
edited and constantly updated if they were still valid.  EVERYONE
in APRS saw exactly the SAME bulletin board.

All that was lost when some clones just list bulletins as they 
come in.

Thanks for taking a fresh look at it.
Bob

, not a chronological display that
 I tested that yesterday.  I haven't paid much attention to
bulletins in Xastir up to this point, we read them just fine but
currently have to use the Send Message mechanism to send any out (no
specific Send Bulletin/Send Announcement dialog).


> THe original concept was that any given station would only
> have a certain number of ACTIVE bulletin lines.  And they
> were line-by line replaceable.  Hence the limit to a single
> digit was fine.
>
> I would hope that if you are goint to be hitting the network
> with lots and lots of bulletins, that you also should re-use
> old BLN#'s so that olderones are replaced as new ones
> update old info...

Yes, except there shouldn't be lots and lots of them.  We just need
to keep them separate by state in case 2 or 3 states activate at
once, and need to keep the incidents separate in case we get 2 or 3
activations in one state.


> Would that work in your application?

Yes.  One of our Firenet team came up with the idea of changing the
SSID based on the "incident".  This allows up to 10 bulletin lines
for each incident.  By adding the 2-letter state abbreviation to the
SOURCE callsign it allows up to 16 incidents per state.  By no means
am I expecting to send very many bulletins, but in some cases there
could be more than one incident per state, so this allows us to keep
the bulletins separate from each other and to overwrite earlier
bulletins for each incident with updated information, which is what
I'm after.

So...  This is an example of where we need separation between a few
different incidents (including separation by state so that we can
igate them to RF only in the areas of interest).  It appears to me
that this will function nicely for us if we add the state to the
SOURCE callsign and change the SSID of the SOURCE callsign based on
the incident.  That gives us 10 replaceable bulletins per incident,
and igating to RF based on the state affected.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer 
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"