[aprssig] Multi control station situational awareness - Using original Bulletin protocol!
Robert Bruninga
bruninga at usna.edu
Tue Mar 31 20:05:03 EDT 2020
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200331/27509067/attachment.html>
More information about the aprssig
mailing list