[aprssig] Multi control station situational awareness - For mobiles? or homes without power?

[spam8mybrain]

Greetings. 
    
It took longer than I thought to implement it (too much holiday madness), but I have a prototype I'm starting to test. I haven't finished writing the protocol extension specification document yet, but I should have Version 0 ready by next week.So I can share crude database tables with any number of peer APRS stations (RF or Internet), and share the table structure and labeling schema out-of-band so that the media can't see the column labels. Still working on Frank's request to support database entries for non-APRS entities over the same transport.Anyone want to try it out next week?Andrew, KA2DDOauthor of YAAC

-------- Original message --------
From: spam8mybrain via aprssig <aprssig at lists.tapr.org> 
Date: 12/4/19  09:21  (GMT-05:00) 
To: Greg D <ko6th.greg at gmail.com>, Robert Bruninga <bruninga at usna.edu>, aprssig at lists.tapr.org 
Subject: Re: [aprssig] Multi control station situational awareness - For mobiles? or homes without power? 

Hi, Greg.
    
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.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.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.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.I can write this up more formally as a proposed extension to the APRS protocol specification.Andrew, KA2DDOauthor of YAAC-------- Original message --------From: Greg D <ko6th.greg at gmail.com> Date: 12/3/19  22:26  (GMT-05:00) To: spam8mybrain <spam8mybrain at yahoo.com>, Robert Bruninga <bruninga at usna.edu>, aprssig at lists.tapr.org Subject: Re: [aprssig] Multi control station situational awareness - For
  mobiles? or homes without power? Hi all,Wow, excellent discussion.  And, thanks Andrew for your insight into theproblem, if not your actual code.  Would this be a view of the data fromwithin YAAC, or a separate application?To summarize some of the thoughts....  First, a bit of clarification onwhat I'm envisioning are parameters that the solution should include. The scale, for starters.  Right now we're looking at check-ins(contributions) from the field of view of our club's repeater, whichcovers the outage area our members reside in pretty well.  That area issome 40 miles in diameter, or 120-ish square miles.  The terrain is theSierra Nevada foothills, so lots of valleys.  Our repeater has batterybackup power, good for several weeks, which worked perfectly.  At thenorth end, about 25 miles from the club repeater is a high level Digi,which appears to also have backup power (it was operating continually asfar as I could tell).  Its coverage is even larger, and can usually becounted on to hit an iGate somewhere, though not all iGates in the areaare bi-directional.  But because of the terrain, not everyone can hitthat Digi with any reliability, and the few fill-in digis are usuallynot outfitted with backup power (mine isn't).  I believe both netcontrol stations can hit it, and there's enough coverage that we coulduse APRS as a viable transport.We discussed the use of mesh netwoks, such as the mentioned TARPN, andAREDN which is similar.  These networks don't currently exist in thisarea, and again with the physical area and terrain, would take some timeand money to create.  Doubtful that such an undertaking would besupported for the need we have identified. Hosting a dial-up node is not going to be good, as I was pretty muchalone in having a working land-line phone, and that it was working was ahuge surprise to me, as it's gone down (no dial tone) for everyunplanned outage over the past about 3 years.  Creative idea, however.Packet BBS was not an option we had though of.  There are (or, were?) afew packet BBS systems in the state, and I think one within earshot ofme is still operating.  Haven't used it for a while.  That certainlycould be a way to pass a file around from one control operator toanother.  But being an informal net, we didn't set up a specificoperator schedule.  Instead we just let each other know when we came andwent; often both were available at the same time.  So, the idea ofpassing a file around would take some coordination, but could bepossible.  We had thought to use Winlink for this.  If nothing else, myTNC is an MFJ-1278T with a huge mail storage card installed.  It'smostly wasted technology, as I run the TNC in KISS mode... This is aworthwhile thing to investigate, if we can figure out the RF paths. Thanks for the idea! Overall size of the data collected is important to consider.  Myhand-written notes from the 3 events totaled about 4 pages, singlesided.  So, this is way more than will fit in an HT, good size for textfiles, and trivially small for an enterprise-class application (SARtrack).The two (current) net control operators included one ham who is about 10crow-flies miles from the other (me), but not on a line-of-sight basis. He has radios and backup power (battery + generator), and was on themfor all 3 of the major outages.  No internet during the outages.  I wasthe other operator, and my situation is less dire, as I was only outduring the first of the three outages.  For the other two, I had bothpower and Internet, and could view the PG&E website for their updates. For the first outage, I was totally offline until power came back.  Nogenerator here (nor a desire to have one); I have battery backup power,and can hit the repeater with just my Kenwood D-74 and the main beamantenna.  Computers here were not used during the outage, but I have avariety of platforms from the proverbial Raspberry Pi to laptops thatare within capacity of the batteries.  And in a pinch I could tap intothe battery in my EV.A question about Objects...  How much information can one objectcontain?  I was thinking 1 packet-worth, but apparently that's nottrue?  I think that it would be good for folks to be able to see theobjects as they are generated, but as Stephen says, creating one on anHT-sans-PC is not going to happen.  Data input from the population atlarge is expected to be primarily voice through the repeater.So, next steps.  On the guess that I'd survive the last planned outage,we set up a Google Docs file to use as a test bed to see what sorts ofinformation should be captured and now the baton passing could workbetween stations.  The outage ended up being canceled for our area, sowe didn't have a chance to test it in action.  We did a littlepre-outage postings with it, and it seemed like it would work well.  So,that's action along the file-transfer leg of the discussion.For the live RF-based path, I'm very interested in Andrew's work.  I useYAAC on a Raspberry Pi in my car, and could certainly take the new codeout for a test drive (pun intended and not).  Let me know what I can doto help.Thanks to all for the excellent discussion, and the great ideas to try!Greg  KO6THspam8mybrain via aprssig wrote:> Bob,>> I could have something available for option#2 in a week or so, freely> available. I've been working on this sort of usecase for some time> now, but I haven't been in charge enough to deploy it.>> And I'm still working on adding supplemental information to the> reports from one-way trackers, like how many injured/exhausted> bicyclists riding in a SAG vehicle.>> Andrew, KA2DDO> author of YAAC>>> -------- Original message --------> From: Robert Bruninga <bruninga at usna.edu>> Date: 12/3/19 19:08 (GMT-05:00)> To: aprssig at lists.tapr.org> Subject: Re: [aprssig] Multi control station situational awareness -> For mobiles? or homes without power?>> There sounds like two paths emerging.>> - Come-as-you are with APRS radios in the mobile as the end terminal unit>    Everybody has one>> - Invent something new with PC's, clients, Pi's, displays, for use at home> (or front seat mobile?>   Nobody has one>>> -----Original Message-----> From: aprssig <aprssig-bounces at lists.tapr.org> On Behalf Of Shawn Stoddard> Sent: Tuesday, December 3, 2019 7:01 PM> To: aprssig at lists.tapr.org> Subject: Re: [aprssig] Multi control station situational awareness - How's> this supposed to work?>>> Great sanity check. You’re thinking the same path I am.>> On Tue, Dec 3, 2019, at 15:40, Greg Troxel wrote:> > I would urge you to step back and consider your requirements, think> > about the protocol that will be used at a high level, and then figure> > out how to use specific techniques to implement that protocol.> >> > If what you want to do is publish infomration about status of> > particular places, then APRS probably is the best fit.> >> > If you are trying to synchronize the list of checked-in stations among> > N NCS stations, then I think you want some sort of database sync> > protocol which is going to send messages among the participants, and> > you may or may not want to carry that over APRS.> >> > I think you implied this, but from the "train like you'll fight" I> > would suggest using the over-the-air sync all the time, and not use any> > direct-to-APRS-IS internet-based injection.   Gatewaying to APRS-IS is> > great for others to probably be able to see what's up, but I think you> > should plan on no internet, and thus operate that way routinely,> > because otherwise you are likely to be depending on it more then you> > think.> >> > ALl of this is going to push you to protocols that are very terse and> > push just the data, with all formatting and UI local.  This means> > writing a local implementation of the UI for the protocol.> >> > 73 de n1dam> >> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200102/e0ba4b88/attachment.html>