| |
ZL3AI > APRDIG 03.10.03 09:37l 217 Lines 9010 Bytes #999 (0) @ WW
BID : 2061-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 4/16
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1354Z @:ZL3VML.#80.NZL.OC #:9558 [Chch-NZ] FBB7.00i $:2061-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Cheap GPS receivers / RS232 / Digitraveller
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 30 Sep 2003 08:42:23 -0700
X-Message-Number: 11
>I cleaned out one local xx's whole stock of 2 of these. Quite the deal.
I've scrounged up four myself so far. I think one store in town's got at
least one left.
>First thing I did when I got mine home was crack it open. You can see where,
Bah. I had mine open before I was out of the parking lot. =]
>board. This is the wire that needs any voltage other than 0V in order to
I think it requires a minimum of 1 volt...
>through the nomal power port. Note that that GPS doesn't have its own
>voltage regulator, and the specs say it needs 6v. 5v from the 7805 appears
>to work just fine.
The 3 AAA cells provide 4.5 volts - 3.6 with rechargables, and it seems to
work on that. You could also bypass the rectifier to eliminate a bit of
voltage drop.
I modified one unit that I needed TTL, non-inverted signals from... it was
just a matter of pulling the RS-232 transceiver and soldering jumper wire
between the input and output pads.
>I used a 1 amp version of the 7805 since that's what I had laying around,
>but since the GPS draws 75mA max, you could replace it with the lower
>current, smaller package version with no ill effects.
I built an adapter board that plugs into the TT3 and supplies 6 volts to the
GPS with a 7806 regulator, but for some reason the TT3 stays in its
blinking, GPS invalid state forever. Haven't had a chance to troubleshoot
it. The internal regulator sounds like a better setup anyway, and would
take less space.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: UIDIGI and DWAIT setting
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 30 Sep 2003 08:54:41 -0700
X-Message-Number: 12
>What happens to the person who resides between the two digi's during
>adigipeat operation heard by both digipeaters. The probability they will
>not decode the packet is great.
I seem to be seeing just that... one digi's got a non-zero dwait
apparently, because it always comes in like 200 msec after the first one.
Gotta put the TNC in PASSALL one of these days (with the IGATE off) and see
what I can find out. If that fails, the only other way I've got to decode
the packets and prove which digis are doing it is to run it through my 2211
decoder, capture the binary output, and decode it by hand on the 'scope
display. Not fun, but I've already got slips of paper marked off at 1-bit
intervals for the purpose.
>Would you want that behavior in a system that might used in a life or death
>situation?
Nope, and IMHO that's not how APRS should be used - at least, not as a
primary system. It's not an 'operational' message system. The military,
at least, makes a strong distinction between those systems suited for
convenience and administrative use, and those engineered for battlefield
operations and command-and-control.
That's not to say we shouldn't do something about the problems we see in
the system...
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Cheap GPS receivers / RS232 / Digitraveller
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Tue, 30 Sep 2003 11:55:05 -0400
X-Message-Number: 13
Hmm, can someone tell me if the software that comes with the thing
(the PDA version) works on a Palm IIIc???
Mike
----------------------------------------------------------------------
Subject: Re: Cheap GPS receivers / RS232 / Digitraveller
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 30 Sep 2003 09:16:59 -0700
X-Message-Number: 14
I'm pretty sure it does, as long as you've got the memory to hold the maps.
Not sure if it comes with the right cable, though.
----- Original Message -----
From: "Mike Yetsko" <myetsko@insydesw.com>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, September 30, 2003 8:55 AM
Subject: [aprssig] Re: Cheap GPS receivers / RS232 / Digitraveller
>Hmm, can someone tell me if the software that comes with the thing
>(the PDA version) works on a Palm IIIc???
>
>Mike
----------------------------------------------------------------------
Subject: Re: Digipeater Duplicate Checking is broke
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 12:21:00 -0400 (EDT)
X-Message-Number: 15
On Mon, 29 Sep 2003, Tim Cunningham wrote:
>What I hear you say is that we need to obsolete these old digi's with
>firmware that do not support callsign substitution. I can agree with
>the obsolescing part. The bigger problem is the dupe checking.
>
>1. Can you agree that packet dupe checking is broken from the example?
No. A callsign substituting digi will never retransmit a packet that it
has already transmitted. That is the dupe checking algorithm of
callsign substitution and it works.
>2. Both UIDIGI and Kantronics fail to dupe check altered packets caused by
>callsign substitution. Can you agree with this statement?
No. This is also not true. A callsign substituting digi will never
retransmit a packet that it has alreayd transmitted.
>If the answer is yes to both of the above questions, then we are in
>agreement so far. The data really supports that dupe checking is broken.
Nope, what is broken in this case is your definition of "dupe checking".
Lets say we have two digis A and X. A can hear B and C, And X can
hear Y and Z. But both A and X also hear each other. Now if Only A or X
hears a packet, then with callsign substitution the packet propogates
outward with no dupes. But if both A and X hear the initial packet, then
they will BOTH respond.
But, unless the SYSOPS have HACKED the D-WAIT parameter, then these will
always occur at the same instant and neither A nor X will hear the other
one's copy. Thus the dupe is killed by fratricide. Yet, both packets
will be digipeated by the next tier of digis, B and C, and Y and Z and
there are no dupes to them, or beyond.
What is happening in some areas is that well meaning, but not fully
understanding local sysops have dinked with the D-WAIT paramter to make
sure that their digis will NOT collide if another digi is digipeating the
same packet. They have, in efffect, ASSURED that all copies of all
packets will never collide and so you will hear the maximum number of
dupes as each digi waits for other digis before it does. This is BAD.
D-WAIT in APRS is supposed to be 0.!
Further. Even if both A and X do digipeat the other's packet, the path is
now ONE hop shorter and so B, C, Y and Z do NOT further propagate this ONE
set of dupes. THey die where they were born, in the vicinity of the
INCORRECTLY SET DIGIs. What you are seeing is when you tack on a WIDE3-3
hop on the end of a callsign substituded dupe. Yes, your WIDEn-N will
FLOOD the network with those copies.
This is why we must get back to basics:
1) Use no longer than 2 hop GENERIC paths beginning with RELAY or WIDE.
2) Change the WIDEn-N paradigm
3) Longer paths of 3 or more hops need to be specific, either using the
LINKn-N, LANn-N or WIDE,WIDE,DIGI3 kinds of paths.
4) Make sure all D-Waits are set to the defualt of 0.
>Now, with this in mind, you are advocating that we employ callsign
>substitution. This is not a problem in itself. The problem is the havoc
>it creates in a local and * distant * network since dupe checking is
>broken when dealing with packet paths that have been altered by callsign
>substitution.
AH, we must get away from the idea that every packet is supposed to go to
DISTANT networks. With the density of APRS on the 1200 baud 144.39 in
the USA, we cannot possibly afford to do that any more...
>Removing callsign substitution at this point based on the reality of
>what we know about dupe checking improves the problem caused by callsign
>substitution. Can you agree with this statement?
Not at all. Doing so is just another local hack that destroys the
fundamentals of APRS, overloads all local areas with out-of-area packets
that it cannot possibly support, and is why APRS is basically impossible
to use as intended as a RELIABLE LOCAL REAL-TIME SYSTEM.
>Wheetter performance of long haul WIDEn-N generic traffic through areas
that can support it. And no stigma attached to such use.
8) Automatic QRM limiting for LANn-N routing to only X copies for X
digipeaters independent of N.
9) Full length LINKn-N routing with only worst case 7 copies instead
of 100 to 200 copies.
Bottom line. We CANNOT continue with busiiness as usual. The APRS network
is broke, and getting worse with local HACKS killing fundcionality and just
too many packets.. Currently reliablity under stress just doesnt work.
We have to change the way we think. Focusing too much on one or two extra
LOCAL-ONLY dupes while ignoriing the other 94% of the problem is just
barking up the wrong tree...
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
