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

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

Expand Messages
  • James Ewen
    Oct 20, 2011
      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.

    • Show all 7 messages in this topic