| |
ZL3AI > APRDIG 04.05.03 19:17l 423 Lines 14078 Bytes #999 (0) @ WW
BID : 1240-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 27, 3/4
Path: DB0FHN<DB0ZWI<DB0CHZ<DB0ERF<DB0MRW<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<VK7AX<
ZL2BAU<ZL3VML
Sent: 030430/1337Z @:ZL3VML.#80.NZL.OC #:64848 [Chch-NZ] FBB7.00i $:1240-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Ver.2: Another thing I'd like to see...
From: Gerry Creager N5JXS <gerry.creager@tamu.edu>
Date: Sun, 27 Apr 2003 19:47:26 -0500
X-Message-Number: 16
More precisely, (A)X.25 is inefficient in an RF environment, and we
depend on AX.25 transport. APRS takes some interesting advantages...
and liberties... with original AX.25 assumptions, and exploits these to
its advantage.
Were we using a more modern protocol, we'd consiter multicast with
subscription rather than UI or its equivalent, UDP.
gerry
----------------------------------------------------------------------
Subject: d7a power plug
From: "Wes Johnston" <wes@johnston.net>
Date: Sun, 27 Apr 2003 21:19:20 -0400
X-Message-Number: 17
Anyone know the size of the coaxial power plug? or radio shack part number?
Thanks
Wes
----------------------------------------------------------------------
Subject: Filtering of Internet feed?
From: "Jacob Tennant" <k8jwt@ntelos.net>
Date: Sun, 27 Apr 2003 21:23:44 -0400
X-Message-Number: 18
A local op. was asking me if there is any way to filter down the amount of
stations received on the internet feed of APRS at the local (machine) level?
Was looking for just stations within approx. 100mole radius of his station
instead of a worldwide dump of stations?
I was also wondering about this for use at our soon to be active EOC/Igate
station. Not wanting to hog so much band width from the donated cable modem
connection.
Jacob Tennant K8JWT
----------------------------------------------------------------------
Subject: RE: Ver.2: Another thing I'd like to see...
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Sun, 27 Apr 2003 21:49:09 -0400
X-Message-Number: 19
Bob Bruninga wrote:
<snip>
>APRS is for tactical REAL-TIME information. Not for 24/7 moniroing of
>nothing happening.
No...that's a job for BEACONet on 10 meters! Geez, I hope the geomagnetic
field would calm down a little. :) Just three days ago, the screen (from
Florida, USA), looked like this:
http://www.rochesterny.org/BEACONet/images/PSK31-APRS-10m-20030423.JPG
Then again...BEACONet-ers are also the first ones to know when the band is
open again. :))
Ev, W2EV
----------------------------------------------------------------------
Subject: K0FAO-5>EMERGENCY
From: "Joe Della Barba" <joe@dellabarba.com>
Date: Sun, 27 Apr 2003 21:51:00 -0400
X-Message-Number: 20
Anyone else see this?
73 Joe N3HGB
----------------------------------------------------------------------
Subject: Re: Filtering of Internet feed?
From: Kirk Mefford <kc2elo@softhome.net>
Date: Sun, 27 Apr 2003 22:52:40 -0400
X-Message-Number: 21
Afilter does exactly what you're looking for. I lost the link to it but if
you can't find it I think I still have the install package somewhere.
----------------------------------------------------------------------
Subject: Re: Filtering of Internet feed?
From: Kirk Mefford <kc2elo@softhome.net>
Date: Sun, 27 Apr 2003 23:04:50 -0400
X-Message-Number: 22
Found the link......
http://www.dwrracesupport.com/dnld/AFilter28.zip
----------------------------------------------------------------------
Subject: RE: Ver.2: Another thing I'd like to see...
From: "Daron J. Wilson" <daron@wilson.org>
Date: Sun, 27 Apr 2003 20:21:59 -0700
X-Message-Number: 23
>UNFORTUNATELY, many client software programs ignored this fundamental
>principle and so they only transmit the same packet over and over at a
>fixed rate. This ruins the fundamental design concepts of APRS in two
>ways. It makes no distinction between NEW fresh data that needs to be
>transmitted quickly and OLD stale data that is of less and less
>importance and only adds QRM to the channel.
>
>It is too bad that some of the most popular APRS programs ignored this
>fundamental design principle of APRS..
I'm sure you have answered it before Bob, but which software is fully
compatible? Why would developers provide software packages that are not
fully functional with the system?
I guess if you let me know which ones actually follow the plan, I'll ask
the guys that built the other software why they didn't follow.
N7HQR
----------------------------------------------------------------------
Subject: Re: [ BobDonnell@arkalmus.com ] Re: [ "Curt Mills, WE7U" ] Re:
Another thing I'd like to see...
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 27 Apr 2003 22:23:32 -0500
X-Message-Number: 24
>Then you need the whole AX.25 protocol stack, and APRS software isn't
>designed to support connected-mode operations.
APRS messaging does not require connected mode. It just requires that a
sending station keep sending its message until an ACK is received from the
other station, or a timeout occurs.
>Also, a lot of the
>simple tracker plans don't make provision for receiving packets. Heck,
>some don't make provision for checking to see if the channel's busy. In
>the case of high mountain SAR work, it may actually be necessary to have
>the trackers not aware of channel loading, because when the receiver
>"can see for miles", the channel may never become unoccupied. Making
>use of existing infrastructure by staying on 144.39 has both plusses and
>minuses in that environment.
This is my biggest complaint about simple trackers. They really need to be
able to receive and decode traffic so that messaging can occur. When they're
just out there generating position information, and not participating in the
network, a lot of the value of APRS is lost. However, there is a time and
place for transmit only trackers.
The whole issue of stations not able to transmit is another factor of CSMA
networks that we need to rethink...
As I stated, there's lots of reasons that AX.25 is the wrong protocol...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: AX.25 & TCP/IP [was: Another thing I'd like to see...]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Sun, 27 Apr 2003 23:31:17 -0400
X-Message-Number: 25
"Gregg G. Wonderly" wrote:
<snip>
>As I stated, there's lots of reasons that AX.25 is the wrong protocol...
The "least common denominator" is the TNC. AX.25 is what all of the TNC's
use, right? Does someone make a TCP/IP based TNC? I ask from ignorance,
nothing more.
Regards,
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Filtering of Internet feed?
From: "Brent Hildebrand" <bhildebrand@earthlink.net>
Date: Sun, 27 Apr 2003 20:33:35 -0700
X-Message-Number: 26
While AFilter may filter the APRS-IS data stream, you still receive the
data from the full Internet feed. The JavAPRSFilter approach prevents
the sending of data to the client program in the first place keeping
bandwidth to a minimum. See the JavAPRSFilter information reposted
below.
===============
1.2 javAPRSFilter Users Guide.
Introduction:
The APRS-IS full feed today have a lot of traffic and require a high
bandwidth, in particular for the APRS-IS server sites, but also for some of
you that connect that are only interested in the particular traffic. To
accommodate this a number of servers have special regional feeds which
filter the traffic. There are also some weather specific feeds available.
But all these are setup according to what the server operator "thinks" will
be good for the users. Now we can take this one step further.
Now will each of you be able to select what traffic you are interested in
and the server will create a unique feed for you. There is great flexibility
to construct your personal feed.
How does it work?
Pete Loveall AE5PL have written the APRS-IS server software javAPRSSrvr in
java which is used by a number of servers. Pete has been kind to create some
hooks into his server software so I have been able to write a filter add-on,
javAPRSFilter (also in java). These 2 applications work together to provide
this filtering. Status on the APRS-IS servers can be found here:
<http://ahubswe.net/aprs_stat.asp>
You define the filter by doing the following:
1. Connect and logon to a filter enabled port on a server
2. Send an APRS message to the server requesting the filter you want
Filter commands
There are 4 different kinds of filters that can be used in any combination.
Each filter is working independent and is additive to the feed. This mean if
the filter finds a match it will be passed to you. The filter commands in
the APRS message to the servers call is starting with the word 'filter'
(without quotes) and each filter command is delimited by a single space. A
message with just 'filter?' (without quotes) will return the current filter
definition.
#1 Range filter
The range filter will pass all stations and their beacons, status, messages
etc within a distance from a set location. It will also pass messages to
stations within the filter and positions of the message sender even if they
are outside the range. Up to 3 range filters can be used at the same time to
extend the areas when you have problem to find a good circle match.
Syntax: r/lat/lon/dist [r/lat1/lon2/dist2 [[r/lat2/lon2/dist2]]
Where: r = range command
lat = latitude in degrees (no decimals). Negative for south
lon = longitude in degrees (no decimals). Negative for west
dist = distance in kilometers from lat/lon.
I'm sorry we don't use miles here in Sweden ;-)
Samples: r/55/-4/600 This will pass all traffic for UK
r/37/-81/1500 This will pass all east cost US traffic
#2 Prefix filter
The prefix filter will pass traffic based on if the sender's call starts
with a specific pattern. Up to 10 patterns can be defined at the same time.
Syntax: p/p1/p2/p3... (up to 10)
Where: p = prefix command
p# = The prefix (starting) pattern
Samples: p/K This will pass all traffic from stations
starting with K
p/SK/F This will pass stations starting with either SK or
F
p/SM5NRK This will pass all traffic from SM5NRK and any
SSID at the end
#3 Budlist filter
The budlist filter will pass traffic based on exact match of the sender's
call. Also the SSID is part of the exact match. If you want all SSID use
prefix filter above. Up to 10 calls can be defined at the same time (if they
can fit in a single APRS message).
Syntax: b/call1/call2/call3... (up to 10)
Where: b = budlist command
call# = The prefix (starting) pattern
Samples: b/SM5NRK This will pass all traffic from
SM5NRK
without any SSID
b/SM5NRK-5/SK5UM This will pass all traffic from
SM5NRK-5
and SK5UM
#4 Type filter
The type filter will pass traffic depending on the packet type. More than
one type can be defined in one single command.
Syntax: t/type
Where: t = type command
type = is one or more of the following letters
p = Position packets
o = Objects
i = Items
m = Message
n = NWS Weather
w = Weather
t = Telemetry
q = Query
s = Status
u = User-defined
Samples: t/p This will pass all traffic with a position
t/w This will pass all weather traffic. For
positionless weather objects the corresponding
position packet will also be sent when it is
next heard
t/mos This will pass all messages, objects and
status
traffic
Remeber that the APRS message must start with the word filter and the the
commands.
The above filters can be combined as explain above. Each filter will
however working independent of the others, for example:
filter r/63/16/1000 r/55/-4/600 p/F b/AE5PL t/s
The above filter will pass all traffic within Nordic (range#1) AND UK
(range#2) AND stations starting with F (prefix) AND from AE5PL (budlist) AND
all status traffic (type).
#5 Symbol filter
The symbol filter will pass traffic based on the symbol in the packet.
Syntax: s/pri/alt/over
Where: s = symbol command
pri = symbols in primary table
alt = symbols in alternate table
over = overlay character (case sensitive)
Samples: s/-> This will pass all House and Car symbols
(primary table)
s//# This will pass all Digi with or without overlay
s//#/T This will pass all Digi with overlay of capital T
#6 Digipeater filter
The digipeater filter will pass all packets that have been digipeated by a
particular station(s). Remember that a packet can many time go different
routes to get to APRS-IS and might be digipeated by other stations that is
shown. These packets are filtered out by various filters/application as
duplicates. More that one digipeater can be entered and each are OR
together.
Syntax: d/digi1/digi2...
Where: s = digipeater command
digi# = digipeater call
Samples: d/SM5NRK-2 Pass all packets digipeated by
SM5NRK-2
d/SM5NRK-2/SK5UM Pass all packets digipeated by
SM5NRK-2
or SK5UM
#7 Area filter
The area filter works the same as rang filter but the filter is defined as
a box of coordinates. The coordinates can also been seen as upper left
coordinate and lower right. Lat/lon are integer (no decimal) degress. South
and west are negative. Up to 3 area filters can be defined at the same
time.
Syntax: a/latN/lonW/latS/lonE
Where: a = area command
latN = North latitude border (-90 to 90)
lonW = West longitude border (-180 to 180)
latS = South latitide border (-90 to 90)
lonE = East longitude border (-180 to 180)
Sample: a/50/-130/20/-70 This will pass all traffic in US
#8 q Contruct filter
The q Construct filter will base all filtering on the q Construct used on
the APRS-IS. For more information about q Contract look here:
<http://www.aprs-is.net/q.htm>
Syntax: q/con/ana
Where: q = q Construct command
con = list of q Construct to pass (case sensitive)
ana = analysis based on q Construct.
i = Pass positions from IGATES identified by qAr or
qAR.
Sample: q/C Pass all traffic with qAC
q/rR Pass all traffic with qAr ot qAR
q//i Pass all position packets from IGATES
indentified in
other packets by qAr or qAR
Where to connect?
This is up to each server operator if/when they will provide this type of
service. The following servers and ports have this enabled as far as I
know.
ahubswe.net:14580
aprsca.net:14580
aprseast.net:14580
aprswest.net:14580
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
