[aprssig] Announcing Events - Etiquette
Stephen H. Smith
wa8lmf2 at aol.com
Sat Jan 25 13:34:02 CST 2014
On 1/25/2014 1:08 PM, Mike GM1WKR wrote:
> 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 ...
> Thanks in advance,
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.
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
EchoLink: 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net
Long-Range APRS on 30 Meters HF
High Performance Sound Systems for Soundcard Apps
"APRS 101" Explanation of APRS Path Selection & Digipeating
More information about the aprssig