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!"
