[aprssig] KPC-3 8.2 settings
Keith - VE7GDH
ve7gdh at rac.ca
Mon Aug 22 00:22:47 CDT 2005
Ed KF4CHG wrote on 21/08/2005
(after I said...)
>> I disagree with entering a setting of WIDEN-N=TRUE. I don't think Arte was
>> trying to enable WIDEn-n digipeating - just to get it to respond to
> Well sorry to say but, it is WIDEN-N=TRUE. This makes UI-View give
> state or ARRL support. Cut and paste the following into your
> uiview32.ini then restart UI-View go to Digipeater Setup. Then come
> back and tell me what you see. Where ALIAS= make UI-View respond ONLY
> to the path entered. VE7GDH-10 has to be in the ALIAS list so long as
> ALIAS_SUBSTITUTION=TRUE and SUBST_ALIAS=VE7GDH-10. This is done so when
> UI-View hears an RF path of WIDE1-1 it will been be digipeated back out
> as VE7GDH-10,WIDE*. So if you do the Cut & Paste thingie and run it for
> awhile while monitoring the terminal window, you'll see that it works.
Small change... VE7GDH is on a laptop with a TCPIP connection only. No RF connection unless I'm working on something. I looked over the above settings, but didn't enter them verbatim. I am running VE7GDH as a both a WIDEn-n digipeater and an IGate at about 165M or about 541.365 feet ASL. However I did change the uiview32.ini file as follows:
The only real change is that I changed UITRACE to BC (I wasn't responding to TRACEn-n or BC-n-n previously) and I now have TRACEn-n=TRUE. Previoiusly I was disabled. For my station (IGate and medium level digipeater) I want it to respond to WIDEn-n ---- not just to WIDE1-1. At some point in time, I will get a stand-alone digi going here or nearby. When that happens, I will change over to being an IGate only.
I do see now that the settings that you suggested would change Arte's digipeater to respond to WIDE1-1 and it would also change UIFLOOD from WIDE to NY so he would respond to SS-n-n and not WIDEn-n. Like I said, I'm willing to shoot myself in the foot if it will help. If I'm wrong, I think that I have helped people (including myself) to see how to set a UI-View digi up for WIDE1-1 and SSn-n. If I'm right, my response to Arte was how to set it up with call sign substitution and to respond to WIDE1-1 only and to not respond to TRACEn-n. Under your suggestions the WIDEn-n was replaced by SSn-n. My modification to your suggested settings (see above) will still have me respond to WIDEn-n as I did before (not just WIDE1-1 that your settings would have done) and (I am hoping) that my changes will replace TRACEn-n (that I wasn't using before) with SSn-n (being BCn-n in my case).
I haven't done any tests to see if any other digis in the area respond to BCn-n, but in my case (meaning my location) I don't think that it hurts to have that setting in there... that is if the way I actually set it up gets it to treat BCn-n the way it would have originally handled TRACEn-n if I actually had it enabled previously.
Just got back from a bike ride and did the changes as above. I'll watch the terminal window later or probably in the morning. Going for supper before it disappears from the table!
> This is also per Bob Bruninga, WB4APR:
> "HANDLING THE UNIVERSAL ONE-HOP PATH (which used to be RELAY): Some
> areas may still need some FILL-IN small valley digis to help mobiles in
> some areas. These used to be RELAY digis, but these generated very bad
> DUPE situations. Instead RELAY is now obsolete and has been replaced
> with simply WIDE1-1. If a FILL-IN digi is needed, give it the alias of
> WIDE1-1 instead of RELAY and those local mobiles that need to use it can
> use the mobile path of WIDE1-1,WIDE2-1. This gets them 2 hops either
> through the FILL-IN digi or via any other digis as well. But because the
> path is exclusively WIDEn-N based, then the WIDEn-N perfect dupe
> elimination process works."
That's true, but irelevant at least to your arguement as I see it. If anything, Bob's statement seems to back up what I originally suggested to Arte. Whether someone is wrong or right really comes down to how we interpret what Arte's wanted to do, and whether he really should be responding to SSn-n. Ether way, it has probably made a few people (myself included) think a bit more about the digi settings!
> Oh, by the way before I forget here is what Arte quoted:
> "In the ancient practice of acting as a fill-in digi, I've had my KPC-3
> Plus v8.2 acting as RELAY. It is now, however, in KISS mode using the
> last version of UI-View. In light of the "New WideN-N Paradigm" I want
> to comply with current recommendations, yet see the need for continuing
> to act as a fill-in digi."
> So I would interpret this as he wanted information on how to setup a
> Fill-In digipeater.
> Arte, correct us at anytime on this to be or not to be a Fill-In digipeater.
I interpreted Arte's request as a wish to have UI-View run as a "fill-in" digipeater, meaning responding to WIDE1-1 - not to WIDEn-n. I think where we are differing is the advise that you were giving Arte was to get it to respond to WIDE1-1, to respond to SS-n-n instead of WIDEn-n. I think that setting it up "per the book" responding to WIDE1-1 with callsign substitution is a completely different kettle of fish than setting it up to change the meaning of WIDEn-n to SSn-n. I would further question if Arte's station is a "home fill-in" digi, should it be responding to SSn-n? I would think that should be the task of digipeaters that are otherwise "high level" (or at least in my case, medium level) WIDEn-n digipeaters.
Just to comment further on my original response to the note you posted to Arte... your settings will work and have him respond to WIDE1-1. What I missed or didn't understand before was that your suggested settings would add SSn-n support to Arte's digipeater. Even though I missed that before, do you think that all "home fill-in" digis should respond to SSn-n, or should it just be digis that are at a higher elevation?
73 es cul - Keith VE7GDH
"Still willing to shoot myself in the foot in the cause of APRS if it will help!"
More information about the aprssig