| |
ZL3AI > APRDIG 25.01.04 07:17l 237 Lines 11404 Bytes #999 (0) @ WW
BID : 2711-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jan 21, 1/3
Path: DB0FHN<DB0FOR<DB0MRW<OK0PKL<OK0PPL<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 040125/0502Z @:ZL3VML.#80.NZL.OC #:17523 [Chch-NZ] FBB7.00i $:2711-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, January 21, 2004.
1. Re: Attended vs Unattended
2. HF Extended Coverage
3. RE: HF Extended Coverage
4. IGates, Excessive RF Traffic, & Inet/RF Combo Stations
5. Re: IGates, Excessive RF Traffic, & Inet/RF Combo Stations
6. RE: HF Extended Coverage
7. Getting thru a proxy server???
8. Re: Getting thru a proxy server???
9. Re: Getting thru a proxy server???
10. Re: SAPPHIRE (NO-45) pass
11. Re: SAPPHIRE (NO-45) pass
12. Re: HF Extended Coverage
13. Re: Getting thru a proxy server???
14. Re: Getting thru a proxy server???
15. Everyone should read this if in USA
16. RE: HF Extended Coverage
17. Re: IGates, Excessive RF Traffic, & Inet/RF Combo Stations
18. Onstar
19. Re: Onstar
----------------------------------------------------------------------
Subject: Re: Attended vs Unattended
From: <hgerhardt@charter.net>
Date: Wed, 21 Jan 2004 5:23:48 +0000
X-Message-Number: 1
Yes, a home station which is on 24/7, does serve a purpose if it is set up
correctly. It should act as a digi responding only to RELAY to pick up the
weaker mobile and hand trackers in the area and then retransmitting them
with a better antenna into a wide digi. This increases the possibility of
a small tracker to make it into our APRS system.
Of course if you are in a city and have a home station on every corner,
then there will be overkill and maybe the local stations want to get
together to see who will remain on 24/7 and who will shut down when they
are not playing. Of course that would require coordination between
agreeable parties. Silly me, how could I think something like that could
ever happen. Hi, hi....
In our part of the country in the rural areas where I live, I don't think
we could have too many stations on the air to respond to RELAY but that too
can change as APRS gets more popular every day. When I first started in
the mid 90's, we had around 25 stations on the screen on our entire NW APRS
Network. Now look at us, everyone has over 200 stations on their screen
and we have reduced our path down to TRACE2-2 and recommend that home
stations transmit no more often than every 30 minutes!
By the way, I run WinAPRS and use the restore.tnc file which automatically
reconfigures my TNC to keep my APRS station operating when my computer is
shut down. When that is the case, my Beacon Text states "Computer
Off-Line".
Herb, KB7UVC
NW APRS Group, West Sound Coordinator
Our WEB Site: www.nwaprs.org
----------------------------------------------------------------------
Subject: HF Extended Coverage
From: Glenn Wiebe <gswiebe@mb.sympatico.ca>
Date: Wed, 21 Jan 2004 10:40:57 -0600
X-Message-Number: 2
I use WinAPRS 261 & a Kam to operate a 30m/2m gateway station. I live in
an area with a limited number of APRS users. With the aid of a local
UI-DIGI digipeater we can access a metropolitan area some 30 miles away.
Many HF APRS stations use an Unproto of gate,wide or echo,gate,wide
though some use wide2-2. Wide,wide or wide2-2 would be more suitable for
me. Perhaps there are other locations where wide,wide would be more
suitable, I don't know. Unless there are some downsides to this, I
suggest all HF users consider using wide,wide. Or is there a way I can
'jigger' UI-DIGI to do this for me?
73 de Glenn...VE4GN
----------------------------------------------------------------------
Subject: RE: HF Extended Coverage
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Wed, 21 Jan 2004 11:45:52 -0500
X-Message-Number: 3
WIDE,WIDE or WIDE2-2 won't work on HF. There aren't any WIDEs on HF. The
only paths that are valid on HF are ECHO and GATE. ECHO is equal to RELAY
on the VHF world. GATE will turn the signal into VHF at the Gateway
stations.
Now, GATE,WIDE2-2 or GATE,WIDE,WIDE would work well because the WIDEs would
be executed on the VHF network.
73s,
Eric KF4OTN
----------------------------------------------------------------------
Subject: IGates, Excessive RF Traffic, & Inet/RF Combo Stations
From: "Phil Pacier, AD6NH" <ad6nh@arrl.net>
Date: Wed, 21 Jan 2004 10:51:27
X-Message-Number: 4
Hello folks. I've been working on this for about a year now trying to
figure it out. I have noticed a problem, and perhaps some of you have
noticed it as well. It has to do with stations that transmit on both the
internet and the RF channel (we'll call these combo stations in this
letter). In short, IGates are duplicating messages on RF converstations
that are taking place between two combo stations on the internet. Here's
the scenario:
AD6NH operates on both RF and the Internet. I send weather beacons on both
channels using the same callsign (as many or most combo stations do). The
N6EX-3 IGate sees my RF beacons and considers me local for gating. Now, I
start having a conversation with KB7ZVA-1 or K7ACS or anyone else by
utilizing the "I" internet channel. I started noticing my TNC transmitting
a whole lot of packets when I would have these internet conversations, so I
started looking at the packets. I found that the N6EX-3 IGate, which
remember sees me local, was sending me the same packets over RF that
KB7ZVA-1 was sending me over the internet. What was happening was,
KB7ZVA-1 would send me a message over the internet, and I would hear it
right away, but so would N6EX-3. Since the IGate thought I was local and
(here's the key) had NO knowledge that I had acked the message over the
'net, it sent the message over RF. This caused my station to send a
duplicate ACK over RF, even though I had already sent one over the
Internet. This is a huge problem!
Many stations that utilize the internet believe that they are conserving RF
bandwidth, and therefore have more lengthy conversations than they would on
RF (myself included). This is not the case! And it is happening with
every IGate and terminal software out there. The problem is, IGates
currently have no way to differentiate between stations that are RF only
and need gating, and stations that have internet ability and don't need RF
gating. If we were to solve this problem, I would almost be willing to bet
we could cut RF traffic, particularly in metro areas, by some 30%. Many
folks now have stations that make use of both the internet and the RF
channel. My experiments have shown that currently, the RF channel is still
being utilized during Internet to Internet conversations!
I see three possible fixes. The first two would be on the user (client)
end. Either use a separate callsign for RF and Internet, or have a toggle
switch that inserts something into the path (such as NORF) to tell the
IGates not to gate these messages to RF. I personally don't like these
first two choices, because it requires the client to figure out what is
going on. If I'm having simultaneous conversations with RF and Internet
stations, I would have to consistently toggle NORF on and off. Using
separate callsigns also creates more confusion, particularly for WX
stations that send data to both the RF and the Internet. The third
solution would be to have the IGates be able to decipher when a station
that is in their local list is present on the 'net. This, in my opinion,
is the best solution, because once the changes were made in the IGate
software, clients wouldn't have to make any changes. IGates currently keep
a list of stations that they consider local to them, and these are the
recipients of gated traffic. If the gate were to detect the same callsign
with a TCPIP header, it would simply drop them from the list for x amount
of time (this could be a sysop paramater, 30 or 60 minutes or whatever).
Remember, if I'm a client and I'm connected to the internet, I do not need
any IGate to send me any messages via RF - I'm going to see all messages
addressed to me from wherever in the world! I'm sure it would add a little
overhead to the IGate programs, but I believe this fix is absolutely
necessary to ensure the continuing survival of the RF bandwidth.
Bottom line, there is a lot of unnecessary RF usage taking place due to
this problem. Perhaps I'm not the first one to point it out, but I would
like to see the major IGate software authors implement some sort of fix
like the one I described. When I start having internet conversations, the
LA LOAD traffic monitor jumps sometimes to 470 packets in 10 minutes - half
of which are unnecessary IGate packets. Thanks for listening.
73
Phillip Pacier - AD6NH
http://www.aprsca.net
----------------------------------------------------------------------
Subject: Re: IGates, Excessive RF Traffic, & Inet/RF Combo Stations
From: "Curt, WE7U" <archer@eskimo.com>
Date: Wed, 21 Jan 2004 09:11:22 -0800 (PST)
X-Message-Number: 5
On Wed, 21 Jan 2004, Phil Pacier, AD6NH wrote:
>Isee three possible fixes. The first two would be on the user (client)
>end. Either use a separate callsign for RF and Internet, or have a toggle
>switch that inserts something into the path (such as NORF) to tell the
>IGates not to gate these messages to RF. I personally don't like these
>first two choices, because it requires the client to figure out what is
>going on. If I'm having simultaneous conversations with RF and Internet
>stations, I would have to consistently toggle NORF on and off.
Not necessarily: Your client software must know that you're doing an
internet QSO, and so could toggle it on and off for you automatically in
the transmitted packet. The user wouldn't have to know that it was
happening.
>The third
>solution would be to have the IGates be able to decipher when a station
>that is in their local list is present on the 'net. This, in my opinion,
>is the best solution, because once the changes were made in the IGate
>software, clients wouldn't have to make any changes.
I agree that this seems to be the best solution. Unfortunately it also
affects most clients, since most clients are capable of igating.
>If IGates currently keep
>alist of stations that they consider local to them, and these are the
>recipients of gated traffic. If the gate were to detect the same callsign
>with a TCPIP header, it would simply drop them from the list for x amount
>of time (this could be a sysop paramater, 30 or 60 minutes or whatever).
I like this idea, but what about in an emergency situation, where you're
trying to communicate via a client connected to the 'net and RF, and the
'net connection goes down suddenly. You'd have to wait until one of the
igate stations would time you out before you'd get from RF to the 'net
again. Any easy fix for this?
I'd like to see that any station in an emergency could get their traffic
through, whether it is RF or 'net traffic, without having to wait for their
status to change w.r.t. which interface they're on.
Even with the above problem, I think your idea is worth implementing. It
seems obvious that it would reduce RF traffic.
-----------------------------------------------------------------
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
