Loading ...
Sorry, an error occurred while loading the content.

digi / alias

Expand Messages
  • Mark Miller
    Scott, I have been looking at how OT2 digipeats. It looks like the only valid ALIAS values are WIDE1 and WIDE. WIDE1 behaves where any WIDE1-N will be
    Message 1 of 16 , Aug 27, 2006
    View Source
    • 0 Attachment
      Scott,

      I have been looking at how OT2 digipeats. It looks like the only valid
      ALIAS values are WIDE1 and WIDE. WIDE1 behaves where any WIDE1-N will be
      treated at WIDE1-1. I found a station in my area sending WIDE1-2, other
      digipeaters decremented to WIDE1-1, but the OT2 digipeated, and finished
      off the WIDE, which I think is correct. I set up an ALIAS of WIDE2, and it
      does the same as WIDE1. Any WIDE2-N gets finished off. That is why it
      looks like the only valid ALIAS values are WIDE1, or WIDE. WIDE digipeats
      for any WIDEn-N.

      73,

      Mark N5RFX
    • Cap Pennell
      Yes, it is correct that any WIDE1-N should be treated as though it was heard as WIDE1-1. If a APRS user sets WIDE1-1 our new North American system intends it
      Message 2 of 16 , Aug 27, 2006
      View Source
      • 0 Attachment
        Yes, it is correct that any WIDE1-N should be treated as though it was heard
        as WIDE1-1.
        If a APRS user sets WIDE1-1 our "new" North American system intends it only
        to be set as the _first_ digipeater address in a mobile or portable
        station's digipath. (Sort of like the former, now obsolete RELAY but
        creating far fewer duplicate packets than RELAY and WIDE did.)
        Responding to that WIDE1-1, as transmitted by the (OT2) digi a mobile user's
        path of WIDE1-1,WIDE2-1 should become OT2mycall*,WIDE2-1 or
        OT2mycall,WIDE1*,WIDE2-1.

        Scott told us he was planning to add a 'first hop only' flag for each alias
        too (hopefully set as a default) - if it's enabled, the alias will only be
        used if nothing else has marked a digi field as used or decremented an n-N
        counter. That's intended to let it pick up on WIDE-anything as a fill-in
        without it being specifically requested.
        73, Cap KE6AFE

        > -----Original Message-----
        > From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com]On
        > Behalf Of Mark Miller
        > Sent: Sunday, August 27, 2006 04:32 AM
        > To: tracker2@yahoogroups.com
        > Subject: [tracker2] digi / alias
        >
        >
        > Scott,
        >
        > I have been looking at how OT2 digipeats. It looks like the only valid
        > ALIAS values are WIDE1 and WIDE. WIDE1 behaves where any WIDE1-N will be
        > treated at WIDE1-1. I found a station in my area sending WIDE1-2, other
        > digipeaters decremented to WIDE1-1, but the OT2 digipeated, and finished
        > off the WIDE, which I think is correct. I set up an ALIAS of
        > WIDE2, and it
        > does the same as WIDE1. Any WIDE2-N gets finished off. That is why it
        > looks like the only valid ALIAS values are WIDE1, or WIDE. WIDE
        > digipeats
        > for any WIDEn-N.
        >
        > 73,
        >
        > Mark N5RFX
      • scott@opentrac.org
        I need to pull up what I got Bob to declare the official behavior, and make sure it s documented on the APRS Wiki, and then we can decide if it s right or
        Message 3 of 16 , Sep 4, 2006
        View Source
        • 0 Attachment
          I need to pull up what I got Bob to declare the 'official' behavior, and make sure it's documented on the APRS Wiki, and then we can decide if it's right or not and see what needs to be done to meet the spec.  Got my hands full with other stuff right now and haven't had time to tweak the digi behavior.
           
          Scott


          From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of Mark Miller
          Sent: Sunday, August 27, 2006 4:32 AM
          To: tracker2@yahoogroups.com
          Subject: [tracker2] digi / alias

          Scott,

          I have been looking at how OT2 digipeats. It looks like the only valid
          ALIAS values are WIDE1 and WIDE. WIDE1 behaves where any WIDE1-N will be
          treated at WIDE1-1. I found a station in my area sending WIDE1-2, other
          digipeaters decremented to WIDE1-1, but the OT2 digipeated, and finished
          off the WIDE, which I think is correct. I set up an ALIAS of WIDE2, and it
          does the same as WIDE1. Any WIDE2-N gets finished off. That is why it
          looks like the only valid ALIAS values are WIDE1, or WIDE. WIDE digipeats
          for any WIDEn-N.

          73,

          Mark N5RFX

        • James Ewen
          ... So, if Bob declares it official , does that make it proper? I ve been trying to wrap my head around these observations, and what is being described. ...
          Message 4 of 16 , Sep 4, 2006
          View Source
          • 0 Attachment
            >I need to pull up what I got Bob to declare the 'official' behavior
             
            So, if Bob declares it 'official', does that make it proper?
             
            I've been trying to wrap my head around these observations, and what is being described.
             
            >It looks like the only valid ALIAS values are WIDE1 and
            WIDE.
             
            Valid for the OT2, or what?
             
            >WIDE1 behaves where any WIDE1-N will be treated at WIDE1-1.
             
            So, the OT2 would turn WIDE1-7 into DIGIA,WIDE1*?
             
            >I found a station in my area sending WIDE1-2, other digipeaters
            >decremented to WIDE1-1, but the OT2 digipeated, and finished
            >off the WIDE, which I think is correct.
             
            Kantronics will decrement any ssid, no matter what the number before the '-' is. The OT2 is responding okay.
             
            >I set up an ALIAS of WIDE2, and it does the same as WIDE1.
            >Any WIDE2-N gets finished off.
             
            Here's where it gets confusing. Does it turn any WIDE2-N into DIGIA,WIDE2*? It should decrement WIDE2-2 into WIDE2-1, WIDE2-1 into WIDE2*, of course with callsign insertion as well.
             
             
            Anyway, back to the 'official' behaviour... The Kantronics TNCs don't do any checking to make sure that the n-N values are 'valid'. It is possible for the user to input a path such as WIDE2-4. This allows the user to bypass some digipeater operator attempts to limit long abusive paths.
             
            I would suggest that the original intent was to have the n-N value to be set to the same value, and that being able to set the 'N' value higher than 'n' is an oversight.
             
            I would suggest that proper handling of a non-valid n-N setting would be to make N=n-1 if N>n, when digipeating.
             
            James
            VE6SRV

            I am using the free version of SPAMfighter for private users.
            It has removed 165 spam emails to date.
            Paying users do not have this message in their emails.
            Try SPAMfighter for free now!
          • Cap Pennell
            Right, James, I think. The objectives of the new (current) system are to: 1. eliminate duplicate packets (to allow more throughput for all of the users on VHF)
            Message 5 of 16 , Sep 8, 2006
            View Source
            • 0 Attachment
              Right, James, I think.
               
              The objectives of the new (current) system are to:
              1. eliminate duplicate packets (to allow more throughput for all of the users on VHF)
              2. allow "tracing" of digipeater operation (using "callsign insertion")
              3. provide for fill-in or temporary digis to assist mobile stations only where needed
               
              Fill-in digis operate WIDE1-1 ONLY (and MYcall).  Generally, mobile stations do not digipeat at all.
              High-level permanent digis operate WIDE1-1 or WIDE2-2 or WIDE2-1 at least (and MYcall), and perform "callsign insertion".
               
              It's assumed all users of WIDEn-N will set n=N as in WIDE1-1 or WIDE2-2 (only routine exception is the mobile path WIDE1-1,WIDE2-1).
               
              Courteous routine or special event digipath, Base:WIDE2-2  Mobile:WIDE1-1,WIDE2-1  (either provides two hops in all directions)
               
              73, Cap KE6AFE
              -----Original Message-----
              From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com]On Behalf Of James Ewen
              Sent: Monday, September 04, 2006 23:18 PM
              To: tracker2@yahoogroups.com
              Subject: Re: [tracker2] digi / alias

              >I need to pull up what I got Bob to declare the 'official' behavior
               
              So, if Bob declares it 'official', does that make it proper?
               
              I've been trying to wrap my head around these observations, and what is being described.
               
              >It looks like the only valid ALIAS values are WIDE1 and WIDE.
               
              Valid for the OT2, or what?
               
              >WIDE1 behaves where any WIDE1-N will be treated at WIDE1-1.
               
              So, the OT2 would turn WIDE1-7 into DIGIA,WIDE1*?
               
              >I found a station in my area sending WIDE1-2, other digipeaters
              >decremented to WIDE1-1, but the OT2 digipeated, and finished
              >off the WIDE, which I think is correct.
               
              Kantronics will decrement any ssid, no matter what the number before the '-' is. The OT2 is responding okay.
               
              >I set up an ALIAS of WIDE2, and it does the same as WIDE1.
              >Any WIDE2-N gets finished off.
               
              Here's where it gets confusing. Does it turn any WIDE2-N into DIGIA,WIDE2*? It should decrement WIDE2-2 into WIDE2-1, WIDE2-1 into WIDE2*, of course with callsign insertion as well.
               
               
              Anyway, back to the 'official' behaviour... The Kantronics TNCs don't do any checking to make sure that the n-N values are 'valid'. It is possible for the user to input a path such as WIDE2-4. This allows the user to bypass some digipeater operator attempts to limit long abusive paths.
               
              I would suggest that the original intent was to have the n-N value to be set to the same value, and that being able to set the 'N' value higher than 'n' is an oversight.
               
              I would suggest that proper handling of a non-valid n-N setting would be to make N=n-1 if N>n, when digipeating.
               
              James
              VE6SRV

              I am using the free version of SPAMfighter for private users.
              It has removed 165 spam emails to date.
              Paying users do not have this message in their emails.
              Try SPAMfighter for free now!
            • scott@opentrac.org
              Bob s official behavior at least gives us a starting point for discussion. _____ From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf
              Message 6 of 16 , Sep 10, 2006
              View Source
              • 0 Attachment
                Bob's 'official' behavior at least gives us a starting point for discussion.


                From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of James Ewen
                Sent: Monday, September 04, 2006 11:18 PM
                To: tracker2@yahoogroups.com
                Subject: Re: [tracker2] digi / alias

                >I need to pull up what I got Bob to declare the 'official' behavior
                 
                So, if Bob declares it 'official', does that make it proper?
                 
                I've been trying to wrap my head around these observations, and what is being described.
                 
                >It looks like the only valid ALIAS values are WIDE1 and WIDE.
                 
                Valid for the OT2, or what?
                 
                >WIDE1 behaves where any WIDE1-N will be treated at WIDE1-1.
                 
                So, the OT2 would turn WIDE1-7 into DIGIA,WIDE1* ?
                 
                >I found a station in my area sending WIDE1-2, other digipeaters
                >decremented to WIDE1-1, but the OT2 digipeated, and finished
                >off the WIDE, which I think is correct.
                 
                Kantronics will decrement any ssid, no matter what the number before the '-' is. The OT2 is responding okay.
                 
                >I set up an ALIAS of WIDE2, and it does the same as WIDE1.
                >Any WIDE2-N gets finished off.
                 
                Here's where it gets confusing. Does it turn any WIDE2-N into DIGIA,WIDE2* ? It should decrement WIDE2-2 into WIDE2-1, WIDE2-1 into WIDE2*, of course with callsign insertion as well.
                 
                 
                Anyway, back to the 'official' behaviour... The Kantronics TNCs don't do any checking to make sure that the n-N values are 'valid'. It is possible for the user to input a path such as WIDE2-4. This allows the user to bypass some digipeater operator attempts to limit long abusive paths.
                 
                I would suggest that the original intent was to have the n-N value to be set to the same value, and that being able to set the 'N' value higher than 'n' is an oversight.
                 
                I would suggest that proper handling of a non-valid n-N setting would be to make N=n-1 if N>n, when digipeating.
                 
                James
                VE6SRV

                I am using the free version of SPAMfighter for private users.
                It has removed 165 spam emails to date.
                Paying users do not have this message in their emails.
                Try SPAMfighter for free now!

              • James Ewen
                ... Bob came up with an excellent application when he dreamt up APRS. One problem with APRS is that it has never been well documented. The APRS specification
                Message 7 of 16 , Sep 10, 2006
                View Source
                • 0 Attachment
                  > Bob's 'official' behavior at least gives us a starting point for discussion.

                  Bob came up with an excellent application when he dreamt up APRS. One problem with APRS is that it has never been well documented. The APRS specification document that took years to complete describes quite a bit about the string formats and such, but there is still nothing describing the operation of the network.

                  APRS still needs to have a document that describes proper operation of digipeaters, how packets should be handled as they pass through the network, and such.

                  I know I have spent a lot of time discussing the concepts and ideas, as well as talking about improvements that could be done to help increase the reliability and performance of the network.

                  The OT2 is poised to be a tool to allow us to work towards making the APRS network better by allow us to experiment with new concepts. Current existing hardware limits what can be done to the capabilities burnt into the firmware.

                  Be prepare Scott... you're opening a Pandora's box with this unit! It's going to be interesting to see what comes of it!

                  James
                  VE6SRV
                • Cap Pennell
                  Not having a OT2 on hand to fiddle with, and finding only the settings descriptions listed below apparently relevant within the new Tracker2.txt (Tracker2
                  Message 8 of 16 , Sep 10, 2006
                  View Source
                  • 0 Attachment
                    Not having a OT2 on hand to fiddle with, and finding only the settings
                    descriptions listed below apparently relevant within the new Tracker2.txt
                    (Tracker2 user's guide), I'm confused and ignorant. <not unusual>

                    I don't see any settings information about decrementing WIDEn-N nor even
                    only WIDE1-1 (as a fill-in digi). Hearing the description of operation from
                    Mark N5RFX, it does seem as though setting
                    ALIAS 1 WIDE1
                    may produce a fill-in digi. ?
                    But then does a mobile user's routine path setting of WIDE1-1,WIDE2-1 after
                    passing through Mark's OT2 become N5RFX,WIDE1*,WIDE2-1 (or N5RFX*,WIDE2-1)
                    thereby subsequently allowing the second hop by a distant digi (as a fill-in
                    digi should)?
                    Assuming Mark's OT2 is somehow setup to be a modern full "NEWn-N" digi, does
                    a home user's path setting of WIDE2-2 after passing through Mark's OT2
                    become N5RFX*,WIDE2-1 (as it should)?
                    Of course, plain WIDE is obsolete in North America at least.
                    73, Cap KE6AFE


                    ALIAS <n> <callsign>
                    Set digipeater alias for slot <n>. This will typically be
                    a generic alias like 'WIDE'. No SSID is allowed in this
                    field.

                    DIGI on|off
                    Enable digipeating on MYCALL

                    DIGIID <n> on|off
                    Enable callsign substitution for digipeater alias <n>.
                    This should normally be enabled.

                    DUPETIME <0-255> (seconds)
                    Digipeating duplicate suppression period

                    PREEMPT <n> on|off
                    Enable digipeater preemption for alias <n>. If preemption is
                    enabled, packets will be digipeated on this alias even if it
                    isn't the next address in the list.
                  • Mark Miller
                    From what I have observed ... N5RFX*,WIDE2-1 ... N5RFX*,WIDE2-1 73, Mark N5RFX
                    Message 9 of 16 , Sep 10, 2006
                    View Source
                    • 0 Attachment
                      From what I have observed


                      >But then does a mobile user's routine path setting of WIDE1-1,WIDE2-1 after
                      >passing through Mark's OT2 become N5RFX,WIDE1*,WIDE2-1 (or N5RFX*,WIDE2-1)

                      N5RFX*,WIDE2-1

                      >Assuming Mark's OT2 is somehow setup to be a modern full "NEWn-N" digi, does
                      >a home user's path setting of WIDE2-2 after passing through Mark's OT2
                      >become N5RFX*,WIDE2-1 (as it should)?

                      N5RFX*,WIDE2-1

                      73,

                      Mark N5RFX
                    • Mark Miller
                      I have only been involved with APRS for a little more than a year, and I am comforted to know that I have not missed any documentation or specs. I am not
                      Message 10 of 16 , Sep 10, 2006
                      View Source
                      • 0 Attachment
                        I have only been involved with APRS for a little more than a year, and I am
                        comforted to know that I have not missed any documentation or specs. I am
                        not comforted to know that these specs do not exist. I know that APRS and
                        the TAPR DCC used to be together, has that changed? Is there an official
                        body for APRS? I am not volunteering to write the DOCs, but I would
                        certainly help. I am afraid to ask this on the APRS SIG.

                        73,

                        Mark N5RFX


                        >Bob came up with an excellent application when he dreamt up APRS. One
                        >problem with APRS is that it has never been well documented. The APRS
                        >specification document that took years to complete describes quite a bit
                        >about the string formats and such, but there is still nothing describing
                        >the operation of the network.
                        >
                        >APRS still needs to have a document that describes proper operation of
                        >digipeaters, how packets should be handled as they pass through the
                        >network, and such.
                      • Jason Winningham
                        ... The spec is more or less what Bob wants it to be, including any retroactive changes he chooses to make to keep it compatible with 20 year old hardware.
                        Message 11 of 16 , Sep 10, 2006
                        View Source
                        • 0 Attachment
                          On Sep 10, 2006, at 6:32 PM, Mark Miller wrote:

                          > I am not comforted to know that these specs do not exist.

                          The spec is more or less what Bob wants it to be, including any
                          retroactive changes he chooses to make to keep it compatible with 20
                          year old hardware. There was an initial spec that was done in the
                          typical way, but Bob has since self-published revisions and makes
                          changes/additions when he feels like it by putting stuff on his web
                          site (and good luck navigating it).

                          -Jason
                          kg4wsv
                        • Cap Pennell
                          That s good news, Mark. Thanks. You indicate your OT2 is operating the mobile user s WIDE1-1 properly, as a fill-in digi. And also that your OT2 is
                          Message 12 of 16 , Sep 11, 2006
                          View Source
                          • 0 Attachment
                            That's good news, Mark. Thanks. You indicate your OT2 is operating the
                            mobile user's WIDE1-1 properly, as a fill-in digi. And also that your OT2
                            is decrementing the home user's WIDE2-2 and is operating as a full NEWn-N
                            digi.

                            Now it occurs to me that the last thing our VHF network needs is a bunch of
                            new "traveling NEWn-N digis" injecting extra copies of everybody's packets
                            into the VHF network. hi hi With the "hidden transmitter problem" that the
                            OT2 will face too, we'd best not rely solely on the mobile OT2 to interpret
                            whether a packet was heard by another digi or not.

                            In general, mobile or portable stations should not digipeat at all (except
                            perhaps on their MYcall), largely because of the hidden transmitter problem.

                            Maybe the OT2 will have a "do not digipeat while GPS attached, except
                            MYcall" default? hi
                            73, Cap KE6AFE

                            > -----Original Message-----
                            > From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com]On
                            > Behalf Of Mark Miller
                            > Sent: Sunday, September 10, 2006 16:29 PM
                            > To: tracker2@yahoogroups.com
                            > Subject: RE: [tracker2] digi / alias
                            >
                            >
                            > From what I have observed
                            >
                            >
                            > >But then does a mobile user's routine path setting of
                            > WIDE1-1,WIDE2-1 after
                            > >passing through Mark's OT2 become N5RFX,WIDE1*,WIDE2-1 (or
                            > N5RFX*,WIDE2-1)
                            >
                            > N5RFX*,WIDE2-1
                            >
                            > >Assuming Mark's OT2 is somehow setup to be a modern full
                            > "NEWn-N" digi, does
                            > >a home user's path setting of WIDE2-2 after passing through Mark's OT2
                            > >become N5RFX*,WIDE2-1 (as it should)?
                            >
                            > N5RFX*,WIDE2-1
                            >
                            > 73,
                            >
                            > Mark N5RFX
                            >
                          • Jason Winningham
                            ... I think that s the default regardless of whether a GPS is attached... -Jason kg4wsv
                            Message 13 of 16 , Sep 11, 2006
                            View Source
                            • 0 Attachment
                              On Sep 11, 2006, at 6:57 PM, Cap Pennell wrote:

                              > Maybe the OT2 will have a "do not digipeat while GPS attached, except
                              > MYcall" default? hi

                              I think that's the default regardless of whether a GPS is attached...

                              -Jason
                              kg4wsv
                            • scott@opentrac.org
                              Yeah, just wait until I get a unit that ll take firmware updates over the air! ;) _____ From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On
                              Message 14 of 16 , Sep 11, 2006
                              View Source
                              • 0 Attachment
                                Yeah, just wait until I get a unit that'll take firmware updates over the air!  ;)


                                From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of James Ewen
                                Sent: Sunday, September 10, 2006 3:25 PM
                                To: tracker2@yahoogroups.com
                                Subject: Re: RE: [tracker2] digi / alias

                                > Bob's 'official' behavior at least gives us a starting point for discussion.

                                Bob came up with an excellent application when he dreamt up APRS. One problem with APRS is that it has never been well documented. The APRS specification document that took years to complete describes quite a bit about the string formats and such, but there is still nothing describing the operation of the network.

                                APRS still needs to have a document that describes proper operation of digipeaters, how packets should be handled as they pass through the network, and such.

                                I know I have spent a lot of time discussing the concepts and ideas, as well as talking about improvements that could be done to help increase the reliability and performance of the network.

                                The OT2 is poised to be a tool to allow us to work towards making the APRS network better by allow us to experiment with new concepts. Current existing hardware limits what can be done to the capabilities burnt into the firmware.

                                Be prepare Scott... you're opening a Pandora's box with this unit! It's going to be interesting to see what comes of it!

                                James
                                VE6SRV

                              • scott@opentrac.org
                                As far as I know, the APRS Working Group is pretty much defunct. They seem to wake up every year or so to ratify some change Bob proposes, but that s about
                                Message 15 of 16 , Sep 11, 2006
                                View Source
                                • 0 Attachment
                                  As far as I know, the APRS Working Group is pretty much defunct.  They seem to wake up every year or so to ratify some change Bob proposes, but that's about it.  Bob seems to be taking the 'official' spec off on his own with his proposed extensions.  There have been a lot of complaints that his propose (maybe ratified?) changes are only in text files on his site, which still sits at an obscure-looking domain, while TAPR has nice PDF copies of what everyone assumes to be the latest official spec.


                                  From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of Mark Miller
                                  Sent: Sunday, September 10, 2006 4:32 PM
                                  To: tracker2@yahoogroups.com
                                  Subject: Re: RE: [tracker2] digi / alias

                                  I have only been involved with APRS for a little more than a year, and I am
                                  comforted to know that I have not missed any documentation or specs. I am
                                  not comforted to know that these specs do not exist. I know that APRS and
                                  the TAPR DCC used to be together, has that changed? Is there an official
                                  body for APRS? I am not volunteering to write the DOCs, but I would
                                  certainly help. I am afraid to ask this on the APRS SIG.

                                  73,

                                  Mark N5RFX

                                  >Bob came up with an excellent application when he dreamt up APRS. One
                                  >problem with APRS is that it has never been well documented. The APRS
                                  >specification document that took years to complete describes quite a bit
                                  >about the string formats and such, but there is still nothing describing
                                  >the operation of the network.
                                  >
                                  >APRS still needs to have a document that describes proper operation of
                                  >digipeaters, how packets should be handled as they pass through the
                                  >network, and such.

                                • Cap Pennell
                                  The APRS Protocol v1.0.1 document sprang from a drawn out discussion amongst strong personalities that likely never would have amounted to anything usable if
                                  Message 16 of 16 , Sep 12, 2006
                                  View Source
                                  • 0 Attachment
                                    The APRS Protocol v1.0.1 document sprang from a drawn out discussion amongst strong personalities that likely never would have amounted to anything usable if not for the great patience and effort of the document's editor Ian Wade G3NRW.  Ian's tact, determination, and perseverance saved the day.  Since then, Ian has not worked on any updates to the protocol.  hi hi
                                    73, Cap
                                    -----Original Message-----
                                    From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com]On Behalf Of scott@...
                                    Sent: Monday, September 11, 2006 19:58 PM
                                    To: tracker2@yahoogroups.com
                                    Subject: RE: RE: [tracker2] digi / alias

                                    As far as I know, the APRS Working Group is pretty much defunct.  They seem to wake up every year or so to ratify some change Bob proposes, but that's about it.  Bob seems to be taking the 'official' spec off on his own with his proposed extensions.  There have been a lot of complaints that his propose (maybe ratified?) changes are only in text files on his site, which still sits at an obscure-looking domain, while TAPR has nice PDF copies of what everyone assumes to be the latest official spec.


                                    From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of Mark Miller
                                    Sent: Sunday, September 10, 2006 4:32 PM
                                    To: tracker2@yahoogroups.com
                                    Subject: Re: RE: [tracker2] digi / alias

                                    I have only been involved with APRS for a little more than a year, and I am
                                    comforted to know that I have not missed any documentation or specs. I am
                                    not comforted to know that these specs do not exist. I know that APRS and
                                    the TAPR DCC used to be together, has that changed? Is there an official
                                    body for APRS? I am not volunteering to write the DOCs, but I would
                                    certainly help. I am afraid to ask this on the APRS SIG.

                                    73,

                                    Mark N5RFX

                                    >Bob came up with an excellent application when he dreamt up APRS. One
                                    >problem with APRS is that it has never been well documented. The APRS
                                    >specification document that took years to complete describes quite a bit
                                    >about the string formats and such, but there is still nothing describing
                                    >the operation of the network.
                                    >
                                    >APRS still needs to have a document that describes proper operation of
                                    >digipeaters, how packets should be handled as they pass through the
                                    >network, and such.

                                  Your message has been successfully submitted and would be delivered to recipients shortly.