[aprssig] Announcing Events - Etiquette

[Stephen H. Smith]

On 1/25/2014 1:08 PM, Mike GM1WKR wrote:
> Hello,
> I am looking for some opinions and guidance on the best (least annoying) way to
> announce one-off events such as Ham Conventions on APRS (focusing on RF).  I am
> writing a Python thing which will be released (eventually ;-) so don't want to
> produce something that may cause problems in busy/active RF areas.
> My thought is to announce using Bulletin format while the event is far off and
> then switch to a posit object as it becomes 'more current'.  Just prior (as
> mobiles are converging) the Talk-In frequency would be sent.  During the event
> the frequency object would be rolled back as not to hog the RF Channel.
> I am working on the following ...
      <SNIP>
> Thanks in advance,
> Mike
> GM1WKR


I'd love to have something like this as a UIview plug-in.



I would also use something like this with a less aggressive schedule for 
monthly club meets.  In the past, I have used M0CYP's "APRS Events" UIview 
plug-in for this purpose, but it only sends bulletins.    It would be really 
nice to have something that can also send objects with positions.



In the past, I would have APRS Events start sending the bulletins about 36 
hours before a monthly club meeting.  This would ensure that commuting mobiles 
would have 4 chances  (AM and PM the day before, and AM and PM the day of the 
event) to see the bulletin for a meeting starting at 7 or 8 PM.

I would prepare a list, a year in advance, of the monthly meeting dates for 
about 4 different ham clubs that were all in the footprint of a specific nearby 
digipeater.  Month after month, APRS Events would automatically send the 
bulletins out on the right days from my UIview igate/digi/webserver.

[Because APRS Events was constructed as an application that linked to the AGWpe 
interface, you didn't actually need UIview at all.  Events could share a 
hardware or software TNC along side other apps also using the AGWpe interface.]

I would set the digipeat path to the actual call of a specific digi, not a 
generic WIDEn-N, to ensure that only the relevant part of the greater Los 
Angeles area would be covered.

If I could have done it, I would have sent objects starting about  24 hours 
before the event at about once every half hour. This would increase to around 
once every 10 mins starting about 3 hours before the event, with an object kill 
about halfway through the expected duration of the event.  I.e. if stragglers 
haven't shown up by halfway through the meeting, they probably aren't interested.


BOTTOM LINE:

o    Make the app talk to the AGW Packet Engine API.

on   Allow digi paths to be specified individually for each event/meeting so 
digipeater coverage can be tailored to be relevant to the specific event.  I.e 
one might use SSn for a state convention, but an explicit DIGICALL for a local 
monthly club meeting.

o    Interface should solicit the date & hour of the meeting or event. Date 
ideally should be a fully-formed YYYY-MM-DD format so events could potentially 
be loaded years in advance.  The ultimate elegance would be the kind of popup 
clickable mini-calendars you see on AIRLINE-MOTEL-CAR reservation sites.

o    It would then ask "How many days in advance should bulletins begin", "How 
many hours in advance should infrequent objects begin?", How many hours in 
advance should frequent objects begin?", and "How many hours after start should 
KILL OBJECT (and end of beaconing)be sent?".


_______________________________________________________________


--

Stephen H. Smith    wa8lmf (at) aol.com
Skype:        WA8LMF
EchoLink:   14400  [Think bottom of the 2-meter band]
Home Page:          http://wa8lmf.net


  Long-Range APRS on 30 Meters HF
     http://wa8lmf.net/aprs/HF_APRS_Notes.htm

High Performance Sound Systems for Soundcard Apps
    http://wa8lmf.net/ham/imic.htm
    http://wa8lmf.net/ham/uca202.htm

"APRS 101"  Explanation of APRS Path Selection & Digipeating
   http://wa8lmf.net/DigiPaths