<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><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 31, 2020 at 5:37 PM Greg D <<a href="mailto:ko6th.greg@gmail.com">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 Andrew,<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Rambling usage thoughts and questions...  (TL;DR - see "Ding",
    below)<br>
    <br>
    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.  <br>
    <br>
    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)...?<br>
    <br>
    *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.<br>
    <br>
    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...<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Thanks!<br>
    <br>
    Greg  KO6TH<br>
    <br>
    <br>
    <div>Andrew Pavlin via aprssig wrote:<br>
    </div>
    <blockquote type="cite">
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">Hi,
        Steve.</div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">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.</div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">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.<br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">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.</div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">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.<br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">So, if
        what is needed to solve the problem is a distributed bulletin
        board, Usenet solved it for us decades ago.<br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">Just
        my $.03 (inflation, ya know).</div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">Andrew,
        KA2DDO</div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr">author
        of YAAC ("Yet Another APRS Client")</div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px" dir="ltr"><br>
      </div>
      <div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px">
        <div><br>
        </div>
      </div>
      <div id="gmail-m_-8041449493147476804ydpb9f94d4byahoo_quoted_6237914876">
        <div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
          <div> On Wednesday, December 4, 2019, 12:11:44 AM EST, Stephen
            H. Smith via aprssig <a href="mailto:aprssig@lists.tapr.org" target="_blank"><aprssig@lists.tapr.org></a> wrote: </div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>
            <div id="gmail-m_-8041449493147476804ydpb9f94d4byiv6627603611">
              <div>
                <div id="gmail-m_-8041449493147476804ydpb9f94d4byiv6627603611yqtfd56917">
                  <div>On
                    12/3/2019 6:26 PM, <a shape="rect" href="mailto:chiefsfan2@cox.net" rel="nofollow" target="_blank">chiefsfan2@cox.net</a>
                    wrote:<br clear="none">
                  </div>
                  <blockquote type="cite"> </blockquote>
                </div>
              </div>
              <div>
                <div id="gmail-m_-8041449493147476804ydpb9f94d4byiv6627603611yqtfd00049">
                  <div>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</div>
                </div>
                <p>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.   <br clear="none">
                </p>
                <p>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.</p>
                <p>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.  <br clear="none">
                </p>
                <p><br clear="none">
                </p>
                <hr size="2" width="100%">
                <p>Stephen H. Smith    wa8lmf (at) <a href="http://aol.com" target="_blank">aol.com</a> <br clear="none">
                  Skype:        WA8LMF<br clear="none">
                  EchoLink:  Node #  14400  [Think bottom of the 2-meter
                  band]<br clear="none">
                  Home Page:          <a shape="rect" href="http://wa8lmf.net" rel="nofollow" target="_blank">http://wa8lmf.net</a><br clear="none">
                  <br clear="none">
                  -----   NEW!    60-Meter APRS!   HF NVIS APRS Igate
                  Now Operating  ------<br clear="none">
                     <a shape="rect" href="http://wa8lmf.ddns.net:14447/" rel="nofollow" target="_blank"><http://wa8lmf.ddns.net:14447/></a><br clear="none">
                  <br clear="none">
                  Live Off-The-Air APRS Activity Maps<br clear="none">
                     <a shape="rect" href="http://wa8lmf.net/map" rel="nofollow" target="_blank"><http://wa8lmf.net/map></a><br clear="none">
                  <br clear="none">
                  Long-Range APRS on 30 Meters HF <br clear="none">
                     <a shape="rect" href="http://wa8lmf.net/aprs/HF_APRS_Notes.htm" rel="nofollow" target="_blank"><http://wa8lmf.net/aprs/HF_APRS_Notes.htm></a></p>
                <div id="gmail-m_-8041449493147476804ydpb9f94d4byiv6627603611yqtfd18518">
                  <p><br clear="none">
                  </p>
                  <p><br clear="none">
                  </p>
                    </div>
              </div>
            </div>
            <div id="gmail-m_-8041449493147476804ydpb9f94d4byqtfd79887">_______________________________________________<br clear="none">
              aprssig mailing list<br clear="none">
              <a shape="rect" href="mailto:aprssig@lists.tapr.org" rel="nofollow" target="_blank">aprssig@lists.tapr.org</a><br clear="none">
              <a shape="rect" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="nofollow" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br clear="none">
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
aprssig mailing list
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
</pre>
    </blockquote>
    <br>
  </div>


_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>