<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>Hi, Greg.
<div><br></div><div>What I was thinking of was a plug-in extension to YAAC to handle building and persisting the local copy of the distributed database, plus providing table views specific to the various types of local data.</div><div><br></div><div>My idea for transmitting the data would be to use key=value tokens in the free-text comment field of station position or object/item reports to fill in fields in the database. Key= (no value) would delete a particular field from a station or object. Non-specified key=value pairs would be assumed as not changed from a previous transmission defining them. The key strings would be very short (1 to 3 characters) to fit in the max packet length.</div><div><br></div><div>Similar to the TACTICAL text message used by Xastir and YAAC, I propose a text message target of DATABASE, which would specify for a particular APRS symbol the keys and their human readable names. Stations participating in the distributed database would periodically send the text messages so all stations would know the "pretty" names and datatypes (to help in formatting) for each symbol type's supplemental data.</div><div><br></div><div>A text message could be addressed to a transmit-only tracker's callsign-SSID so that supplemental key-value data could be appended to the tracker's position by "smarter" stations, such as capacity and current passenger count of a support vehicle. The trackers (such as a Byonics MT-AIO) wouldn't need to be reconfigured on-the-fly in the field to add this data; a Net Control station receiving a voice report could update their local database and have the information shared by text packet transmission.</div><div><br></div><div>I can write this up more formally as a proposed extension to the APRS protocol specification.</div><div><br></div><div>Andrew, KA2DDO</div><div>author of YAAC</div><br><br>-------- Original message --------<br>From: Greg D <ko6th.greg@gmail.com> <br>Date: 12/3/19 22:26 (GMT-05:00) <br>To: spam8mybrain <spam8mybrain@yahoo.com>, Robert Bruninga <bruninga@usna.edu>, aprssig@lists.tapr.org <br>Subject: Re: [aprssig] Multi control station situational awareness - For
mobiles? or homes without power? <br><br>Hi all,<br><br>Wow, excellent discussion. And, thanks Andrew for your insight into the<br>problem, if not your actual code. Would this be a view of the data from<br>within YAAC, or a separate application?<br><br>To summarize some of the thoughts.... First, a bit of clarification on<br>what I'm envisioning are parameters that the solution should include. <br>The scale, for starters. Right now we're looking at check-ins<br>(contributions) from the field of view of our club's repeater, which<br>covers the outage area our members reside in pretty well. That area is<br>some 40 miles in diameter, or 120-ish square miles. The terrain is the<br>Sierra Nevada foothills, so lots of valleys. Our repeater has battery<br>backup power, good for several weeks, which worked perfectly. At the<br>north end, about 25 miles from the club repeater is a high level Digi,<br>which appears to also have backup power (it was operating continually as<br>far as I could tell). Its coverage is even larger, and can usually be<br>counted on to hit an iGate somewhere, though not all iGates in the area<br>are bi-directional. But because of the terrain, not everyone can hit<br>that Digi with any reliability, and the few fill-in digis are usually<br>not outfitted with backup power (mine isn't). I believe both net<br>control stations can hit it, and there's enough coverage that we could<br>use APRS as a viable transport.<br><br>We discussed the use of mesh netwoks, such as the mentioned TARPN, and<br>AREDN which is similar. These networks don't currently exist in this<br>area, and again with the physical area and terrain, would take some time<br>and money to create. Doubtful that such an undertaking would be<br>supported for the need we have identified. <br><br>Hosting a dial-up node is not going to be good, as I was pretty much<br>alone in having a working land-line phone, and that it was working was a<br>huge surprise to me, as it's gone down (no dial tone) for every<br>unplanned outage over the past about 3 years. Creative idea, however.<br><br>Packet BBS was not an option we had though of. There are (or, were?) a<br>few packet BBS systems in the state, and I think one within earshot of<br>me is still operating. Haven't used it for a while. That certainly<br>could be a way to pass a file around from one control operator to<br>another. But being an informal net, we didn't set up a specific<br>operator schedule. Instead we just let each other know when we came and<br>went; often both were available at the same time. So, the idea of<br>passing a file around would take some coordination, but could be<br>possible. We had thought to use Winlink for this. If nothing else, my<br>TNC is an MFJ-1278T with a huge mail storage card installed. It's<br>mostly wasted technology, as I run the TNC in KISS mode... This is a<br>worthwhile thing to investigate, if we can figure out the RF paths. <br>Thanks for the idea! <br><br>Overall size of the data collected is important to consider. My<br>hand-written notes from the 3 events totaled about 4 pages, single<br>sided. So, this is way more than will fit in an HT, good size for text<br>files, and trivially small for an enterprise-class application (SARtrack).<br><br>The two (current) net control operators included one ham who is about 10<br>crow-flies miles from the other (me), but not on a line-of-sight basis. <br>He has radios and backup power (battery + generator), and was on them<br>for all 3 of the major outages. No internet during the outages. I was<br>the other operator, and my situation is less dire, as I was only out<br>during the first of the three outages. For the other two, I had both<br>power and Internet, and could view the PG&E website for their updates. <br>For the first outage, I was totally offline until power came back. No<br>generator here (nor a desire to have one); I have battery backup power,<br>and can hit the repeater with just my Kenwood D-74 and the main beam<br>antenna. Computers here were not used during the outage, but I have a<br>variety of platforms from the proverbial Raspberry Pi to laptops that<br>are within capacity of the batteries. And in a pinch I could tap into<br>the battery in my EV.<br><br>A question about Objects... How much information can one object<br>contain? I was thinking 1 packet-worth, but apparently that's not<br>true? I think that it would be good for folks to be able to see the<br>objects as they are generated, but as Stephen says, creating one on an<br>HT-sans-PC is not going to happen. Data input from the population at<br>large is expected to be primarily voice through the repeater.<br><br>So, next steps. On the guess that I'd survive the last planned outage,<br>we set up a Google Docs file to use as a test bed to see what sorts of<br>information should be captured and now the baton passing could work<br>between stations. The outage ended up being canceled for our area, so<br>we didn't have a chance to test it in action. We did a little<br>pre-outage postings with it, and it seemed like it would work well. So,<br>that's action along the file-transfer leg of the discussion.<br><br>For the live RF-based path, I'm very interested in Andrew's work. I use<br>YAAC on a Raspberry Pi in my car, and could certainly take the new code<br>out for a test drive (pun intended and not). Let me know what I can do<br>to help.<br><br>Thanks to all for the excellent discussion, and the great ideas to try!<br><br>Greg KO6TH<br><br><br>spam8mybrain via aprssig wrote:<br>> Bob,<br>><br>> I could have something available for option#2 in a week or so, freely<br>> available. I've been working on this sort of usecase for some time<br>> now, but I haven't been in charge enough to deploy it.<br>><br>> And I'm still working on adding supplemental information to the<br>> reports from one-way trackers, like how many injured/exhausted<br>> bicyclists riding in a SAG vehicle.<br>><br>> Andrew, KA2DDO<br>> author of YAAC<br>><br>><br>> -------- Original message --------<br>> From: Robert Bruninga <bruninga@usna.edu><br>> Date: 12/3/19 19:08 (GMT-05:00)<br>> To: aprssig@lists.tapr.org<br>> Subject: Re: [aprssig] Multi control station situational awareness -<br>> For mobiles? or homes without power?<br>><br>> There sounds like two paths emerging.<br>><br>> - Come-as-you are with APRS radios in the mobile as the end terminal unit<br>> Everybody has one<br>><br>> - Invent something new with PC's, clients, Pi's, displays, for use at home<br>> (or front seat mobile?<br>> Nobody has one<br>><br>><br>> -----Original Message-----<br>> From: aprssig <aprssig-bounces@lists.tapr.org> On Behalf Of Shawn Stoddard<br>> Sent: Tuesday, December 3, 2019 7:01 PM<br>> To: aprssig@lists.tapr.org<br>> Subject: Re: [aprssig] Multi control station situational awareness - How's<br>> this supposed to work?<br>><br>><br>> Great sanity check. You’re thinking the same path I am.<br>><br>> On Tue, Dec 3, 2019, at 15:40, Greg Troxel wrote:<br>> > I would urge you to step back and consider your requirements, think<br>> > about the protocol that will be used at a high level, and then figure<br>> > out how to use specific techniques to implement that protocol.<br>> ><br>> > If what you want to do is publish infomration about status of<br>> > particular places, then APRS probably is the best fit.<br>> ><br>> > If you are trying to synchronize the list of checked-in stations among<br>> > N NCS stations, then I think you want some sort of database sync<br>> > protocol which is going to send messages among the participants, and<br>> > you may or may not want to carry that over APRS.<br>> ><br>> > I think you implied this, but from the "train like you'll fight" I<br>> > would 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,<br>> > because otherwise you are likely to be depending on it more then you<br>> > think.<br>> ><br>> > ALl of this is going to push you to protocols that are very terse and<br>> > push just the data, with all formatting and UI local. This means<br>> > writing a local implementation of the UI for the protocol.<br>> ><br>> > 73 de n1dam<br>> ><br>> > <br><br></body></html>