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

Re: [tracker2] digi / alias

Expand Messages
  • 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 1 of 16 , Sep 4, 2006
    • 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 2 of 16 , Sep 8, 2006
      • 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 3 of 16 , Sep 10, 2006
        • 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 4 of 16 , Sep 10, 2006
          • 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 5 of 16 , Sep 10, 2006
            • 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 6 of 16 , Sep 10, 2006
              • 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 7 of 16 , Sep 10, 2006
                • 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 8 of 16 , Sep 10, 2006
                  • 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 9 of 16 , Sep 11, 2006
                    • 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 10 of 16 , Sep 11, 2006
                      • 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 11 of 16 , Sep 11, 2006
                        • 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 12 of 16 , Sep 11, 2006
                          • 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 13 of 16 , Sep 12, 2006
                            • 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.