| |
ZL3AI > APRDIG 23.10.03 04:33l 232 Lines 9316 Bytes #999 (0) @ WW
BID : 2180-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 20, 3/4
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0GOS<ON0AR<WB0TAX<7M3TJZ<SP7MGD<
ZL2TZE<ZL3VML
Sent: 031022/1246Z @:ZL3VML.#80.NZL.OC #:10967 [Chch-NZ] FBB7.00i $:2180-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: D700 / WinAPRS / tracker compatibility?
From: Wes Johnston <wes@johnston.net>
Date: Mon, 20 Oct 2003 14:00:52 -0400
X-Message-Number: 17
Your GPS probably was putting out a new version of NMEA which the kenwood
cannot receive.... I think it's NMEA 2.0... it has an extra field in the
end of the GPRMC sentance.
you can upgrade your kenwood for $65 or $70.
Wes
At 11:39 AM 10/20/2003, Richard Amirault wrote:
>showed up on my APRSDos screen. But all during the event I was never able
>to get a position on my own tracker. I could see it beacon, but always with
>question marks on the first line of the D700 screen (as if it didn't know
>what it was receiving) Other trackers showed up in my station recieved
>list, but not my own tracker. (don't know how the other trackers were
>actually programed)
>Why didn't I get a valid position report on my D700?
----------------------------------------------------------------------
Subject: Re: Accuracy of Garmin GPS devices?
From: "Curt Mills, WE7U" <hacker@tc.fluke.com>
Date: Mon, 20 Oct 2003 11:53:20 -0700 (PDT)
X-Message-Number: 18
On Mon, 20 Oct 2003, Darryl Smith wrote:
>I have just done a field test, and it appears that the GARMIN waits for
>about 15 seconds or so after losing lock before it indicates to the user
>that the data might be suspect. During this time, the NMEA data continues to
>come out the port with an 'A' indicating valid data, and static positions.
I remember reading about this several years ago, something which
basically amounts to dead-reckoning for some period of time with the
Garmins, which is intended to help you get through urban canyon
areas and through tunnels and such, without making your tracking
software go nuts.
That's most likely what you're seeing.
It's a "feature", not a bug. hi hi
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: IGate Support on Filtered and Regional Server Ports
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Mon, 20 Oct 2003 16:15:45 -0500
X-Message-Number: 19
The core servers (second, third, and fourth.aprs.net) and tier 2 servers
(xxx.aprs2.net) that are running javAPRSSrvr have implemented some extra
support for IGates that connect to their regional or user-defined filter
ports. As was mentioned earlier on this SIG, the regional and
user-defined ports required a station on RF to meet the filter criteria
before the server would pass messages to an attached IGate. Many times,
this would mean that a valid posit from the RF station would be required
before an IGate would gate messages to RF for that station.
The new IGate support has been implemented for user-defined filter ports
(usually 14580) and regional ports (varies, check the server's status
page on port 14501 for more details). To enhance IGate operation on
these ports, javAPRSSrvr now monitors all of the packets passed from the
IGate and records the origination callsign-SSID. This list is
maintained and is normally 30 minutes deep. If the server sees a
message addressed to one of the "recently heard" stations, it will pass
it and any associated posit to the IGate for further processing.
Just as a reminder, the following ports support filters on most
javAPRSSrvr servers:
1314 All messages, associated posits, and anything that passes the
filter.
14580 Messages (and associated posits) for the logged-in station and
for any stations heard gated through the logged-in station, and anything
that passes the filter.
Regional ports are effectively port 14580 with predefined filters.
When in doubt about a port, browse to the server's status page (port
14501) for a list of available ports.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: NO INFO
From: =?iso-8859-1?Q?K=D8FAO?= <k0fao@swbell.net>
Date: Mon, 20 Oct 2003 17:07:12 -0500
X-Message-Number: 20
I'm running windows 2000 pro and WinAPRS 2.5.1. I got the Precision
Mapping to run but now when I turn on the tnc port it won't hear the
data. It will TX but won't RX any packets. I'm using the kenwood TS-2000
for the radio and TNC. The radio has the DB9 plug going to the com port on
the computer and that is it. Am I missing something?
Micah
K=D8FAO
----------------------------------------------------------------------
Subject: Re: D700 / WinAPRS / tracker compatibility?
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 20 Oct 2003 18:30:28 -0400 (EDT)
X-Message-Number: 21
On Mon, 20 Oct 2003, Richard Amirault wrote:
>the other UIView. We wanted the tracker symbols to be a circle with a
>number inside. When I assembled and tested my tracker that's exactly what
>showed up on my APRSDos screen. But all during the event I was never able
>to get a position on my own tracker.
>
>Why didn't WINAprs show the icon correctly
WinAPRS never implemented "general" overlays characters. All they did was
make "special" icons that LOOK like overlays for the few routine uses of
overlays such as for a few of the DIGIs such as R, W, T and N. All other
overlay characters on all other ICONS are ignored...
>Why didn't I get a valid position report on my D700?
If you used your own callsign with the same SSID, it will ignore it. Or
does your tracker use an AX.25 TOCALL different from the APRS standards?
Bob
----------------------------------------------------------------------
Subject: Re: Smart DIgis and the new Paradigm
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 20 Oct 2003 18:45:32 -0400 (EDT)
X-Message-Number: 22
On Mon, 20 Oct 2003, Wes Johnston wrote:
>>No, even if the IGate was in range of the same smart digi that heard the
>>packet, that digi must still digipeat it at least once. So you still get
>>the guarante of at least one full digipeat by at least one FULL function
>
>You get the CHANCE that it'll be digipeated by a WIDE digi.... Let's not
>forget that some people's wide nodes are also IGATES.
Doesnt matter. The implementation intended was that any smart digi (Even
if it was also an IGate) would still digipeat the packet ONCE, even if the
path to the nearest IGate (itself) was 0.
>>1) If a home RELAY picked it up, then it would digi it to the next full
>>function digi.
>
>True... and everyone within range of the RELAY station would hear a copy of
>the packet. But RELAYs intentionally have less than optimal coverage...
But the full function digi ALSO digipeats it.
>>2) If a full function smart digi heard it first, then it would DIGIpeat
>>it at least once or whatever it took to get to the IGate.
>
>....And since I was forced to use RELAY, my packet would be routed by the
>smart digi using a SPECIFIC callsign of the next digi or to the IGATE. The
>wide digi in the next town might hear it, but if it's callsign is not next
>in the queue, it will not digipeat it. My packet was swallowed up by the
>network and redirected to some point I wasn't aware of , or mis-directed to
>some route I didn't want.... You presume that all people running RELAY in
>their path want to get to an igate, and well, they may not.
Yes, that would be true if we adopted this new fundamental rule to the new
paradigm... Maybe you are rright that it is not a good idea...
>No, it's not... I'm simply saying that I *may* want my packet to bounce
>around my local area for a while on RF... I am forced to use RELAY as a
>first hop, and that runs the risk of having my packet rerouted. How do I
>use RELAY,WIDE _and_ prevent my packet from being rerouted by this new
>paradigm?
We could add a digi flag "NOAUTO" which would insist that it should NOT be
autoigated. You might say that this is adding length to the packet....
this is true. So it boils down to statistics:
The GAINS of letting all smart digis assume that RELAY paths mean get me
to the nearest FULL digi and IGate are:
1) It will save LOTS of QRM by truncating paths beyond the nearest IGate
2) It will apply to ALL packets on the air, even those that haven't
learned of this new technique.
3) For those people who want to override this new rule (a minority)
they will have to add "noauto" to their path.
The status QUO is that we gain nothing by auto-IGate path truncation
unless ALL users add "IGATE" to their path.
My experience is that statistically, the RELAY solution would accomplish
the intention of reduction in QRM while leaving the status QUO does not..
Bob
----------------------------------------------------------------------
Subject: RE: OpenTracker
From: "Scott Miller" <scott@3xf.com>
Date: Mon, 20 Oct 2003 17:09:43 -0700
X-Message-Number: 23
Whoops, managed to kill the server for a few hours today... remote kernel
upgrade didn't work quite right. It should be back up now.
-----Original Message-----
From: bounce-aprssig-31505@lists.tapr.org
[mailto:bounce-aprssig-31505@lists.tapr.org]On Behalf Of Scott Miller
Sent: Sunday, October 19, 2003 11:03 PM
To: TAPR APRS Special Interest Group
Cc: aprssig@lists.tapr.org
Read previous mail | Read next mail
| |
