<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">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 name="messageReplySection">On Dec 3, 2019, 17:01 -0600, Gregg Wonderly <gregg@wonderly.org>, wrote:<br />
<blockquote type="cite">Yaesu.’s Fusion system provides the ability to send text, audio and photo data to a repeater’s HRI-100 connected computer system. That has power implications, but not much different from bulletins requiring someone to keep sending the for newly connected stations to see.<br />
<br />
I like the fusion solution since it decouples the information fanout from net control. There are pluses and minuses for any solution since they are based on the technology used. As Bob said, even the basic function of bulletins is not consistently implemented.<br />
<br />
Gregg<br />
<br />
Sent from my iPhone<br />
<br />
<blockquote type="cite">On Dec 3, 2019, at 4:06 PM, Robert Bruninga <bruninga@usna.edu> wrote:<br />
<br />
A log of checkins could look like this:<br />
<br />
BLN1STNLOG:@1030<br />
Checkins:ASDFAS,WERR,ERETT,ASDFGG,ZXVCXCZ,ASDFFF,WEQRW,ZXCVVV,SDFDFG,WERTW<br />
ER,WRTRYY<br />
<br />
Each time it changes, update the list and the time. Kepe the same BLN1<br />
and it will overwrite the older copy. Or increment the BLN# and have past<br />
logs in the Bulleting list.<br />
<br />
Bob<br />
<br />
<br />
-----Original Message-----<br />
From: aprssig <aprssig-bounces@lists.tapr.org> On Behalf Of Greg Troxel<br />
Sent: Tuesday, December 3, 2019 3:40 PM<br />
To: Greg D <ko6th.greg@gmail.com><br />
Cc: TAPR APRS Mailing List <aprssig@lists.tapr.org><br />
Subject: Re: [aprssig] Multi control station situational awareness - How's<br />
this supposed to work?<br />
<br />
I would urge you to step back and consider your requirements, think about<br />
the protocol that will be used at a high level, and then figure out how to<br />
use specific techniques to implement that protocol.<br />
<br />
If what you want to do is publish infomration about status of particular<br />
places, then APRS probably is the best fit.<br />
<br />
If you are trying to synchronize the list of checked-in stations among N<br />
NCS stations, then I think you want some sort of database sync protocol<br />
which is going to send messages among the participants, and you may or may<br />
not want to carry that over APRS.<br />
<br />
I think you implied this, but from the "train like you'll fight" I would<br />
suggest using the over-the-air sync all the time, and not use any<br />
direct-to-APRS-IS internet-based injection. Gatewaying to APRS-IS is<br />
great for others to probably be able to see what's up, but I think you<br />
should plan on no internet, and thus operate that way routinely, because<br />
otherwise you are likely to be depending on it more then you think.<br />
<br />
ALl of this is going to push you to protocols that are very terse and push<br />
just the data, with all formatting and UI local. This means writing a<br />
local implementation of the UI for the protocol.<br />
<br />
73 de n1dam<br />
<br />
<br />
<br />
<br />
_______________________________________________<br />
aprssig mailing list<br />
aprssig@lists.tapr.org<br />
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br />
<br />
_______________________________________________<br />
aprssig mailing list<br />
aprssig@lists.tapr.org<br />
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br /></blockquote>
<br />
_______________________________________________<br />
aprssig mailing list<br />
aprssig@lists.tapr.org<br />
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br /></blockquote>
</div>
</body>
</html>