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

Re: [[tracker2] SET UP DIGIPEATER ???HELP PLEASE

Expand Messages
  • Keith VE7GDH
    This could probably be renamed stupid digipeating tricks or something like that, but... I know others have put the OT2m and its cousins through its paces
    Message 1 of 2 , May 20, 2010
      This could probably be renamed "stupid digipeating tricks"
      or something like that, but... I know others have put the OT2m
      and its cousins through its paces previously, but I just finished
      messing around with one trying out various digi settings.

      First, for my tests, I stayed on 144.390 so I could keep track of what
      was going around me, and used WIDEE (note the extra E) for the digi
      alias so my sometimes frequent beacons wouldn't cause too much
      QRM. The digi was just going in to a rubber duck, so it's unlikely
      that anyone except myself heard those packets. In the examples
      below, I'll use the standard "WIDE" and not the "WIDEE" that I
      used for QRM limiting.

      ALIAS 1 WIDE
      USEALIAS 1 ON
      HOPLIMIT 1 1

      It would respond to a path of WIDE1-1, sending it back out with a path
      of WIDE1* indicating that it was all used up. However, it would also
      respond to WIDE2-2, WIDE3-3, WIDE4-4 (you get the picture) and the
      digipeated packet would have a remaining path of WIDE2-1, WIDE3-1,
      WIDE4-1 etc. It also responded to a stupid path of WIDEE9999999999-1
      kicking it out the other side with a path of WIDE9-1 still available.
      still available.

      I then tried the following...

      ALIAS 1 WIDE1
      ALIAS 2 WIDE2
      HOPLIMIT 1 1
      HOPLIMIT 2 2
      USELIAS 1 ON
      USEALIAS 2 ON

      It responded to WIDE1-1, but sent it out as mycall* (whatever callsign
      was in the OT2m) indicating the path was used up, and showing the callsign
      of the digi, but not showing what the original path might have been. It also
      responded to WIDE2-1 again sending it back out as mycall* indicating the
      path was used up, and identifying the digi, but not what the original path
      might have been. It did the same for WIDE2-2. My conclusion was that it
      couldn't act properly responding to both WIDE1-1 and WIDEn-N types
      of paths at the same time. Let's see if I can prove that.

      ALIAS 1 WIDE
      HOPLIMIT 1 2
      USEALIAS 1 ON

      It responded to WIDE1-1 sending it back out as mycall*,WIDE1*
      indicating that the original path was (likely) WIDE1-1 but all used up,
      and it identified the digipeater. Basically, it acted like a fill-in digi.

      It also acted like a WIDEn-N digi (as expected) when I used a path of
      WIDE2-1, sending it back out showing that the path was used up,
      and then to WIDE2-2, sending it back out showing that WIDE2-1 was
      still available.

      However, it also responded to WIDE3-3 sending it back out with a
      remaining path OF WIDE3-1. Basically, it digipeated the beacon, and
      sent it on its way but only allowing one more hop even though the
      original beacon asked for 3 hops. I could have carried on with all the
      variations, but I jumped to WIDE7-7 and it did as I expected, sending
      it on its way with WIDE7-1 still being available.

      In many places, I can see this as being a good thing. However, unless the
      digi was specifically set up to allow 7 hops, it would always send it on
      its way with only one digi hop remaining if HOPLIMIT was set to 2.

      If anyone wants to look, the station sending the test beacons was
      VE7GDH-10 and the digi was VE7PGE-2.

      Does anyone think that the T2 based digi should operate otherwise?
      e.g. only respond to WIDE1-1 or WIDE2-1 or WIDE2-2 with last
      lot of settings that I quoted above, and not respond to e.g. WIDE7-7
      at all instead of sending it back out with WIDE7-1 still available?

      Scott - if it is deemed that it would it be desirable to make a change,
      would it be easy to do, or are you limited by code space? In a way,
      it enforces reasonable settings, but the only way to get long paths
      through it would seem to be to have SSn-N enabled with a hoplimit
      of 7. Perhaps the current settings are already the best that can be done,
      but having tried all of the above, I thought that I would throw it out
      there for discussion.

      73 es cul - Keith VE7GDH
      --
      "I may be lost, but I know exactly where I am!"
    Your message has been successfully submitted and would be delivered to recipients shortly.