| |
ZL3AI > APRDIG 03.04.03 12:07l 279 Lines 9609 Bytes #999 (0) @ WW
BID : 1095-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 28, 1/4
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<RZ6HXA<WA7V<VE3FJB<IK6PYS<W4JAX<KD4GCA<
N2BQF<VK3TE<ZL2BAU<ZL3VML
Sent: 030402/0944Z @:ZL3VML.#80.NZL.OC #:63103 [Chch-NZ] FBB7.00i $:1095-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Friday, March 28, 2003.
1. Re: APRS Emergency packet e-mail (sorry about the repeat)
2. Re: my packets on findu.com
3. Re: my packets on findu.com
4. Re: [ Alex ] Re: Digipeating and fun with PIDs
5. Re: Digipeating and fun with PIDs
6. Re: APRS Emergency packet e-mail
7. APRS/CE
8. Re: APRS development?
9. Re: Digipeating and fun with PIDs
10. RE: APRS Emergency packet e-mail
11. Re: [ Alex ] Re: Digipeating and fun with PIDs
12. RE: dumb tracker with just a GPS and TNC to display waypoints on GPS?
13. Re: WinAPRS new version screen shots
14. Re: Dumb tracker ...
15. Re: Digipeating and fun with PIDs
16. Re: Dumb tracker ...
17. Re: Digipeating and fun with PIDs
18. Re: Digipeating and fun with PIDs
19. Re: Digipeating and fun with PIDs
20. Re: Digipeating and fun with PIDs
21. Re: Digipeating and fun with PIDs
22. Re: Digipeating and fun with PIDs
23. Macom GPS antenna
24. Re: Digipeating and fun with PIDs
25. Re: Digipeating and fun with PIDs
26. Re: APRS development?
27. RE: APRS Emergency packet e-mail
28. Re: APRS development?
29. KISS Setup
30. RE: KISS Setup
----------------------------------------------------------------------
Subject: Re: APRS Emergency packet e-mail (sorry about the repeat)
From: James Jefferson <jjeffers@aprsworld.net>
Date: Thu, 27 Mar 2003 23:09:24 -0600
X-Message-Number: 1
On Thursday 27 March 2003 10:47 pm, you wrote:
>Hi Dad, I thought you might find this interesting:
Sorry about the repeat. The send again button is a good thing, IF one change
the To: e-mail address!
-Jim KB0THN
----------------------------------------------------------------------
Subject: Re: my packets on findu.com
From: Bill Herrmann <bherrman@spro.net>
Date: Thu, 27 Mar 2003 22:55:25 -0700
X-Message-Number: 2
At 10:01 PM 3/27/2003 -0600, Matthew Werner wrote:
>I don't see it as being GPS error when the speed is reported as 42 and
>it's a new WAAS enabled receiver...
Don't be too sure (though I agree with your assessment) I was running a
handheld GPS in our minivan at one point and it reported the maximum speed
as 237mph. I did not know that stock minivans would go that fast....
(and this was most definitely a GPS error)
Bill
----------------------------------------------------------------------
Subject: Re: my packets on findu.com
From: "Matt Werner" <mwerner@duluth.com>
Date: Fri, 28 Mar 2003 00:32:32 -0600
X-Message-Number: 3
I was just looking at what xastir at home heard from the truck (which is
parked 20 yards away).
I have a report of 104, 138, and 182mph. Pretty good for a four cylinder
with 125k miles.
I wonder where the problem is - if it's in the TinyTrak or the GPS? I
hadn't noticed problems like this before with either, although both of them
have only been in service a few weeks.
I notice that it appears to report correctly when I'm actually moving.
Tomorrow I will have to go to the GPS and check what the max speed is in it.
I doubt however that I will see anything over 100.
----------------------------------------------------------------------
Subject: Re: [ Alex ] Re: Digipeating and fun with PIDs
From: <henk.de.groot@hetnet.nl>
Date: Fri, 28 Mar 2003 10:00:26 +0100
X-Message-Number: 4
Hello Curt,
From: "Curt Mills" <hacker@tc.fluke.com>
>only allow packets that meet the Control=0x03, PID=0x0f
>restrictions. Thanks for making me take another look at it!
Be sure that the P/F bit is stripped off from the control byte before
checking for 0x03, otherwise you will miss the UI frames that
have the P/F bit set...
As for the checks during the pocessing of the AX.25 packets from
the kernel interface, I wrote that part of the code... Its defensive
and only uses the data after checking its validity, just as Alex als
descibed for his code (and the same way DIGI_NED validates the
input). This method will withstand random junk packets.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Digipeating and fun with PIDs
From: "Laurie - g6isy" <g6isy@dsl.pipex.com>
Date: Fri, 28 Mar 2003 12:28:27 -0000
X-Message-Number: 5
Henk de Groot wrote:
>At 20:16 26-3-03 -0500, Steve Dimse wrote:
>>On 3/26/03 at 9:46 PM Scott.Miller@vandenberg.af.mil (Miller Scott
>>Contr 30SCS/FTI) sent:
>>
>>>The only clients that will be trying to interpret OpenTRAC data as
>>>APRS are those that totally disregard the AX.25 specification.
>>>Nothing is throwing random binary data at it - the client is
>>>CHOOSING to disregard critical AX.25 header information.
>>>
>>What AX-25 header information? If you mean the PID, that data is not
>>passed to the clients in terminal mode, which is by far the most
>>common mode in use.
>
>Yes, it is, the only data you get to see in terminal mode is data with
>PID=0xF0. You should never see other data in terminal mode. So you
>don't need the PID in the header, you know it is 0xF0 since it cannot
>be anything else...
Henk,
I'm afraid you are wrong on this point.
Most TNC's will display monitored packets for ALL PID's when in terminal
mode.
Early firmware will display all PID's. Later firmware usually has the
ability to supress PID's other than 0xF0 by using a command such as
PIDCHECK. However the default is for all frames to be accepted.
73 Laurie - G6ISY
----------------------------------------------------------------------
Subject: Re: APRS Emergency packet e-mail
From: WA2UZO <wa2uzo@arrl.net>
Date: Fri, 28 Mar 2003 07:44:38 -0500
X-Message-Number: 6
If you would rather run a Perl script locally than receive email you
can use APRSWatch as a starting point. You might want to tweak the
script but the concept is there for anyone looking for an alternative
solution.
http://home.earthlink.net/~zobkiw/#APRSWatch
From the description online:
APRSWatch opens a telnet stream to an APRS server and watches the
output for keywords that you specify. When one is found it is displayed
along with the APRS sentence that it was found within. You can
optionally send yourself an email when a keyword is found or ring the
terminal bell (see code for details). Inspired by PEAPRS, this
implementation could be extended to create a fully automated APRS
monitoring and early-warning system. More details of usage and options
in the code. This is an early proof-of-concept that can be extended
greatly.
Enjoy and 73.
WA2UZO
----------------------------------------------------------------------
Subject: APRS/CE
From: Timothy Brown-TM <Timothy.Brown@telus.com>
Date: Fri, 28 Mar 2003 08:53:00 -0500
X-Message-Number: 7
I stumbled across the APRS/CE web site a few weeks ago. Does anyone have
any experience with the beta version of the program? Are it's feature set
as rich as PocketAPRS? Any comments on the future of APRS/CE? Does the
Pocket PC platform or the CE/OS have any advantages over the Palm for APRS
related work?
73,
Tim Brown
VE3TMB
----------------------------------------------------------------------
Subject: Re: APRS development?
From: "Travis J. Maclay" <travis@btea.org>
Date: Fri, 28 Mar 2003 10:04:37 -0500
X-Message-Number: 8
Michael Amos wrote to the SIG:
>Funny, I've had a Registered Version of WinAPRS running for a month now and
>no lockup problems. Ran it on WinXP Pro and Win2kPro (Current) w/ no
>lockups, crashes, etc.
>
>Mike
>KG4NDS
>Atlanta, GA
Travis writes to Mark Fellhauer:
I must admit, I've downloaded all WinAPRS updates in the past as they've
come out, and on various machines, have had problems w/ machine lockups,
program errors, etc.
Now that I am running it on an XP machine, with P4 2.0GHz & 1 GB Ram, I have
had virtually no problems. The program (WinAPRS 2.6.1) stays up as long as
the computer stays up, which right now is going on 8 days.
Just a bit of info to possibly help piece together what might be happening
on your end.
Travis
N4TJM
----------------------------------------------------------------------
Subject: Re: Digipeating and fun with PIDs
From: <henk.de.groot@hetnet.nl>
Date: Fri, 28 Mar 2003 16:12:28 +0100
X-Message-Number: 9
>From: <g6isy@dsl.pipex.com>
>Henk de Groot wrote:
>>Yes, it is, the only data you get to see in terminal mode is data with
>>PID=0xF0. You should never see other data in terminal mode. So you
>>don't need the PID in the header, you know it is 0xF0 since it cannot
>>be anything else...
>Most TNC's will display monitored packets for ALL PID's when in terminal
>mode.
>Early firmware will display all PID's. Later firmware usually has the
>ability to supress PID's other than 0xF0 by using a command such as
>PIDCHECK. However the default is for all frames to be accepted.
That is bad news! The TH-D7 TNC did not display them.
This means that APRS cannot co-exist with use of other UI frame
use like TCP/IP and NetRom. Use of ALTNET does not solve this
problem since MIC-E also uses non "AP*" desitnation adresses.
I didn't like terminal mode use to begin with, but its even worse
than I though it was already.
Instread of using alt-net, maybe a non standard first byte of the data
can be used to discriminate between OpenTrac and APRS. The
APRS data types are determined by the first byte of data, maybe
OpenTrac can use 0x7F or something like that as first byte. That
should do the trick also, at the expense of one more data byte.
Alternatively it can also be encoded in one bit if OpenTrack starts
using a first byte in the range 0x80..0xFF, then is can still convey
a 7 bit value.
Kind regards,
Henk.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
