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

Re: [tracker2] Dropping WIDE3-n (and above) from a WIDE2-2 digi

Expand Messages
  • James Ewen
    ... Can you post the digipeater settings used to accomplish this? I haven t found a way to do that yet. ... With HOPS 0, it should not digipeat WIDE1-1, as the
    Message 1 of 7 , Oct 20, 2011
    • 0 Attachment
      On Thu, Oct 20, 2011 at 6:38 AM, notrobbage <vk6ufo@...> wrote:

      > We have a few local T2 digis set with alias "WIDE"
      > and hops "2". These digis still digipeat "WIDE3-n"
      > and "WIDE4-n" etc, but end their miserable lives
      > as "WIDE3*" and "WIDE4*"  etc, which is the normal
      > result by all accounts.

      Can you post the digipeater settings used to accomplish this? I
      haven't found a way to do that yet.

      > I plan to have my own fill-in digi set as "WIDE1" and
      > hops "0" so only "WIDE1-1" are digipeated and any
      > other WIDEn are ignored completely.

      With HOPS 0, it should not digipeat WIDE1-1, as the hop request is
      greater than 0.


      > As far as I've been able to find out, that's how it should
      > work . I wonder can the same with be done with a
      > WIDE2-2 digi so WIDE >= 3 just stop dead?

      I had been futzing with that to try and get the digipeater to only act
      upon WIDE2-2 and less, but have not been successful. However you
      statement above indicates that the OT2 units in your area are
      successfully trapping WIDE3-N and WIDE4-N paths.

      > I was guessing two aliases
      >
      > "WIDE1" 0 hops
      > "WIDE2" 1 hops

      That should make it so the unit will only respond to WIDE2-1 as a
      digipeat request.

      I played with putting a numerical value after the WIDE and setting hop
      limits equal to the numeric suffix in order to try and stop WIDEn-N
      digipeat requests from being acted upon where the n value is larger
      than the HOP limit. As it stands, the HOP limit only looks at the N
      value when determining whether it is below the HOP limit request. As
      such, with a HOP limit of 2, a digipeat request of WIDEn-2 with n
      being any value between 1 and 7 will be acted upon. This means that
      packets that have been handled by non-HOP limiting digipeaters from
      far away can end up being propagated across the local network that is
      trying to limit exessive hop request packets.

      --
      James
      VE6SRV
    • Lynn W. Deffenbaugh (Mr)
      ... Not really. Read it carefully. He says that they end their miserable lifes as WIDE3* and WIDE4* which to me implies that they actually DID get 3
      Message 2 of 7 , Oct 20, 2011
      • 0 Attachment
        On 10/20/2011 12:54 PM, James Ewen wrote:
        > On Thu, Oct 20, 2011 at 6:38 AM, notrobbage<vk6ufo@...> wrote:
        >> We have a few local T2 digis set with alias "WIDE"
        >> and hops "2". These digis still digipeat "WIDE3-n"
        >> and "WIDE4-n" etc, but end their miserable lives
        >> as "WIDE3*" and "WIDE4*" etc, which is the normal
        >> result by all accounts.
        > Can you post the digipeater settings used to accomplish this? I
        > haven't found a way to do that yet.

        > However you
        > statement above indicates that the OT2 units in your area are
        > successfully trapping WIDE3-N and WIDE4-N paths.

        Not really. Read it carefully. He says that they "end their miserable
        lifes as "WIDE3*" and "WIDE4*"" which to me implies that they actually
        DID get 3 and 4 hops out of the original 3-3 or 4-4 specification. He
        wants to trap them, but they're not trapping now.

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
      • James Ewen
        On Thu, Oct 20, 2011 at 11:13 AM, Lynn W. Deffenbaugh (Mr) ... Trapping the excessive paths using digined or other rule based software can have them
        Message 3 of 7 , Oct 20, 2011
        • 0 Attachment
          On Thu, Oct 20, 2011 at 11:13 AM, Lynn W. Deffenbaugh (Mr)
          <ldeffenb@...> wrote:

          > Not really.  Read it carefully.  He says that they "end their miserable
          > lifes as "WIDE3*" and "WIDE4*"" which to me implies that they actually
          > DID get 3 and 4 hops out of the original 3-3 or 4-4 specification.  He
          > wants to trap them, but they're not trapping now.

          Trapping the excessive paths using digined or other rule based
          software can have them immediately decremented to a -0 path element as
          well.

          Ending their miserable lives implies they are killed, not just dying
          after fulfilling their life's destiny!

          They are ugly any way you put it! (Of course we use WIDE3-3 around
          here to try and traverse the network far enough to get to another
          human being.)

          --
          James
          VE6SRV
        • Rob
          ... As above, an alias of WIDE and hops set to 2 . An incoming WIDE3-3 for example will go back out as a WIDE3* Similar with my current fill-in. I have
          Message 4 of 7 , Oct 20, 2011
          • 0 Attachment
            On 21/10/11 00:54, James Ewen wrote:  

            On Thu, Oct 20, 2011 at 6:38 AM, notrobbage <vk6ufo@...> wrote:

            > We have a few local T2 digis set with alias "WIDE"
            > and hops "2". These digis still digipeat "WIDE3-n"
            > and "WIDE4-n" etc, but end their miserable lives
            > as "WIDE3*" and "WIDE4*"  etc, which is the normal
            > result by all accounts.

            Can you post the digipeater settings used to accomplish this? I
            haven't found a way to do that yet.

            As above, an alias of "WIDE" and hops set to "2". An incoming "WIDE3-3" for example will go back out as a "WIDE3*"
            Similar with my current fill-in. I have an alias of "WIDE" and hops set to "1". An incoming "WIDE2-2" gets digipeated as "WIDE2*"
            So they already do it by default.

            I want my fill-in to stop doing it, which is what I'm hoping an alias of "WIDE1" and hops "0" will do (which is different than "WIDE" and hops "0"). I found the information on the T2 group.


            I had been futzing with that to try and get the digipeater to only act

            upon WIDE2-2 and less, but have not been successful. However you
            statement above indicates that the OT2 units in your area are
            successfully trapping WIDE3-N and WIDE4-N paths.

            Not exactly. The "WIDE3*" or "WIDE4*" still goes to air.  Other digis will ignore if there no more path but it all still uses bandwidth.

            Either way I'll give the "WIDE1" with hops "0" a go shortly and see what happens.

            It would probably make more sense to T2 users to have another checkbox in the digipeater config which says something like "ignore this alias when n is greater than hops" or something to that effect.

            -- 
            Rob, VK6UFO, VK6RN
          • James Ewen
            ... What firmware version are you running? I haven t seen that action. I d like to play with it and see what s happening. ... Some feel that these paths over
            Message 5 of 7 , Oct 20, 2011
            • 0 Attachment
              On Thu, Oct 20, 2011 at 4:11 PM, Rob <vk6ufo@...> wrote:

              > As above, an alias of "WIDE" and hops set to "2". An incoming "WIDE3-3" for example
              > will go back out as a "WIDE3*" Similar with my current fill-in. I have an alias of "WIDE"
              > and hops set to "1". An incoming "WIDE2-2" gets digipeated as "WIDE2*"

              What firmware version are you running? I haven't seen that action.

              I'd like to play with it and see what's happening.


              > However you
              > statement above indicates that the OT2 units in your area are
              > successfully trapping WIDE3-N and WIDE4-N paths.
              >
              > Not exactly. The "WIDE3*" or "WIDE4*" still goes to air.  Other digis will ignore
              > if there no more path but it all still uses bandwidth.

              Some feel that these paths over the hop limit should be given a single
              hop as a courtesy, rather than totally ignoring the packet. Ignoring
              the packet might make the operator look at the reason for lack of
              digipeating of their packets. I had to take down the main digipeater
              here in Edmonton for about a week as we shut down one site, and moved
              it to another site. Only one other user noticed the digipeater
              missing, and that's because the two of us are constantly monitoring
              the network and are actively working on expanding the network. Most
              user are simply fire and forget dumb trackers, and if they do look at
              the network it's via the web, and since there are 5 i-gates in the
              area, there's no indication of anything amiss. Of course if you
              listened and watched on RF, you would have seen noticed a dearth of
              packets on air.

              > It would probably make more sense to T2 users to have another checkbox
              > in the digipeater config which says something like "ignore this alias when n
              > is greater than hops" or something to that effect.

              No, we've been around that bush a few times. The firmware checks the
              SSID numeric value only, that's the N portion of the WIDEn-N hop
              request. With a HOP limit of 2, WIDE3-3 won't get acted upon, but
              WIDE3-2 and WIDE3-1 would because the SSID N value is less than the
              HOP limit.

              There might be a newer version of firmware available that has a change
              to the digipeater logic than what I am running though.

              --
              James
              VE6SRV
            • Rob
              ... The current one that the GUI downloads. Just to be sure I confirmed this morning that my fill-in was definitely digipeating incoming WIDE2-2 and WIDE2-1 as
              Message 6 of 7 , Oct 21, 2011
              • 0 Attachment
                On 21/10/11 09:22, James Ewen wrote:  

                On Thu, Oct 20, 2011 at 4:11 PM, Rob <vk6ufo@...> wrote:

                > As above, an alias of "WIDE" and hops set to "2". An incoming "WIDE3-3" for example
                > will go back out as a "WIDE3*" Similar with my current fill-in. I have an alias of "WIDE"
                > and hops set to "1". An incoming "WIDE2-2" gets digipeated as "WIDE2*"

                What firmware version are you running? I haven't seen that action.


                The current one that the GUI downloads. Just to be sure I confirmed this morning that my fill-in was definitely digipeating incoming WIDE2-2 and WIDE2-1 as WIDE2*. After changing the alias "WIDE" with hops "1" to alias "WIDE1" with hops "0", it would only digipeat on incoming WIDE1-1 and no other WIDE.

                Some feel that these paths over the hop limit should be given a single
                hop as a courtesy, rather than totally ignoring the packet.

                Yes. It probably depends on the location and amount of traffic. We have low traffic compared to other cities in Australia and very low compared to US and Eu cities so it probably doesn't matter much right now.


                No, we've been around that bush a few times. The firmware checks the
                SSID numeric value only, that's the N portion of the WIDEn-N hop
                request. With a HOP limit of 2, WIDE3-3 won't get acted upon,


                But it apparently does act, which is the point. The operator should have the option to not act if they require it and it's not evident in the GUI. As a fill-in I would like mine to create as little disturbance as possible but still catch mobile stations for the hole I'm filling. "WIDE" and hops "1" creates too much pointless traffic.

                I know which digipeaters in my area beacon and/or digipeat on WIDE3-n so I will monitor the on-air traffic and see if I can capture what is occurring.
                -- 
                Rob, VK6UFO, VK6RN
              Your message has been successfully submitted and would be delivered to recipients shortly.