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

T2 digipeating n>setting

Expand Messages
  • notrobbage
    Something I brought up a few months back. Tell me if I m reading this wrong. Output is from my AGWPE set-up. The originator is using WIDE1-1,WIDE3-2 by the
    Message 1 of 6 , Jul 1, 2012
    View Source
    • 0 Attachment
      Something I brought up a few months back. Tell me if I'm reading this wrong. Output is from my AGWPE set-up.

      The originator is using WIDE1-1,WIDE3-2 by the looks. VK6RAV-3 is configured to digipeat WIDE3-N which it does.

      VK6RTH-3 is configured to digipeat on WIDE2 for 2 hops and VK6RN-3 is configured for WIDE1 for 1 hop.

      1:Fm VK6MUD To CQ Via VK6RAV-3,WIDE1*,WIDE3-2 <UI pid=F0 Len=49 >[15:41:27]
      =3144.56S/11612.23E-73' from Gidgegannup {UISS53}
      1:Fm VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3*,WIDE3-1 <UI pid=F0 Len=49 >[15:41:28]
      =3144.56S/11612.23E-73' from Gidgegannup {UISS53}
      1:Fm VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3,VK6AHR-3,WIDE3* <UI pid=F0 Len=49 >[15:41:29]
      =3144.56S/11612.23E-73' from Gidgegannup {UISS53}
      1:Fm VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3,VK6RN-3,WIDE3* <UI pid=F0 Len=49 >[15:41:31]
      =3144.56S/11612.23E-73' from Gidgegannup {UISS53}

      It appears to me that the last two digipeaters are reacting to an incoming WIDE3-1 when they should be ignoring it?
    • ka8nyu
      My OT3m seems to respond to any W2 packet, where I wish for it to be a one hop / fill digi as well. Any way to limit the digi portion to act as a fill / W1
      Message 2 of 6 , Jul 1, 2012
      View Source
      • 0 Attachment
        My OT3m seems to respond to any W2 packet, where I wish for it to be a one hop / fill digi as well.

        Any way to limit the digi portion to act as a fill / W1 digi only. Acting as a W2 or higher just introduces QRM.



        --- In tracker2@yahoogroups.com, "notrobbage" <vk6ufo@...> wrote:
        >
        > Something I brought up a few months back. Tell me if I'm reading this wrong. Output is from my AGWPE set-up.
        >
        > The originator is using WIDE1-1,WIDE3-2 by the looks. VK6RAV-3 is configured to digipeat WIDE3-N which it does.
        >
        > VK6RTH-3 is configured to digipeat on WIDE2 for 2 hops and VK6RN-3 is configured for WIDE1 for 1 hop.
        >
        > 1:Fm VK6MUD To CQ Via VK6RAV-3,WIDE1*,WIDE3-2 <UI pid=F0 Len=49 >[15:41:27]
        > =3144.56S/11612.23E-73' from Gidgegannup {UISS53}
        > 1:Fm VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3*,WIDE3-1 <UI pid=F0 Len=49 >[15:41:28]
        > =3144.56S/11612.23E-73' from Gidgegannup {UISS53}
        > 1:Fm VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3,VK6AHR-3,WIDE3* <UI pid=F0 Len=49 >[15:41:29]
        > =3144.56S/11612.23E-73' from Gidgegannup {UISS53}
        > 1:Fm VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3,VK6RN-3,WIDE3* <UI pid=F0 Len=49 >[15:41:31]
        > =3144.56S/11612.23E-73' from Gidgegannup {UISS53}
        >
        > It appears to me that the last two digipeaters are reacting to an incoming WIDE3-1 when they should be ignoring it?
        >
      • la5ppa
        Hi, take a look at this link http://home.ebnett.no/tt14/PDF/Path_test_OT2m.pdf On page 1 you will see how to set T2 as a Fill-In, only digipeating WIDE1-1 The
        Message 3 of 6 , Jul 1, 2012
        View Source
        • 0 Attachment
          Hi, take a look at this link
          http://home.ebnett.no/tt14/PDF/Path_test_OT2m.pdf

          On page 1 you will see how to set T2 as a Fill-In, only digipeating WIDE1-1

          The document is in Norwegian :-) but I think you will understand from the picture and raw APRS data

          --
          Lasse


          --- In tracker2@yahoogroups.com, "ka8nyu" <cmscholl@...> wrote:
          >
          > My OT3m seems to respond to any W2 packet, where I wish for it to be a one hop / fill digi as well.
          >
          > Any way to limit the digi portion to act as a fill / W1 digi only. Acting as a W2 or higher just introduces QRM.
          >
        • James Ewen
          ... There s no interaction between the last two digipeaters to cause the activity that you are seeing. Both VK6AHR-3 and VK6RN-3 are acting upon the packet
          Message 4 of 6 , Jul 1, 2012
          View Source
          • 0 Attachment
            On Sun, Jul 1, 2012 at 1:57 AM, notrobbage <vk6ufo@...> wrote:

            > The originator is using WIDE1-1,WIDE3-2 by the looks. VK6RAV-3
            > is configured to digipeat WIDE3-N which it does.
            >
            > VK6RTH-3 is configured to digipeat on WIDE2 for 2 hops
            > and VK6RN-3 is configured for WIDE1 for 1 hop.
            >
            > VK6MUD To CQ Via VK6RAV-3,WIDE1*,WIDE3-2
            > VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3*,WIDE3-1
            > VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3,VK6AHR-3,WIDE3*
            > VK6MUD To CQ Via VK6RAV-3,WIDE1,VK6RTH-3,VK6RN-3,WIDE3*
            >
            > It appears to me that the last two digipeaters are reacting to an incoming
            > WIDE3-1 when they should be ignoring it?

            There's no interaction between the last two digipeaters to cause the
            activity that you are seeing. Both VK6AHR-3 and VK6RN-3 are acting
            upon the packet with the WIDE3-1 as the requested hop, having been
            previously handled by VK6RTH-3. This is perfectly normal operation.

            The OT line simply looks at the SSID and if the SSID is less than or
            equal to the hop limit, it will be digipeated. Since the SSID in this
            request is 1, which is less than the hop limit for both digipeaters,
            both digipeaters act upon the packet individually.

            An OT unit supporting a digipeat alias of WIDE and a hop limit of 1
            will digipeat all of these requests.

            WIDE7-1
            WIDE6-1
            WIDE5-1
            WIDE4-1
            WIDE3-1
            WIDE2-1
            WIDE1-1

            Similarly, if you have a hop limit of 3, the unit will digipeat
            anything with an SSID of 3 or less and a matching digipeat alias.

            Thus: WIDEn-3, WIDEn-2 and WIDEn-1 where n can be any number will all
            be digipeated.

            Ideally, the digipeating hop limit routine should ensure that both n
            and N in the WIDEn-N digipeating hop request are less than or equal to
            the desired hop limit.

            The work around is to include the n value as part of the base alias,
            ie WIDE1 with a hop limit of 1.

            --
            James
            VE6SRV
          • Rob
            ... I suspect that s what most people expect to happen. -- Rob, VK6UFO, VK6RN
            Message 5 of 6 , Jul 1, 2012
            View Source
            • 0 Attachment
              On 02/07/12 01:53, James Ewen wrote:

               

              Ideally, the digipeating hop limit routine should ensure that both n
              and N in the WIDEn-N digipeating hop request are less than or equal to
              the desired hop limit.


              I suspect that's what most people expect to happen.

              -- 
              Rob, VK6UFO, VK6RN
            • James Ewen
              ... Unfortunately there s even less documentation on how the digipeating routines are supposed to work than there is about the packets bouncing around the
              Message 6 of 6 , Jul 1, 2012
              View Source
              • 0 Attachment
                On Sun, Jul 1, 2012 at 3:54 PM, Rob <vk6ufo@...> wrote:

                > On 02/07/12 01:53, James Ewen wrote:
                >
                > Ideally, the digipeating hop limit routine should ensure that both n
                > and N in the WIDEn-N digipeating hop request are less than or equal to
                > the desired hop limit.
                >
                > I suspect that's what most people expect to happen.

                Unfortunately there's even less documentation on how the digipeating
                routines are supposed to work than there is about the packets bouncing
                around the network.

                As such, people are making things up as they go. UIFLOOD and UITRACE
                digipeating was first introduced on the Kantronics line of TNCs, and I
                use them as the baseline as to how the functions SHOULD work. There
                are some issues with the routines in the Kantronics, but we have a
                really good idea of HOW the routines were INTENDED to work.

                There are some extensions of the functionality being introduced, but
                the fundamental functionality needs to be uniform across all
                implementations of digipeating.

                That's not the case though. Each implementation has a slight
                variation, or anomaly, which I have been pushing to get "corrected" so
                that they all work the same. I've been after Scott to make some
                changes, I've gotten Byon to correct an issue in the TT4, and I'm also
                working with Lynn to modify the digipeating implementation in his
                program.

                I'm also working with Lynn on documenting issues in the Kenwood line as well...

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