| |
ZL3AI > APRDIG 02.10.03 10:10l 228 Lines 9566 Bytes #999 (0) @ WW
BID : 2051-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 29, 7/12
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0BI<DB0NOS<DB0EA<DB0RES<ON0AR<
LU6DTS<ZL2TZE<VK3KAY<ZL2BAU<ZL3VML
Sent: 031001/1402Z @:ZL3VML.#80.NZL.OC #:9451 [Chch-NZ] FBB7.00i $:2051-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: cheap GPS receivers and the RS232 "standard"
From: "KENT HUFFORD" <khufford@comcast.net>
Date: Mon, 29 Sep 2003 17:50:40 -0400
X-Message-Number: 32
Yes, that would make a rs232 "standard" port happy.
However, I've only been wiring up GPS's to RS232's since 1994. I have never
found a computer or program that cared about those other connections. The
only ones coming out of the GPS is send/receive, ground and +DC. So, all
I've ever hooked up were pins 2,3 and 5 in a DB9... They all have worked.
Might someday run into one, but have not yet for GPSs.. (some GPSs have a
whole "other side" B, with more wires, but have never need to use them)
AND, I just got a TINYTRACK III. ALL it wants is ground and pin
2(DB9)(Brown) from the GPS.
BUT, of course, the DIGITRAVELER needs some voltage on the red wire to turn
it on. I feed it +5v that I also feed the GPS to run it, instead of the 3
AAA batteries.
73s
Kent
KQ4KK
-----Original Message-----
From: Henk de Groot
Sent: Monday, September 29, 2003 4:38 AM
Subject: [aprssig] Re: Even cheaper GPS receivers
At 17:51 28-9-03 -0400, KENT HUFFORD wrote:
>PDA software version is 20-1601
>PC version is 20-1602
>Only difference is the connectors and software.
>Cut off the end of the PDA cable, black wire to pin 5, Red to 3 and
>Brown to pin 2 of a DB9.
To be fool-proof also short circuit RTS and CTS (so it will work even if
hardware-flowcontrol happens to be enabled) and short circuit DTR, DSR and
DCD (so it even works if the software checks for a carrier-detect signal).
I always make these connectons in the DB9 connector when making a 3 wire
RS232 link. It can save a lot of problems figuring out why the cable
doesn't work...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4 - dupe checking
From: "Bill Vodall - WA7NWP" <wa7nwp@jnos.org>
Date: Mon, 29 Sep 2003 14:59:58 -0700
X-Message-Number: 33
>>UIDIGI also misses the boat on this one. The dupe checking on the
>>network also misses the boat on this one. Your suggestion of weighing
>>only the payload is a great idea!
I'm not sure on UI-DIGI's dupe checking. I'd guess he does it right since
there's been some current development efforts.
From past discussions here, the current Kantronics implementation does
correct dupe checking on the SOURCE and PAYLOAD fields of WIDEn-n and
TRACEn-n packets. The problem is they (Kantronics) don't check simple
RELAY and WIDE packets.
DIGI_NED has it correct and works great.
>Unfortunately, we have to live with
>>the hardware we have now (reality) until it can be updated or completely
>>verified.
I believe it's time to quit trying to do magic with the old, small, closed
source TNC style digipeaters and use real software (DIGI_NED and hopefully
even smarter offspring) with real computers. When there isn't much
traffic, the TNC's work fine. Here in the busy metro area - we need
better.
73,
Bill - WA7NWP
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Mon, 29 Sep 2003 17:35:20 -0500
X-Message-Number: 34
>>UIDIGI also misses the boat on this one. The dupe checking on the
>>network also misses the boat on this one. Your suggestion of weighing
>>only the payload is a great idea! Unfortunately, we have to live with
>>the hardware we have now (reality) until it can be updated or completely
>>verified.
>
>Nope, it works perfectly. Callsign substitution assures that no packet
>will be digipeated TWICE by the same digi. It is just as effective as
>WIDE2-2. Any other copies of a packet that people see are just more
>copies, not dupes...
I am not disagreeing that callsign substitution is good if it works as you
explain it should work. However, the reality of how it works with the local
Kantronics and UIDIGI systems changed my mind completely based on the
reality of what it really does. What the digi's perform and what you
explain do not match. That is why we are disagreeing. Please go back to the
example. Better yet, let me paste here again:
KE4ROC-9>BEACON,RELAY,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,RELAY*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,W4GPS-7*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,W4GPS-7,WIDE*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,WC4ADG*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,WC4ADG,WIDE*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
KE4ROC-9>BEACON,RELAY,W4SBO-7*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX
StationKE4ROC-9>BEACON,WC4ADG,W4GPS-7*,WIDE/1:!3440.31N/08633.13W_Remote U2000
WX Station
KE4ROC-9>BEACON,RELAY,W4SBO-7,W4GPS-7*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
KE4ROC-9>BEACON,WC4ADG,W4SBO-7,W4GPS-7*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
KE4ROC-9>BEACON,WC4ADG,W4GPS-7,WIDE*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
This is far to much duplication. Extend this on out to another part of the
DX network and the problem continues to expand. There is all kinds of
duplication going on here with callsign substitution. It is simply broken!
In other words it does not work like you explained it should work.
Go back at look at the explanation and tell me that callsign substitution
works (reality check). The Kantronics failed. The UIDIGI failed. Even Findu
cannot identify a duplicate packet when the path has been altered by
callsign substitution. Hence, my statement to eliminate callsign
substitution, because it does not work like you think it should work. It is
going to take a long time to get the firmware fixed in the digipeaters
(reality). If callsign substitution worked the way you explained it, we
would not be having this discussion and there would be no problem. Since it
does not work the way you explained that is why we are not agreeing. Trust
me, I am not flapping in the wind on this issue. That was my whole point
and the reason for the conclusion to eliminate callsign substitution.
Since the digi hardware does not work as callsign substitution should work
in your explanation, my conclusion is also based on making what we have in
the field work for us.
Tim - N8DEU
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 29 Sep 2003 17:54:38 -0500
X-Message-Number: 35
>Better yet, let me paste here again:
>
>KE4ROC-9>BEACON,RELAY,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
>KE4ROC-9>BEACON,RELAY*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Station
>KE4ROC-9>BEACON,W4GPS-7*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Stati
on
>KE4ROC-9>BEACON,W4GPS-7,WIDE*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Stati
on
>KE4ROC-9>BEACON,WC4ADG*,WIDE,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Statio
n
>KE4ROC-9>BEACON,WC4ADG,WIDE*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Statio
n
>KE4ROC-9>BEACON,RELAY,W4SBO-7*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Stat
ion
>KE4ROC-9>BEACON,WC4ADG,W4GPS-7*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX Sta
tion
>KE4ROC-9>BEACON,RELAY,W4SBO-7,W4GPS-7*/1:!3440.31N/08633.13W_Remote U2000 WX S
tation
>KE4ROC-9>BEACON,WC4ADG,W4SBO-7,W4GPS-7*/1:!3440.31N/08633.13W_Remote U2000 WX
Station
>KE4ROC-9>BEACON,WC4ADG,W4GPS-7,WIDE*/1:!3440.31N/08633.13W_Remote U2000 WX Sta
tion
>
>This is far to much duplication.
When I go to findu and request 100 stations within 100 miles of W4GPS-7 I
see that there are perhaps way too many digis in the area. And, perhaps
even worse, perhaps many do not have dwait=0. If there are 14 digis that
hear my packet with RELAY,WIDE as the path, and many do not have DWAIT=0
set, then they will each take up a slot digipeating the packet, and you
will see each of the digipeating it as you do in your list.
Those not doing substition are hiding their presense in your list making it
more difficult to see the real issues. DWAIT=0 is a big issue when you
have as man digis as I see in that list. All of them must transmit at the
same time, or else there will be way too many copies of the packet visible
to other, possibly broken digis, and sure enough, it will take 30 seconds
for a single packet to be digipeated...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Daydreaming...
From: "Richard Amirault" <ramirault@erols.com>
Date: Mon, 29 Sep 2003 18:59:37 -0400
X-Message-Number: 36
I was daydreaming today ... and had a wonderful thought ;-) ....
I use APRSDos to run my 24/7 WX station. I've never used any other ARPS
program (except PocketAPRS) and I don't see any reason to change now. I do
run a D-700 however, so I'm not totaly in the dark ages.
And of course, I've been reading all the differing "opionions"on this list
for years now.
GEE, wouldn't it be nice if we could say, "If you want to run APRS then
FIRST you have to learn and use APRSDos for 3 months .. before you can use
any other version."
Of course it will never happen (nor should it) but it might educate a few
folks. Oh well...
Richard Amirault N1JDU Boston,
MA, USA
www.erols.com/ramirault "Go Fly A Kite"
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
