Re: [[tracker2] SET UP DIGIPEATER ???HELP PLEASE
- 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.
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
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!"