<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hmmm.... if this would be so useful in UIView, what about in the more modern APRS clients?<br><br>Something to add to my project list....<br><br>Andrew Pavlin, KA2DDO<br>author of YAAC ("Yet Another APRS Client")<br><a href="http://www.ka2ddo.org/ka2ddo/YAAC.html">http://www.ka2ddo.org/ka2ddo/YAAC.html</a><br><br><div>> Date: Sat, 25 Jan 2014 14:34:02 -0500<br>> From: wa8lmf2@aol.com<br>> To: aprssig@tapr.org<br>> Subject: Re: [aprssig] Announcing Events - Etiquette<br>> <br>> On 1/25/2014 1:08 PM, Mike GM1WKR wrote:<br>> > Hello,<br>> > I am looking for some opinions and guidance on the best (least annoying) way to<br>> > announce one-off events such as Ham Conventions on APRS (focusing on RF). I am<br>> > writing a Python thing which will be released (eventually ;-) so don't want to<br>> > produce something that may cause problems in busy/active RF areas.<br>> > My thought is to announce using Bulletin format while the event is far off and<br>> > then switch to a posit object as it becomes 'more current'. Just prior (as<br>> > mobiles are converging) the Talk-In frequency would be sent. During the event<br>> > the frequency object would be rolled back as not to hog the RF Channel.<br>> > I am working on the following ...<br>> <SNIP><br>> > Thanks in advance,<br>> > Mike<br>> > GM1WKR<br>> <br>> <br>> I'd love to have something like this as a UIview plug-in.<br>> <br>> I would also use something like this with a less aggressive schedule for <br>> monthly club meets. In the past, I have used M0CYP's "APRS Events" UIview <br>> plug-in for this purpose, but it only sends bulletins. It would be really <br>> nice to have something that can also send objects with positions.<br>> <br>> In the past, I would have APRS Events start sending the bulletins about 36 <br>> hours before a monthly club meeting. This would ensure that commuting mobiles <br>> would have 4 chances (AM and PM the day before, and AM and PM the day of the <br>> event) to see the bulletin for a meeting starting at 7 or 8 PM.<br>> <br>> I would prepare a list, a year in advance, of the monthly meeting dates for <br>> about 4 different ham clubs that were all in the footprint of a specific nearby <br>> digipeater. Month after month, APRS Events would automatically send the <br>> bulletins out on the right days from my UIview igate/digi/webserver.<br>> <br>> [Because APRS Events was constructed as an application that linked to the AGWpe <br>> interface, you didn't actually need UIview at all. Events could share a <br>> hardware or software TNC along side other apps also using the AGWpe interface.]<br>> <br>> I would set the digipeat path to the actual call of a specific digi, not a <br>> generic WIDEn-N, to ensure that only the relevant part of the greater Los <br>> Angeles area would be covered.<br>> <br>> If I could have done it, I would have sent objects starting about 24 hours <br>> before the event at about once every half hour. This would increase to around <br>> once every 10 mins starting about 3 hours before the event, with an object kill <br>> about halfway through the expected duration of the event. I.e. if stragglers <br>> haven't shown up by halfway through the meeting, they probably aren't interested.<br>> <br>> BOTTOM LINE:<br>> <br>> o Make the app talk to the AGW Packet Engine API.<br>> <br>> on Allow digi paths to be specified individually for each event/meeting so <br>> digipeater coverage can be tailored to be relevant to the specific event. I.e <br>> one might use SSn for a state convention, but an explicit DIGICALL for a local <br>> monthly club meeting.<br>> <br>> o Interface should solicit the date & hour of the meeting or event. Date <br>> ideally should be a fully-formed YYYY-MM-DD format so events could potentially <br>> be loaded years in advance. The ultimate elegance would be the kind of popup <br>> clickable mini-calendars you see on AIRLINE-MOTEL-CAR reservation sites.<br>> <br>> o It would then ask "How many days in advance should bulletins begin", "How <br>> many hours in advance should infrequent objects begin?", How many hours in <br>> advance should frequent objects begin?", and "How many hours after start should <br>> KILL OBJECT (and end of beaconing)be sent?".<br><br></div> </div></body>
</html>