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