[aprssig] Multi control station situational awareness - Using original Bulletin protocol!

Robert Bruninga bruninga at usna.edu
Wed Apr 1 11:27:41 EDT 2020

To answer some of your questions about APRS Bulletins:

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...

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.

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.

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.

5) What goes into a bulletin is a judgment call, weighing urgency with
latency, and with network load.

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

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:
http://aprs.org/APRS-tactical.html 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.

Hope that helps.

On Wed, Apr 1, 2020 at 12:37 AM Greg D <ko6th.greg at gmail.com> wrote:

> Hi Bob,
> Thanks for taking the time to weigh in.  Much appreciated.
> So, trying to understand first, before reacting...
> 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.
> 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?
> 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.
> 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.
> 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?
> Greg  KO6TH
> Robert Bruninga wrote:
> 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.
> 1) Bulletins are numbered BLNx where X is numeric or alphabetic to
> establish a -sequence- to the lines in the bulletin.
> 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.
> 3) BLNx lines are repeated ad nausium but at a decaying rate.
> 4) Thus every station gets every line and they are always displayed as
> sorted by line number
> 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.
> 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...
> The PROBLEMS with some implementations after APRSdos that undermines the
> beauty of the design I think are some of these:
> 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.
> 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.
> 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.
> Can we at least identify any clients that fully implemented the original
> Bulleting protocol?
> - Kenwood - NOT.  TX's 1 per minute for 5 minutes and stops.  Does not
> sort on receipt.  Does not replace identical line numbers.
> - WinAPRS - Not.  Same as above
> - YAAC - ?
> - APRSIS32 - ?
> - XASTIR - ?
> Curious... Bob
> On Tue, Mar 31, 2020 at 5:37 PM Greg D <ko6th.greg at gmail.com> wrote:
>> Hi Andrew,
>> This is an intriguing idea.  Basically, use the old News service as the
>> back-end database / viewer, and packet radio as the transport.  The
>> difference between this and the PBBS model is that the database is
>> distributed and sync'd among all the nodes (net control stations), vs
>> having a single instance that everyone "dials" into (figuratively or
>> literally).  I like the concept.
>> How would the packet radio part work?  Would you create a plug-in to YAAC
>> to make the connections, or would we need a different client to run in a
>> more traditional connected-mode (vs UI) framework?  Ideally, updates would
>> be real time among the active net control stations, with a sync function
>> when a new station begins their shift.  Is the News service able to run
>> near-realtime without forcing a global sync with every entry?  I don't
>> recall this being part of its normal operation (thinking it was more batch
>> oriented), but it's been a few years (!) since I've used it.
>> Rambling usage thoughts and questions...  (TL;DR - see "Ding", below)
>> Thinking about how it would be used; there's certainly a lot of
>> flexibility...  In the application I originally posted about (wide area
>> service outage support net), how would this work?  I was thinking (and have
>> rejected - see below) to have one thread for status check-ins (power out /
>> on and where), each resource (gas/fuel, stores open or closed, ice in stock
>> or out, equipment / generators, random needs, etc.), miscellaneous notes,
>> ...?  I'm kind of missing the APRS mapping opportunity, even though we
>> didn't have it with our paper logs.  Perhaps the plug-in could somehow
>> create map objects with the information presented?  After all, a live map
>> is one of the primary views into the APRS universe, with the text-based
>> information being the weak link.  APRS messaging has the text, but not the
>> historical information retrieval.  Scattered objects have the information,
>> but no way to search through it.
>> So, I'm starting to talk in circles...  YAAC already has the ability to
>> create messages and objects, so why have a separate user interface (and one
>> without a map)...?
>> *Ding!*  An idea...  Perhaps the News "database" (or probably one message
>> thread therein) would simply be an archive of the APRS traffic (messages
>> and objects) involved in the overall incident, with the unique ability to
>> replay / sync it (LOCALLY!!, not over RF) when a new Net Control station
>> does a sync to begin their shift?  This removes the need for Internet
>> access (and presumes operation on a local simplex frequency), and provides
>> that sync ability that's missing / awkward with APRS-IS.  The remaining
>> (existing) News functionality could be used for conversation traffic
>> archiving among the Net Control operators.  Primary user interface is the
>> standard APRS messaging and object generation that YAAC already provides;
>> the plug-in would add the real-time archiving of the traffic, and sync /
>> local replay functions, using the News service as the database mechanism.
>> Information display would be the existing Station/Object list.  The
>> real-time sync of messages and objects between active Net Control stations
>> is just the normal APRS operation via RF.
>> The one thing that's missing is a simple time-ordered Net Control running
>> log.  My preference would be to have it be auto-generated (station checked
>> in, object created, object updated, etc.) and added to the sync'd News
>> file.  Or, is this already provided in the base YAAC application?  I'm not
>> seeing it...
>> Making all this work on an operational basis will require a number of
>> site / incident-specific usage conventions, e.g. what to name objects
>> (gas-1, gas-2...) and how to make status messages useful (power is out here
>> - where?).  There might be another plug-in or two to make data entry easier
>> for a one-person Net Control station to handle, but let's get the core
>> right first.
>> I'm trying to keep this simple, otherwise it'd just be better to get one
>> of the enterprise-level SAR support products, which is where I don't want
>> to end up.  Remember, we're trying to replace pencil & paper, and need to
>> assume battery operations - HT and laptop or Raspberry Pi - and a candle.
>> Thanks!
>> Greg  KO6TH
>> Andrew Pavlin via aprssig wrote:
>> Hi, Steve.
>> Re-reading your email on this as I got restarted on my own effort in this
>> area reminded me of some other ancient technology that we might want to
>> resuscitate for this problem.
>> Does anybody remember Usenet (otherwise known as the InterNetNews)? It
>> was a powerful means of implementing a distributed world-wide collection of
>> thousands of bulletin boards of discussion threads, back before the World
>> Wide Web, hosting service providers, and (nearly) ubiquitous broadband
>> replaced Usenet with world-accessible single-server web forums and blogs.
>> Like email in those days, Usenet only carried plain-text; like email, it
>> could carry anything that could be bundled into a plain-text email message,
>> such as binary files encoded by the useful uuencode and uudecode programs.
>> It would automatically synchronize all the distributed copies of any given
>> discussion group. And it could work over (by today's standards)
>> ridiculously low-bandwidth links. In 1991, I was running a corporate Usenet
>> news gateway over a leased-line Internet connection at a screaming 19.2
>> kilobaud. Yes, _that_ slow. Yes, we had dialup modems that went faster than
>> that before broadband.
>> These days, the Usenet news server software is still available in most
>> Linux distros (I just checked, and both Fedora Core and Raspian Buster
>> still have it as an optional distro package). Many email clients still
>> support NNTP (Network News Transport Protocol) as well as SMTP (Simple Mail
>> Transport Protocol). And NNTP can transfer over any TCP/IP link (including
>> TCPIP-over-AX.25 and HSMM, as well as the global Internet), and over
>> batched low-level links (it used to use an old package called UUCP
>> [Unix-to-Unix CoPy] to transfer updates over dialup links) at barely more
>> infrastructure than the KISS protocol.
>> So, we could set up NNTP servers on Raspberry Pi computers (or anything
>> else) and use any sorts of links to connect them together: Internet,
>> HamWAN, AREDN, TARPN, heck maybe even fldigi file transfers (not much
>> different than what UUCP did). Because NNTP uses a flood-fill algorithm to
>> distribute messages over multiple paths, if one link goes down, the target
>> at the other end of the failed link will eventually get it via several
>> relays on other links as long as every news server has links to more than
>> one other news server, and the topology doesn't have any Single Points Of
>> Failure. No particular network topology is required; just like amateur
>> radio, Usenet doesn't need a central control office (unlike cellphones). We
>> can certainly get sufficient TCP/IP speeds over AX.25 packet with the
>> 9600-baud TNCs (hardware and software) that are readily available now for a
>> TARPN-style VHF network for areas where we can't do HamWAN/AREDN, but NNTP
>> will still work over those networks as well. And, if we keep our Usenet
>> separate from what's left of the old Internet Usenet, we don't have to
>> worry (as much) about illegal content putting transmitting stations at risk
>> or excessive traffic volume. After all, most public service events that use
>> APRS put their event traffic on a different frequency than the national
>> APRS frequency to avoid congestion.
>> So, if what is needed to solve the problem is a distributed bulletin
>> board, Usenet solved it for us decades ago.
>> Just my $.03 (inflation, ya know).
>> Andrew, KA2DDO
>> author of YAAC ("Yet Another APRS Client")
>> On Wednesday, December 4, 2019, 12:11:44 AM EST, Stephen H. Smith via
>> aprssig <aprssig at lists.tapr.org> <aprssig at lists.tapr.org> wrote:
>> On 12/3/2019 6:26 PM, chiefsfan2 at cox.net wrote:
>> Since you had a analog landline phone still working that would be a
>> reason to bring back some phone patches like we used to have. And now you
>> can run a BBS on a rasp pi computer which makes for great portability and
>> low power consumption
>> Funny you should bring this up at this particular time.  Just last week,
>> I was experimenting connecting an old Heathkit HD-1515 phone patch I found
>> in my junk box to the 6-pin mini-DIN data port of a Yaesu FT-857D.   It
>> worked perfectly both on FM for 2 meters and on SSB for HF.   I'm now going
>> to add a 6-pin mini-DIN jack to the back panel of the patch, in parallel
>> with the existing RCA RX and TX audio jacks.   I can then use a standard
>> off-the-shelf  6-pin DIN to 6-pin DIN cable to connect the patch to any
>> radio with a standard 6-pin data port.   Finally, I will add a double-throw
>> center-off   locking-one-way  /  momentary-the-other-way toggle switch to
>> the front panel to key the radio transmitter.
>> I'm now thinking about getting one of those Bluetooth gizmos that links
>> to a cellphone and and produces a couple of classic RJ-11 analog phone
>> jacks. I could plug the patch into one and a classic desk phone set into
>> the other.  This would allow phone patches either via  a "real" phone line,
>> or via a cellphone connection if needed.
>> Another variation on this theme:  With a sound card interface setup
>> normally as you would use for digimodes on a PC,  start up Skype instead of
>> a soundcard digi-mode app. You can then run "phone patches" from radio
>> users to users on Skype instead of a POTS line.
>> ------------------------------
>> Stephen H. Smith    wa8lmf (at) aol.com
>> Skype:        WA8LMF
>> EchoLink:  Node #  14400  [Think bottom of the 2-meter band]
>> Home Page:          http://wa8lmf.net
>> -----   NEW!    60-Meter APRS!   HF NVIS APRS Igate Now Operating  ------
>>    <http://wa8lmf.ddns.net:14447/> <http://wa8lmf.ddns.net:14447/>
>> Live Off-The-Air APRS Activity Maps
>>    <http://wa8lmf.net/map> <http://wa8lmf.net/map>
>> Long-Range APRS on 30 Meters HF
>>    <http://wa8lmf.net/aprs/HF_APRS_Notes.htm>
>> <http://wa8lmf.net/aprs/HF_APRS_Notes.htm>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>> _______________________________________________
>> aprssig mailing listaprssig at lists.tapr.orghttp://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
> _______________________________________________
> aprssig mailing listaprssig at lists.tapr.orghttp://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200401/03784a88/attachment-0001.html>

More information about the aprssig mailing list