| |
ZL3AI > APRDIG 04.10.03 11:18l 262 Lines 9886 Bytes #999 (0) @ WW
BID : 2081-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 01, 6/11
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL3VML
Sent: 031003/1359Z @:ZL3VML.#80.NZL.OC #:9641 [Chch-NZ] FBB7.00i $:2081-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: The new APRS n-N paradigm
From: Gary Hinton <ghinton@eng.mcd.mot.com>
Date: Wed, 01 Oct 2003 10:49:39 -0700
X-Message-Number: 33
In Arizona, we have 445.925 assigned for APRS.
Gary AC7R
+--------------------------------------------------------------------+
| Gary Hinton AC7R Phone: (602) 438-3450 |
| GTAC FAX: (602) 438-5627 |
| Motorola Computer Group Pager: 877-992-6630 (two-way) |
| 2900 S. Diablo Way e-mail: ghinton@eng.mcd.mot.com |
| Tempe, Arizona 85282 Mail Drop: DW185 |
+--------------------------------------------------------------------+
----------------------------------------------------------------------
Subject: RE: Random backoff
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 01 Oct 2003 19:54:57 +0200
X-Message-Number: 34
At 10:28 1-10-03 -0400, Bob Bruninga wrote:
>Sorry, I stand by my post that we must have DWAIT of 0 in all DIGIS and
>SLOT/PERSIT must be disabled.. You are correct, that SLOT and PERSIT
Okay, you are focused too much on TAPR type TNC implementations. KISS
doesn't have DWAIT nor a method to switch the PERSIST method off. None of
the other types of modems/solutions like BayCom, SCC cards, PicPar, PAR96
and you name it have this obsolete DWAIT method. Also AGWPE does not have
it and I don't recall ever having seen this type of setting in any of the
NOS versions. Linux also only supports the Persist method and nothing else.
Other firmware like TheFirmware also only has Persist and if I'm correct so
does UIDIGI. There is no way to "switch SLOT/PERSIST off" and it doesn't
make sense. DWAIT is obsolete and depricated, nobody should use it.
That being cleared once and for all I hope, you can still accomplish
COMPLETELY what you want and I think it would make more sense in putting
your effort to propagate those settings among the users.
The *100%* equivalent of DWAIT=0 is PERSIST=255 and SLOTTIME=0. That will
do *EXACTLY* the same thing as you try to accomplish with DWAIT=0, but uses
parameters available on all existing TNC and modem implementations without
exception.
Like I tried to say before there is even a better way than tweaking those
channel access parameters. Just "lie" to the TNC and configure it for
full-duplex. The TNC will then completely disregard any carrier and starts
transmitting without any delay on any received packet.
Note that I am not in favour of this at all. I'm just trying to explain
that you can set PERSIST and SLOTTIME such way that they behave exactly the
same as DWAIT=0 and *if* you want to do this, changing PERSIST and SLOTTIME
is the only right way to do it. Leave DWAIT alone as a historic artifact
present in a few specific TNC commandline implementations for backward
compatibility.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Correctly IDing weather stations
From: "Michael J. Wolthuis" <wolthui3@msu.edu>
Date: Wed, 1 Oct 2003 14:05:07 -0400
X-Message-Number: 35
Group,
I need some advice. In my location here we have a lot of weather
stations on APRS, but the mycall is set up to their county identifier.
Thus they are not TXing their callsign on their weather data transmit.
To rectify this we originally set the ID timer the same as the timer for
the weather data via Kantronics BLT and BE e timers.
However, this extra beacon is using up way to much valuable air space.
So, I have two ideas and need advice which is legal or are both legal
and which is best?
1) We can ID the transmitters like a repeater every 10minutes, but then
there is no ID except their county ID on the weather transmission. I
don't care, but I want it to be legal.
2) What if I set the unproto of the weather data instead of WX VIA
WIDE,WIDE to MYCALL VIA WIDE, WIDE (ie. KB8ZGL VIA WIDE,WIDE) Now I have
IDed the transmission in the weather data string and I have left the
county identifier intact as a tactical callsign.
Which is best, please save me the armchair lawyering, I want to be legal
and efficient.
Mike
Kb8zgl
----------------------------------------------------------------------
Subject: Re: Digipeater Duplicate Checking is broke
From: Bruce Gordon <bgordon@rain.org>
Date: Wed, 01 Oct 2003 11:19:00 -0700
X-Message-Number: 36
Scott,
A FIXED station, in the unlikely situation of a near balance, could use
a simple beam or even move the antenna a few feet to resolve the
matter. I wish that were the only problem.
Bruce Gordon N6OLT
Scott Miller wrote:
>
>>1) there will always be some collisions.
>>2) There will always be some success from DIGI A just about everywhere
>>3) There will always be some success from DIGI B just about everywhere
>
>I guess I'm not following how this is supposed to work. You've got two
>digis equidistant from a fixed station. Both digis have zero DWAIT. A
>mobile somewhere between them is picked up by both digis, and digipeated at
>the same time, give or take a 200 msec in TXD difference. The fixed station
>has a pretty constant multipath situation. How does it ever see ANYTHING
>from EITHER digipeater?
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: Silk Purses
From: "Georgette Sampson" <georgette.sampson@cox.net>
Date: Wed, 1 Oct 2003 13:10:44 -0500
X-Message-Number: 37
The Sow's ear of packet radio since its first use (not just an APRS
problem), is the continuing lack of interest in a quality signals.
Almost every tracker has instructions on how to set the audio levels, even
if you don't have a $20 deviation meter.
If you are serious about enjoying Ham Radio, then set your deviation.
After listening to the local area for just a couple of days, I think APRS
signals can improve in more than 50% of the users.
----------------------------------------------------------------------
Subject: Re: Correctly IDing weather stations
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Wed, 1 Oct 2003 14:20:51 -0400
X-Message-Number: 38
>1) We can ID the transmitters like a repeater every 10minutes, but then
>there is no ID except their county ID on the weather transmission. I
>don't care, but I want it to be legal.
First off, can I ask why you appear to be under the impression that you
have to have a ham call as ID in every transmission?
Mike
----------------------------------------------------------------------
Subject: Re: Correctly IDing weather stations
From: "Spider" <spider@rivcom.net>
Date: Wed, 1 Oct 2003 11:44:22 -0700
X-Message-Number: 39
From: "Michael J. Wolthuis" <wolthui3@msu.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Wednesday, October 01, 2003 11:05 AM
Subject: [aprssig] Correctly IDing weather stations
>Group,
>I need some advice.
Why not put the callsign in the LT buffer along with the coordinates...in
the comment.
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: Correctly IDing weather stations
From: WA8LMF2@aol.com
Date: Wed, 1 Oct 2003 15:09:06 EDT
X-Message-Number: 40
In a message dated 10/1/2003 11:12:13 AM Pacific Daylight Time,
wolthui3@msu.edu writes:
>2) What if I set the unproto of the weather data instead of WX VIA
> WIDE,WIDE to MYCALL VIA WIDE, WIDE (ie. KB8ZGL VIA WIDE,WIDE) Now I have
> IDed the transmission in the weather data string and I have left the
> county identifier intact as a tactical callsign.
1) Is it going to occur to anyone (including the FCC??) that the
destination call sign in the path is actually that of the sending
station???
2) It will just about guarantee that the signals won't get digipeated or
igated, since standard digi and igate software looks for a very specific
range of destination addresses (mostly beginning with CQ, APxxxx and a few
others).
(But then again, maybe that would be a worthwhile way of reducing channel
congestion! )
----------------------------------------------------------------------
Subject: FIX APRSdos RELAYS
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 1 Oct 2003 15:52:33 -0400 (EDT)
X-Message-Number: 41
CLEANING up RELAY:
To lead in the FIXING of 144.39, here is how ALL people that are still
running APRSdos need to configure their systems to GET RID of un-needed
RELAYS:
Unless your HOME station running APRSdos is a necessary part of your LAN
where your station is needed as a RELAY-FILL digi for mobiles, then you
need to disable the MYALIAS of RELAY in your TNC.
Another test. If mobiles in the vicinity of your HOME station can also
hit another full service RELAY, then you should not be enabled as a RELAY
fill station.
The following change will precent APRSdos from initializing your TNC with
the myalias of RELAY. Look in your ROOT directory on your C drive for the
CFIG843.xxx configuration file. Look about half way down for this entry:
999,-99,99,99,0,1024
"RELAY",43,""
Now EDIT the word "RELAY" to "none" and resave the file.
To be SAFE, make a backup copy first. Sometimes different text editors
screw up the exact file and you dont want to have that mess up your
APRS program. If you ever re-start APRS NEW and then save a
NEW-from-scratch CFIG file, you will have to do this manual change again.
If your AREA DOES need your home station to be a RELAY, then you should
upgrade your TNC to either a recent Paccomm or a recent Kantronics so that
your TNC will do callsign substitution on any packets it does handle as a
RELAY fill-in digi. To do this, simply talk to your TNC and have it save
the parameter of "RELAY" to its UIDIGI list.
de WB4APR@amsat.org, Bob
FIXING 144.39 http://www.ew.usna.edu/~bruninga/aprs/fix14439.html
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
