| |
ZL3AI > APRDIG 02.07.04 10:31l 750 Lines 29106 Bytes #999 (0) @ WW
BID : 3545-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 30, 1/1
Path: DB0FHN<DB0FOR<DB0MRW<DB0WUE<DK0WUE<DB0RES<ON0AR<VK6HGR<GB7ESX<ZL2BAU<
ZL3VML
Sent: 040702/0758Z @:ZL3VML.#80.NZL.OC #:27021 [Chch-NZ] FBB7.00i $:3545-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, June 30, 2004.
1. RE: Strange positions showing up
2. Re: Ambiguity Plotting of positionless packets
3. UIDIGI digipeater symbol overlay?
4. Re: UIDIGI digipeater symbol overlay?
5. Re: Ambiguity Plotting of positionless packets
6. Maps on findu from aprsworld
7. Re: UIDIGI digipeater symbol overlay?
8. Re: Maps on findu from aprsworld
9. ECHO satellite hearable on D7 and D700
10. Re: Ambiguity Plotting of positionless packets
11. ECHO satellite and APRS?
12. RE: ECHO satellite and APRS?
13. Re: ECHO satellite and APRS?
14. RE: ECHO satellite and APRS?
15. Re: Maps on findu from aprsworld
16. RE: ECHO satellite and APRS?
17. Ping Flood Attack?
18. Re: APRS Vicinity Tracking Nationwide!
19. Campbell Scientific CR-10 WX station
20. Re: Campbell Scientific CR-10 WX station
21. RE: Ping Flood Attack?
22. Re: APRS Vicinity Tracking Nationwide!
23. Re: Unproto Paths for Digipeaters
----------------------------------------------------------------------
Subject: RE: Strange positions showing up
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Tue, 29 Jun 2004 23:07:16 -0500
X-Message-Number: 1
Those are Mic-E reports. Unfortunately, the Mic-E character for a
longitude of 9 East is the DEL character. My guess is there is an IGate
with filtering turned on in the TNC in that area.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
>-----Original Message-----
>From: Larry Cerney
>
>I seems that I receiving position reports from a few station
>from Lisbon, Portugal. One seems to be the ARRL of Portugal
----------------------------------------------------------------------
Subject: Re: Ambiguity Plotting of positionless packets
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 30 Jun 2004 00:48:50 -0400
X-Message-Number: 2
On 6/29/04 at 8:50 AM Robert Bruninga <bruninga@usna.edu> sent:
>The algorithm is simple. On each packet heard without
>a position, simply take the nearest DIGI's location,
>randomize it within a 1 mile radius and then use that
>position with a 10 mile Ambiguity indication as the
>last known vicinty plot for that station. Then plot it
>on a 128 range scale map. This will ALWAYS show
>about where someone is, even if they have no posit!
>
>Thats how APRSdos does it... A web page should
>do it too.... de WB4APR, Bob
Something to play with:
http://www.findu.com/cgi-bin/find.cgi?call=wb4apr&vicinity=yes
This is very simplistic, does not make any attempt to see if the first digi
is used, substituted, or valid, and it plots the digi location. It is
certain not to work in many circumstances, for example:
http://www.findu.com/cgi-bin/find.cgi?call=K4HG-8&vicinity=yes
This packet path is (assuming you look before I leave work in the morning):
K4HG-8>RU4T8T,RELAY,WIDE,KD4BBM-6*,qAO,WB2WPA-3:'l) R`k/]"3z}
Without callsign substitution on the relay, it finds a station calling itself
RELAY in Tennessee...
There are too many possibilities to come up with a universal algorithm
easily, and I'm not convinced this is useful enough to spend much time on
it, so for now, this is all you get. Please, no messages telling me it
doesn't work for any given report...
Steve K4HG
----------------------------------------------------------------------
Subject: UIDIGI digipeater symbol overlay?
From: David and Ann Fraser <zl3ai@nzart.org.nz>
Date: Wed, 30 Jun 2004 17:32:21 +1200
X-Message-Number: 3
What is the proper overlay for a UIDIGI digipeater symbol?
I'm a little confused as one source says 'U' while another says 'N'.
David ZL3AI.
----------------------------------------------------------------------
Subject: Re: UIDIGI digipeater symbol overlay?
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Wed, 30 Jun 2004 08:18:25 -0500
X-Message-Number: 4
Bob Bruninga suggested using the 'U' overlay for a UIDIGI to distinguish
it from a digipeater setup with an 'N' overlay, because UIDIGI was the
only standalone digipeater that handled the UIFLOOD call of WIDEn-n
properly. The Kantronics KPC3+ were being mislabeled with an 'N'
overlay when they were in fact setup using the ID method versus the
No-ID method when handling UIFLOOD calls. His analogy was that
UIDIGI handled the No-ID situation correctly and therefore warranted
a unique overlay that identified it as such. Hence, the 'U' overlay was
instituted around August 2001.
We have many KPC3+ units in this part of the country using the 'N'
overlay that actually perform the ID method and bastardize the packet
path and create unnecessary duplicates of packets in the network. The
'U' overlay lets us know which digis handle the UIFLOOD call properly.
Having said that, we also made some other fundamental changes in our
network to accommodate misconfigured digpeaters. We changed the
UIFLOOD call from WIDE to a regional identifier such as AL to
represent statewide digipeating to contain certain packets from spilling
out into an adjacent states network. We change the UITRACE call
from TRACE to WIDE. So anybody who uses WIDEn-n will now
see callsign substitution at each point in the network. While this may
increase the packet payload as it propagates throughout the path, it also
significantly reduces and/or eliminates packet duplication related to
misconfigured digipeaters that could never seem to handle proper
UIFLOOD callsign substitution. The impact was huge in reducing dupes.
Of course this eliminated handling of TRACE paths. This was referred to
as a paradigm shift by Bob Bruninga to build a better network.
Most of our weather station use a path of ALA3-3 in the state. This
insures that the RF packet activity does not spill over into an adjacent
states network. In effect, it controls RF data to a certain region rather
than adding unnecessary data from clogging our neighbors network.
I must admit the change we made to UIFLOOD and UITRACE
callsigns made a welcomed significant impact to our network. The
beauty is that it is transparent to the end user wit the exception of
no longer supporting the TRACE path.
73's
Tim - N8DEU
Huntsville, Alabama
----------------------------------------------------------------------
Subject: Re: Ambiguity Plotting of positionless packets
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 30 Jun 2004 10:59:45 -0400
X-Message-Number: 5
Just a small kibitz... It would seem that two rules would
drastically improve this ambiguity tracking...:
The first digi must be NOT RELAY or WIDE or WIDEn
The first digi must have a *
----------------------------------------------------------------------
Subject: Maps on findu from aprsworld
From: "Matt Werner" <kb0kqa@arrl.net>
Date: Wed, 30 Jun 2004 10:13:43 -0500
X-Message-Number: 6
I just noticed today that the zoom levels of the maps on findu (as produced
by aprsworld) have changed for the three maps presented. Outstanding. I
had asked for this quite a while ago and am happy to see the change -
especially the middle map being a little farther out.
The inner map is maybe a little too far out though - it's far enough out
that it doesn't display the street names around the station that you are
looking up. Can it be moved in a little bit (or find some other way to
display the names)?
Glad to see the progress!
73 - Matt
KB0KQA
----------------------------------------------------------------------
Subject: Re: UIDIGI digipeater symbol overlay?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 30 Jun 2004 11:23:41 -0400
X-Message-Number: 7
Great work on the new n-N paradigm! Glad to hear it is working in Alabama.
Yes, "N" is for KPC-3's doing WIDEn-N digipeating with NOID enabled. If
they are using "ID" then the overlay should be "I". UIDIGI's should be "U".
Thanks. Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Maps on findu from aprsworld
From: James Jefferson Jarvis <jj@aprsworld.net>
Date: Wed, 30 Jun 2004 10:32:54 -0500
X-Message-Number: 8
Matt and APRSSIG -
Steve apparently changed the findu mapping to point to the new aprsworld
mapserver, geo.aprsworld.net. At this point scale and size issues should
be directed to Steve and map content and server issues to me.
-Jim
----------------------------------------------------------------------
Subject: ECHO satellite hearable on D7 and D700
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 30 Jun 2004 14:24:20 -0400
X-Message-Number: 9
ECHO was launched yesterday and can be heard on any D700 or D7 radio. Just
set the internal TNC to 9600 baud. On the D700 you will have to press the
PMON button to monitor the packets on the front panel since they are not
APRS at this point.
Tune to 435.150 (starting at .160 and ending at .140)
The potential to do APRS mobile to Mobile is outstanding though it is not
currenlty enabled. No user uplinks are yet authorized.
This is a good chance to see what your D7/700 can do with 9600 baud
downlink. Hook up a PC to the serial port and you can capture the data.
There is an AMSAT telemetry program you can use to see the telemetry.
See www.amsat.org
ECHO passes over your area (Northern Hemisphere) every day about 3 times
between 10 AM to 1300 AM and then 2100 PM to 0030 AM LOCAL DAYLIGHT time.
If you want to trcak it, here are a useable set of Keps:
ECHO
1 28373U 04025H 04182.42604665 -.00001033 00000-0 -28697-3 0 43
2 28373 98.2586 251.9949 0071137 214.0678 145.5877 14.42925140 682
And as always, feel free to contribute to its launch. They are still a
little short and used emergency funds that need to be re-built...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Ambiguity Plotting of positionless packets
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 30 Jun 2004 15:30:52 -0400
X-Message-Number: 10
On 6/30/04 at 10:59 AM Robert Bruninga <bruninga@usna.edu> sent:
>Just a small kibitz... It would seem that two rules would
>drastically improve this ambiguity tracking...:
>
>The first digi must be NOT RELAY or WIDE or WIDEn
or TRACEn. I thought of this, but it will take more involved parsing and
error reporting, no time for that now. Like I said, I'm still unconvinced
of the utility, and time is limited...
>The first digi must have a *
This doesn't work, for example:
K4HG>APRS,KD4BBM-6,WIDE*:....
K4HG>APRS,KD4BBM-6,WIDE3-1:....
you'd need to check that the first digi is used, meaning that the * occurs
after the first digi, or than an n-n is decremented...same answer as
above...
Steve K4HG
----------------------------------------------------------------------
Subject: ECHO satellite and APRS?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 30 Jun 2004 15:37:33 -0400
X-Message-Number: 11
Satellite-APRS-Internet-GURUS:
How should we do the ECHO satellite downlink?
For ARISS and PCSAT, and next years' ANDE, PCSAT2 and RAFT, all of the 1200
baud packets in the downlink were APRS or other UI packets of human
interest. Thus any ground station anywhere just IGated everything they
heard straight into APRS-IS so that packets captured anywhere were
available everywhere...
But the 9600 baud downlink from ECHO will be 8 times larger and probably
98% packets of no interest to the APRS-IS.
TWO QUESTIONS:
1) Do we need to write IGate software that will filter the downlink stream
from the satelite and only INJECT APRS/UI compatible packets into the
APRS-IS?
2) Since 95% of the other 98% of packets will be data from the ECHO's BBS
in the PACSAT protocol, and can be assembled back together on the
ground into a full copy of all files on orbit, I think we need an
Internet collection point that re-builds for the global HAM community a
WEB based copy of all files that are on the ECHO BBS.
Already that is what the PACSAT protocol does, is to let each users
accumulate all packets and slowly "fill" his ground station with copies of
what others are downloading so that he only needs to request FILLS.
The APRS-Internet struture does this for ARISS and PCSAT and other UI
digipeating satellites globally, so how do we want to strucutre the similar
data from ECHO? And why not also accumulate all packets so that the WEB
would easily capture the complete image of all files and make them
available without human intervention to hams worldwide...
Who wants to spearhead this?
de WB4APR, Bob
----------------------------------------------------------------------
Subject: RE: ECHO satellite and APRS?
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 30 Jun 2004 15:01:58 -0500
X-Message-Number: 12
>-----Original Message-----
>From: Robert Bruninga
>Posted At: Wednesday, June 30, 2004 2:42 PM
>Subject: [aprssig] ECHO satellite and APRS?
>
>But the 9600 baud downlink from ECHO will be
>8 times larger and probably 98% packets of no interest to
>the APRS-IS.
>
>TWO QUESTIONS:
>
>1) Do we need to write IGate software that will filter
> the downlink stream from the satelite and only INJECT
> APRS/UI compatible packets into the APRS-IS?
Already exists in javAPRSIGate. Probably exist in a few others, too.
>2) Since 95% of the other 98% of packets will be data
> from the ECHO's BBS in the PACSAT protocol, and
> can be assembled back together on the ground into
> afull copy of all files on orbit, I think we need an Internet
> collection point that re-builds for the global HAM
> community a WEB based copy of all files that are
> on the ECHO BBS.
Let's leave that to AMSAT. It really has nothing to do with APRS.
>to strucutre the similar data from ECHO? And why not also
>accumulate all packets so that the WEB would easily capture
>the complete image of all files and make them available
>without human intervention to hams worldwide...
Doesn't this defeat what AMSAT is trying to do with the satellite: make
these "files" available to those who use the satellite, not to the
entire Internet? Plus, isn't the actual retrieval of files done via
connected mode (I don't know the ECHO specs, but I think that is how it
works)? I would rather not see non-UI packets gated to APRS-IS since
they have nothing to do with APRS and would therefore carry the
potential to cause problems with the server, IGate, and client parsing
software.
As I have stated in the past, the APRS-IS servers, IGates, and clients
are designed to assume certain things about the packets that get passed
(like having a valid data type character in conjunction with
corresponding data). Also, the APRS-IS network is tuned to carry the UI
packets of APRS (Nagel algorithm disabled, for example) and adding a lot
of connected mode packets to the data stream could increase bandwidth
requirements significantly while degrading over-all reliability.
I think it would be great to gate APRS packets from ECHO to APRS-IS. I
think it would be detrimental, however, to gate all of the non-APRS
packets to APRS-IS.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: ECHO satellite and APRS?
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 30 Jun 2004 16:17:09 -0400
X-Message-Number: 13
On 6/30/04 at 3:37 PM Robert Bruninga <bruninga@usna.edu> sent:
>The APRS-Internet struture does this for ARISS and
>PCSAT and other UI digipeating satellites globally,
>so how do we want to strucutre the similar data from
>ECHO? And why not also accumulate all packets so that
>the WEB would easily capture the complete
>image of all files and make them available without
>human intervention to hams worldwide...
I am not familiar with the PACSAT protocol, is it binary? If so, the APRS
IS cannot be used, you would need to create a separate internet system to
collect the packets...if this was done, it would be easy to then identify
the APRS packets on this server and forward them to the APRS IS.
The two possibilities I see are to create an APRS IS style internet system
(PACSAT IS?), which consolidates and removes the duplicate packets, in
which case the IGate software is very simple, just forwards what it hears
to the PACSAT IS. A findU style parser could parse the PACSAT IS stream
into data.
The other possibility is to use an existing PACSAT ground station software
program, and add the capability to send what it hears to a web server
directly, without an Internet System. This is the easier option, especially
if someone has access to the code of a ground station client (a quick
search of sourceforge did not show any open source code, but I didn't look
elsewhere). You would still need software on the server to assemble the
PACSAT packets into files, but again, if you had source code for a client
program, it would be possible to adapt it.
Sounds like a fun project, hope someone can make it happen...
Steve K4HG
----------------------------------------------------------------------
Subject: RE: ECHO satellite and APRS?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 30 Jun 2004 16:20:09 -0400
X-Message-Number: 14
>>>"AE5PL Lists" 6/30/04 4:01:58 PM >>>
>>2) Since 95% of the other 98% of packets will be data
>> from the ECHO's BBS in the PACSAT protocol, and
>> can be assembled back together on the ground into
>> a full copy of all files on orbit, I think we need an Internet
>> collection point that re-builds for the global HAM
>> community a WEB based copy of all files that are
>> on the ECHO BBS.
>
>Let's leave that to AMSAT. It really has nothing to do
>with APRS. Doesn't this defeat what AMSAT is trying
>to do with the satellite: make these "files" available to
>those who use the satellite, not to the entire Internet?
Well, that is why I prefer a UI digipeater so that Hams can QSO live via
the satellite and not just exchange files... which they can now do 24/7/365
via other means.
>Plus, isn't the actual retrieval of files done via connected
>mode ?
No, that is the beauty of the PACSAT protocol, one uplinks files via
connected mode, but files are distributed to everyone in the footprint and
they all capture everything whether they need it or not. Stations only
requests "fills" on pieces that they missed. Kinda like an APRS system for
files instead of single one-line data...
>I think it would be great to gate APRS packets from
>ECHO to APRS-IS. I think it would be detrimental,
>however, to gate all of the non-APRS packets to APRS-IS.
Agree. That's why I made the subject a dual post to AMSAT also. But since
the APRS-Internet structure has so many gurus that could easily set up a
"side channel" for ECHO just like they did for the APRS-IS, I thought I
would ask here first...
BOb
----------------------------------------------------------------------
Subject: Re: Maps on findu from aprsworld
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 30 Jun 2004 16:25:41 -0400
X-Message-Number: 15
On 6/30/04 at 10:13 AM Matt Werner <kb0kqa@arrl.net> sent:
>I just noticed today that the zoom levels of the maps on findu (as produced
>by aprsworld) have changed for the three maps presented. Outstanding. I
>had asked for this quite a while ago and am happy to see the change -
>especially the middle map being a little farther out.
A lot of people asked for this, now that Jim has the mapserver running well
with the original findU server I donated, I inally got around to making the
switch from his original server. The difference is instead of aprsworld
generating the maps and plotting the position on it, the new server just
generates the map, and then findU plots on it.
>The inner map is maybe a little too far out though - it's far enough out
>that it doesn't display the street names around the station that you are
>looking up. Can it be moved in a little bit (or find some other way to
>display the names)?
I guess it is pretty sensitive to zoom levels, I tweaked it a little,
hopefully it will work in more places now...
Steve K4HG
----------------------------------------------------------------------
Subject: RE: ECHO satellite and APRS?
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 30 Jun 2004 15:54:34 -0500
X-Message-Number: 16
>-----Original Message-----
>From: Robert Bruninga
>Posted At: Wednesday, June 30, 2004 3:24 PM
>Subject: [aprssig] RE: ECHO satellite and APRS?
>
>Agree. That's why I made the subject a dual post to AMSAT
>also. But since the APRS-Internet structure has so many
>gurus that could easily set up a "side channel" for ECHO just
>like they did for the APRS-IS, I thought I would ask here first...
There is a lot more to it than just setting up a "side channel". As
Steve (and I) mentioned, APRS-IS is designed for APRS type data. The
servers are not designed to properly handle just "any" type of data due
to the dupe check methods used, etc. I agree with Steve: as it stands
now, someone would need to design a separate network for the PACSAT
protocol, including designing servers and clients specifically for the
protocol. This is not something I would recommend taking a shotgun
approach to. Rather, I think it should require a well thought out
approach allowing for use beyond just the ECHO satellite.
And, no, I do not have any current interest in doing this. Just where
my interests currently are and are not.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
----------------------------------------------------------------------
Subject: Ping Flood Attack?
From: "Dennis Hudson, N2LBT" <n2lbt@n2lbt.com>
Date: Wed, 30 Jun 2004 17:21:01 -0400
X-Message-Number: 17
Does anyone have contact with N0TWP? His station is out of control and
locking up the network for a 200+ mile radius.
http://www.findu.com/cgi-bin/raw.cgi?call=N0TWP-14
--
Dennis Hudson, N2LBT
Sysop APRSALY
http://n2lbt.com:14501
Albany, NY
----------------------------------------------------------------------
Subject: Re: APRS Vicinity Tracking Nationwide!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 30 Jun 2004 18:50:04 -0400
X-Message-Number: 18
FINDU now supports Vicinity tracking! (Thanks Steve!)
Vicinity tracking was introduced into APRSdos in Jan 1999 to make it
possible to track any packet station nationally even without any GPS! The
main objective was to allow APRS to track nationally, little match box
trackers that could run for a year or more on a 9v battery. Without a
GPS, they only draw power 0.002% of the time when they wake up to send a
one second 1 Watt packet once every 10 minutes (for more than a year)...
Thus APRSdos Vicinity Tracking could track these frequent or desired
occurrences:
1) MIM modules (with no GPS) (match box size)
2) Other PIC Packet generators (with no GPS)
3) Any TNC with only a beacon
4) TH-D7 HT's even if the user has GPS off
5) People with BAD or NO position data, etc
6) Stations who only sent a packet message
To Vicinity Track via FINDU simply add &vicinity on the end of the normal
FINDU request:
http://www.findu.com/cgi-bin/find.cgi?call=K4HG-8&vicinity=yes
NOTE: If you dont get a VICINITY plot, then the *first* digi could not be
resolved. If a valid position is otherwise on file, you will get that...
This is why mobiles should always use a path beginning with RELAY or
WIDE...
All Vicinity Tracking means is an automated way of displaying the general
-vicinity- where a packet originated by identifying the location of the
FIRST DIGIPEATER that a packet hit. Thus the universal APRS path used by
almost everyone of WIDE, WIDEn-N could always be tracked (with or without
GPS).
APRSdos displayed this as follows:
1) The station CALL was displayed randomly within a mile of the digi
2) The symbol was displayed as a big "?"
3) The call was suppressed above the 64 mile scale to not clutter the map
4) But otherwise, the station was in the database now with an assumed
"vicinity" position until later updated if a real posit eventually came in.
This solved the problem in APRSdos that some current software still has,
and that is that they do not establish a record in their data base for any
station until they get a posit. Or they plot them all at 000/000. Ignoring
stations wihtout a position is counter to the original mission of APRS...
ANYWAY.... Now that FINDU can give us vicinity plots anywhere in the WORLD,
I encourage everyone to think-outside-the-box for neat applicaitons... I
wish I had known this was coming, My daughter is tripsing around in France
for the next 2 weeks and I could have put a MIM module in her suitcase and
felt more secure seeing her on the map... a 19" piece of tiny wire can fit
easily inside just about anything...
For much much more on this topic, read the original APRSdos VICINITY.TXT
file included in all copies... (find it on Google)...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Campbell Scientific CR-10 WX station
From: "Spider" <spider@rivcom.net>
Date: Wed, 30 Jun 2004 16:14:43 -0700
X-Message-Number: 19
Looking for an APRS interface for this station. Anyone running one?
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: Campbell Scientific CR-10 WX station
From: "Spider" <spider@rivcom.net>
Date: Wed, 30 Jun 2004 17:24:56 -0700
X-Message-Number: 20
Hi Anthony!
I am looking into the details now and putting out feelers. I am hoping to
hear some ham in this sig...say.."Yeah, I've done that...here's how"! Curt
has offered to support them in Xastir and I am knocking on Scott Miller's
door too! Probably one of the best OpenWXTRAK Wx projects I can think of.
I think that we could take APRS Wx stations up a notch or two supporting
these sorts of units. Having an interface from the CSI dataloggers to APRS
format would benefit all concerned parties....without any doubt in my mind.
I know Weather Display supports at least one CSI (Campbell Scientific, Inc)
datalogger now....just not much info about it. I'll contact them too!
I have been given a complete working station without connectivity to the
world which was used for some government experiment that has been abandoned.
It looks to be in great shape and a very professional high $$$ installation.
And, it is in an area several government agencies see as an important area.
Now I am faced with finding a solution to interface the unit and I'd really
like that interface to be APRS. Obviously, I need all the help I can get
with this.
Jim Wooddell
FireNet Coordinator
WA6OFT
----------------------------------------------------------------------
Subject: RE: Ping Flood Attack?
From: "Ken Brown" <W2KB@comcast.net>
Date: Wed, 30 Jun 2004 20:32:00 -0400
X-Message-Number: 21
20:12:08R N0TWP-14>APW251,W3CE-3*,W2VER-15*,WIDE4-4,TRACE
is what I received from him on RF. According to his comment he is in an
18-wheeler. Current location near Allentown, PA on my UI-View map.
73, ---Ken W2KB
----------------------------------------------------------------------
Subject: Re: APRS Vicinity Tracking Nationwide!
From: Wes Johnston <wes@johnston.net>
Date: Wed, 30 Jun 2004 21:51:45 -0400
X-Message-Number: 22
I just looked up my car, it shows 21 miles from my location, even though
there is a callsign substitution digi at my house and 6 miles from
me. This is not the fault of the vicinity tracking method, but rather an
offshoot problem with our WIDEn-n setup.
One point for the users... I run a path of RELAY,WIDE2-2 (well, actually
RELAY,SC2-2). The listing of RELAY gives any callsign substituting
digipeater a place to sub in it's callsign while it decrements the WIDEn-n
counter. Problem is as my packet travels the network, each subsequent
digipeater to keep putting it's callsign in. Now when FINDU logs my
packet, it may catch the last hop my packet took and log that as my
position... and that could be 100 miles from me, or three digipeaters
away.... The solution it seems is to use the path of RELAY,WIDE,WIDE1-1 so
that RELAY can be sub'ed by the FIRST digipeater to hear my packet, and
subsequent digipeater hops can be logged in place of the WIDE.
http://www.findu.com/cgi-bin/find.cgi?call=Kd4rdb-14&vicinity=yes
So if you want vicinity tracking to work, you have to put TWO callsigns
infront of your WIDEn-n path element - or not use WIDEn-n at all.
Wes.
----------------------------------------------------------------------
Subject: Re: Unproto Paths for Digipeaters
From: "John Langtry, VE3NEC" <ve3nec@sympatico.ca>
Date: Wed, 30 Jun 2004 21:52:32 -0400
X-Message-Number: 23
Hi Eric, and all
True, until you come up to Canada for your Summer vacation.
Here, our DOC (I.C.) requires to "Ident" the station every 30 minutes. I
make mine every 28 minutes, just in case. :)
This is one of the few cases where you might want to send your Posit more
frequently, than your station's ident.
To Bob's point, and every Amateur should know this - We listen first
*before* we transmit. Same thing in APRS ! Launch APRS and listen for a
while, and get a "feel" for the digipeaters around you. Then use the CALL
of your nearest digi, followed by (say WIDE 2-2).
vy 73 de John VE3NEC
905-873-8715
---
END OF DIGEST
Read previous mail | Read next mail
| |
