<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    APRSISCE/32 supports displayable Nicknames for just that purpose. 
    It will eventually be able to transmit them as shared TACTICAL
    callsigns.  The concept is that ANY station can be assigned ANY
    position and be displayed as such on the net controller's screen. 
    And when a new station takes over a tactical position, simply
    re-assign the nickname.  xastir supports the same concept.<br>
    <br>
    This is effectively separating the station from the information, but
    only for display.<br>
    <br>
    Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
    <br>
    On 5/21/2012 10:37 PM, Jim Alles wrote:
    <blockquote
cite="mid:CABS3LnKR7SU1d8dog46yAcfDpoJO161hc_kBJ7jXJe=nkSorMw@mail.gmail.com"
      type="cite">I wrote some suggestions on <a moz-do-not-send="true"
        href="http://www.tapr.org/psr/psr116.pdf">page 11 here</a>, and
      I hope for the day that a callsign-identified mobile station can
      'push around' an object with tactical identifier and the automatic
      GPS location of the station.
      <div>
        <br>
      </div>
      <div>My approach would be to separate the address (callsign) from
        the information, since they tend to spontaneously combust when
        brought together ;)</div>
      <div><br>
      </div>
      <div>Peace,</div>
      <div>Jim A.<br>
        <br>
        <div class="gmail_quote">
          On Mon, May 21, 2012 at 2:16 PM, Lynn W. Deffenbaugh (Mr) <span
            dir="ltr"><<a moz-do-not-send="true"
              href="mailto:ldeffenb@homeside.to" target="_blank">ldeffenb@homeside.to</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            Similar to frequency objects (but limited to 6 characters
            for stations, not 9 for objects), make it a suffix on the
            tactical call.  That way both events can quickly see SAGn,
            FIN, STR (or GO), but they all have a 2 character suffix
            within the 6 first characters or after a - in an object.<br>
            <br>
            SAGnEV (station) or EVSAGn<br>
            TAILEV (station) or EVTAIL<br>
            FINISH-EV (object) or EV-FINISH<br>
            START-EV (object) or EV-START<br>
            <br>
            and so forth where EV is a unique (hopefully) tag describing
            the event.  It could, of course, always come first (as
            shown) which would aid APRS-IS wildcard filters, but I find
            the suffix more quickly deciferable for the station's
            function.<br>
            <br>
            Just because there's a lot of bad-mouthing of "couch
            potatoes" and "it wasn't meant for global views", doesn't
            mean that tactical collisions can be blithely ignored.  If
            we all pay attention to making our tacticals unique for a
            specific event, then we have nothing to worry about even
            when a 2m opening happens during the event and we start
            hearing packets from a similar even two states away!<br>
            <br>
            The issue isn't specific to APRS-IS, but can happen on RF as
            well, so it's worth striving for some sort of uniqueness
            before Murphy drops that band opening in the middle of your
            (non-unique) event.
            <div class="im HOEnZb">
              <br>
              <br>
              Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile
              and Win32<br>
              <br>
            </div>
            <div class="HOEnZb">
              <div class="h5">
                On 5/21/2012 1:59 PM, <a moz-do-not-send="true"
                  href="mailto:n7qnm-lists@nwlink.com" target="_blank">n7qnm-lists@nwlink.com</a>
                wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  As a frequent "client" of the ORIGINAL (at least in
                  time) BALDY and a<br>
                  frequent "luker" here;  I think both John and Lyle
                  have some good points.<br>
                  <br>
                  Is there perhaps another way (Comment?) for
                  INFRASTRUCTURE stations to<br>
                  identify their location to folks with limited display
                  width (ala HamHud or<br>
                  Kenwoods)?    That might help address the issue; but
                  at the same time one<br>
                  could then use local filters to eliminate "noise" from
                  DISTANT tactical<br>
                  calls.<br>
                  <br>
                  Other the other hand, there's still a potential issue
                  here, particularly<br>
                  if folks don't follow the right PATH rules.   I can
                  easily see calls  like<br>
                  "SAG" or "START" or "FINISH" being used by two groups
                  within range of the<br>
                  same mountaintop.  That would definitely cause chaos.<br>
                  <br>
                  Perhaps some some sort of prefix could be added - ala
                  SMSAG1, SMSTART, or<br>
                  SMFIN (Seattle Marathon)?<br>
                  <br>
                  Clay<br>
                  N7QNM<br>
                  N7QNM-9<br>
                  N7QNM-10<br>
                  <br>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    I repeat my original PS:<br>
                    <br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      No, I'm not trying to start a flame war about
                      Tactical station IDs.<br>
                       I'm just trying to help the collisions get sorted
                      out as I notice them.<br>
                    </blockquote>
                    <br>
                    On 5/21/2012 9:11 AM, John Gorkos wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      A considerate APRS manager would include RFONLY or
                      NOGATE in the path<br>
                      of all tactical stations.<br>
                    </blockquote>
                    Actually, that choice alienates a bunch of hams
                    assisting with an event<br>
                    that may not have APRS RF capability but COULD
                    remain aware of the<br>
                    overall situation via an APRS-IS client filtered to
                    the local area to<br>
                    avoid any potential interference from duplicate
                    tactical calls.  You<br>
                    might as well keep all your packets 7 bytes shorter
                    (the length of a<br>
                    path component in the AX.25 header) and let the
                    APRS-IS do whatever it<br>
                    wills with the tactically-named stations' packets.<br>
                    <br>
                    Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows
                    Mobile and Win32<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      John Gorkos<br>
                      AB0OO<br>
                      <br>
                    </blockquote>
                    <br>
                    _______________________________________________<br>
                    aprssig mailing list<br>
                    <a moz-do-not-send="true"
                      href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a><br>
                    <a moz-do-not-send="true"
                      href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig"
                      target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
                    <br>
                    <br>
                  </blockquote>
                  <br>
                  <br>
                  _______________________________________________<br>
                  aprssig mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a><br>
                  <a moz-do-not-send="true"
                    href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig"
                    target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
                  <br>
                </blockquote>
                <br>
                <br>
                _______________________________________________<br>
                aprssig mailing list<br>
                <a moz-do-not-send="true" href="mailto:aprssig@tapr.org"
                  target="_blank">aprssig@tapr.org</a><br>
                <a moz-do-not-send="true"
                  href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig"
                  target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>