| |
ZL3AI > APRDIG 02.10.03 10:21l 284 Lines 12552 Bytes #999 (0) @ WW
BID : 2053-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 29, 9/12
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<VK6HGR<VK3AVE<
ZL2BAU<ZL3VML
Sent: 031001/1410Z @:ZL3VML.#80.NZL.OC #:9453 [Chch-NZ] FBB7.00i $:2053-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Take Control of your DIGI part 4
From: "Bill Vodall - WA7NWP" <wa7nwp@jnos.org>
Date: Mon, 29 Sep 2003 16:38:27 -0700
X-Message-Number: 44
>I would be the UIDIGI can be fixed quickly. I might lose my breath on
Kantronics.
>Not everybody is going to switch to DIGI_NED even though it works as Bob has
>explained.
>
>In this event if you want commonality in a network you have to go with the
least>common denominator. We know what that suggests, but can we bring ourselves
>down to it as a starting point the reality of what can be done now.
I now consider DIGI_NED as the least acceptable level of digipeater for a
busy area. While it probably would be possible to eventually realize
acceptable basic APRS packet functionality with UIDIGI, it is too limiting.
With real software and hardware we can do great new things. IM!HO it's
time to quit being cheap and making excuses for poor performance. It's
time to make some serious progress.
The strongest argument for my suggestion is the very existence of this
discussion. After all these years we're still dealing with digipeater and
path issues.... It's time to fix it and move on.
73,
Bill - WA7NWP
----------------------------------------------------------------------
Subject: Re: cheap GPS receivers and the RS232 "standard"
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Mon, 29 Sep 2003 19:51:02 -0400
X-Message-Number: 45
Well, I won't say how long I've been playing with GPS, but I will say that
I had some of the early prototypes for laptops...
The 'extra' connections on the serial port are NOT needed for most
canned software. But if someone wants to monitor the data stream with
other 'standard' tools, or even write their own software to do things,
having the signals 'pulled true' can make it much easier when you're in
a crunch. It's simple, especially when it's done when it doesn't matter.
When you're trying to debug something that's NOT working is NOT
the time to find you can't use simple tools at your disposal to debug
something.
But then, if you're just a 'user' and never try to do anything out of the
ordinary other than with canned software...
Mike
----- Original Message -----
From: "KENT HUFFORD" <khufford@comcast.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Monday, September 29, 2003 5:50 PM
Subject: [aprssig] cheap GPS receivers and the RS232 "standard"
>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.
>
>Kent
>-----Original Message-----
>
>>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).
>>Ialways make these connectons in the DB9 connector when making a
>>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
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Mon, 29 Sep 2003 19:14:35 -0500
X-Message-Number: 46
>The strongest argument for my suggestion is the very existence
>of this discussion. After all these years we're still dealing with
>digipeater and path issues.... It's time to fix it and move on.
Wasn't Mike Musick going to do something palm based along these lines?
I'd have a tough time siting a PC at my digi, but a palm pilot would be no
trouble at all.
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 29 Sep 2003 20:14:54 -0400 (EDT)
X-Message-Number: 47
On Mon, 29 Sep 2003, Tim Cunningham wrote:
>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.
Nope, what you and everyone else seems to be missing, is that it is NOT the
fault of callsign substition per se, it is many faults compounded:
1) SYSOPS who dink with the Dwait parameter. All DIGIS in an APRS system
MUST have the default D-WAIT of 0!!! Some well meaning, but not
thoroughly understanding SYSOPS have dinked with the D-Wait parameter to
try to make sure that the same packet from two digipeaters DONT collide.
DUH! The are SUPPOSED to collide. It is called fratricide and is part of
the dupe elimination foundation of APRS.
2) WIDEn-N propogation of hundreds of copies of every packet. THus if
there are two original digis, then there are hundreds of copies of both
and they are GUARANTEED if the sysops have changed Dwait from 0!
Get back to 2 hop RELAY,WIDE and WIDE,WIDE propagation as the default and
set no path greater than will hit the maxmimum capacity of the 1200 baud
channel (50 users in an RF LAN) and it will work just fine. There will be
2 dupes if 2 digis hear the original packet, but they only go to each
other and no further! Only ONE copy goes outward to the seccond tier, yet
those close in get TWO copies which was ALSO part of the design of APRS
to assure higher reliability of delivery in the local area.
>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:
Sorry, these examples are no good!
1) They still have RELAY digis that are not doing callsign substitution.
2) THey are 3 hop paths
3) The proper effect of a 3 hop path in a system where every digi
typically hears 3 other digis is about 21 copies (because there are 21
digipeaters within 3 hops of the source)...
How many of the below are those 21 correct ones?
You cant tell because of the unattributed RELAYS at the start.
>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
Station
>KE4ROC-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
Now, lets eliminate the unattributed RELAYS and the unattributed WIDES
and reduce it to my recommended 2 hops look what's left!
>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,W4GPS-7*,WIDE/1:!3440.31N/08633.13W_Remote U2000 WX
Station
And we see that the station that copies these packets can hear both the
W4GPS and WC4ADG digipeaters and there was ONE dupe. Big Deal! And by
getting everyone back to the LOCAL concept of APRS, there is now 6 times
more channel capacity because:
1) There are fewer copies flying all over the place (3) (we can no longer
afford 21 copies of EVERY 3 hop packet transmitted!)
2) DX stations more than 2 hops away (the DOZENS of users surrounding
EACH of the 6 digis that are out in the 3rd tier) are no longer QRM'ing
your LAN!
Like I say, APRS is a local real-time system operating at 1200 baud. It
will work if used propoerly. It is NOT being used properly and nothing
short of reducing the number of HOPS of all users back to only a LOCAL
phenomenon is going to fix it.
Once you accept that premis, arguing over dupes is wasted energy. You
gain so much, in reliabilty, and lack of QRM, with full path tracing of
every packet, and redundant delivery to improve reliablity all come for
FREE...
>This is far to much duplication. Extend this on out to another part of
>the DX network and the problem continues to expand.
Ah , but we can NO LONGER be operating APRS on the DX concept! No packets
should EVER go any further than to hit the surrounding 50 users or you are
QRMing their LANs...
>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.
Nope, you are still not implementing it right. You are trying to do what
I say is RIGHT but in a totally broken system. I agree with your results.
and that is what I am trying to fix. The BROKEN network and the
missguided expectations that are impossible on a shared 1200 baud channel.
>Findu cannot identify a duplicate packet when the path has been altered
>by callsign substitution.
wrong conclusion. The path is not involved in dupe elimination in FINDU.
Else it couldnt even separate the WIDE3-2 from the WIDE3-1 packet. Only
the FROM and the payload are part of dupe checking in FINDU...
>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).
We dont have to change any firmware. a SYSOP can implement my
recommendaitons immediately via remote sysop. ALl he has to do is
1) ONLY use WIDEn-N in areas where N>3 can be used to advantage and
where the surrounding 21 digipeaters TOTAL support less than 50 users
(find me such a place)...
2) OR, devise LINKn-N chains where 1 WIDE3-3 packet does not generate 21
copies in all directions, but only generates 3 copies in ONE direction.
3) OR, devise LANn-N networks of X digis where X supports a general LAN on
the order of 50 users or so, and then N doesnt matter, becauses you will
get X copies to everyone and it will not QRM anyone else
4) Turn off WIDEn-N in your area if DX QRM is killing you.
5) Make sure that RELAY and WIDE are enabled and ONLy in callsign
substituting digis.
6) Start educating users to use RELAY,WIDE and WIDE,WIDE and any long
paths of W,W,W,W,W are BAD PRACTICE and not welcome... They may use
WIDEn-N as much as they want. It will work where it can be afforded, but
it will not damage areas where it cannot be tolerated.
That will make APRS work well in the area of a local LAN of about 50
users. Remember, this 50, includes 16 mobiles in motion. If you dont
need to support that many mobiles, then the LAN can contain up to 100 or
more.... I promise you though, nothing else will fit on the 1200 baud
channel...and still work reliably... Yes, you can stuff more in there,
but the probability of getting a single packet from user A to user B
(message lines) soon becomes impossible and APRS does not work for what it
was designed for...
>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.
And that is exactly what I am doing. Make what we have work, the way it
was designed and using what we have. We can no longer be flooding the
network beyond our own ALOHA circle in our own local LAN
P.S. Yes, back when there were only 50 users spread over 5 states in the
mid-atlantic, WIDEn-N looked like a pretty good idea. But now, in 2003
with 20,000 uers, and with IGates everywhere, we can no longer USE IT AS
IT HAS BEEN USED. We MUST change the WIDEn-N paradigm.
I think the concepts for the new WIDEn-N paradigm will work but only if
fully implemented and not hacked beyone recognition by well meaning but
not thoroughly considered impacts by some local sysops...
Bopb, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
