| |
ZL3AI > APRDIG 02.10.03 10:15l 262 Lines 10270 Bytes #999 (0) @ WW
BID : 2045-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 29, 1/12
Path: DB0FHN<DB0RGB<DB0MRW<DB0SON<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<VK6HGR<
VK3AVE<ZL2BAU<ZL3VML
Sent: 031001/1331Z @:ZL3VML.#80.NZL.OC #:9445 [Chch-NZ] FBB7.00i $:2045-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Monday, September 29, 2003.
1. THD7AG Problems
2. Re: Even cheaper GPS receivers
3. An alternative to the proposed "NEW WIDEn-N Paradigm"
4. Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
5. Re: LANn-N routing.
6. Re: LAN n-N routing.
7. Re: LANn-N routing.
8. Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
9. Cheap GPS RXs ?
10. Re: LANn-N routing.
11. Re: Cheap GPS RXs ?
12. aprsca.net down?
13. Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
14. Re: LANn-N routing.
15. Help with APRSd 2.2.5-14 and RedHat9
16. Re: Take Control of your DIGI part1
17. Re: Take Control of your DIGI part 3
18. Re: Take Control of your DIGI part 2
19. Re: Take Control of your DIGI part 4
20. Packet Path on TH-D7 suggestions
21. Re: Packet Path on TH-D7 suggestions
22. Re: Take Control of your DIGI part 4
23. Re: aprsca.net down?
24. Re: Take Control of your DIGI part 4
25. Re: Take Control of your DIGI part 4
26. Re: Take Control of your DIGI part 3
27. Re: Take Control of your DIGI part 4
28. Re: Take Control of your DIGI part 4
29. Re: Take Control of your DIGI (1)
30. Re: Take Control of your DIGI (2)
31. Re: Take Control of your DIGI (3)
32. cheap GPS receivers and the RS232 "standard"
33. Re: Take Control of your DIGI part 4 - dupe checking
34. Re: Take Control of your DIGI part 4
35. Re: Take Control of your DIGI part 4
36. Daydreaming...
37. Re: Take Control of your DIGI part 4
38. Re: LANn-N routing.
39. Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
40. Re: Take Control of your DIGI part 4
41. Re: Take Control of your DIGI part 4
42. Re: LAN n-N routing.
43. RE: Daydreaming...
44. Re: Take Control of your DIGI part 4
45. Re: cheap GPS receivers and the RS232 "standard"
46. Re: Take Control of your DIGI part 4
47. Re: Take Control of your DIGI part 4
48. Re: Take Control of your DIGI part 4
49. Re: Take Control of your DIGI part 4
50. Re: Take Control of your DIGI part 4
51. Fwd: Re: Take Control of your DIGI part 4
52. Re: Take Control of your DIGI part 4
53. Re: Take Control of your DIGI part 4
54. Re: Take Control of your DIGI part 4
55. palm digis was: Re: Take Control of your DIGI part 4
56. Re: Take Control of your DIGI part 4
57. Re: Take Control of your DIGI part 4
58. Re: Take Control of your DIGI part 4
59. LANS and ALOHA range...
60. Re: Take Control of your DIGI part 4
61. Re: Take Control of your DIGI part 4
62. Re: Take Control of your DIGI part 4
63. Re: Take Control of your DIGI part 4
64. Digipeater Duplicate Checking is broke
65. Re: Take Control of your DIGI part 4
66. Re: Take Control of your DIGI (3)
----------------------------------------------------------------------
Subject: THD7AG Problems
From: kd4ydc@juno.com
Date: Mon, 29 Sep 2003 09:07:46 GMT
X-Message-Number: 1
I asked this question a while back, had some responses...but just didn't
have time to fix it. Now more has happened;
First, the PC and GPS port went out.
Now, all the ports are out. (mic and speaker)
Any ideas where to look and has anyone had this problem before?
Thanks!
Robert
----------------------------------------------------------------------
Subject: Re: Even cheaper GPS receivers
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Mon, 29 Sep 2003 10:38:10 +0200
X-Message-Number: 2
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: An alternative to the proposed "NEW WIDEn-N Paradigm"
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Mon, 29 Sep 2003 06:48:34 -0400
X-Message-Number: 3
The original thread speaks to changing core-features of the APRS system
because there is a belief that (more than) a few users are saturating the
available bandwidth in some areas.
The problem is that the user's needs are (being perceived as) not being met
by the available technology. To arrive at a non-complex solution, it will
be important to re-read this last sentence carefully.
The solution to the problem lies in two areas:
o Modifying user behavior
- something that Riley Hollingsworth has been quite successful at doing
o Maximizing network capacity without breaking anything
- a philosophy that has served Kenwood users well for a number of years
All that is left is to determine how to operationalize the solutions (which
is where the heated discussions may begin). So...here goes nothing...
How does the APRS community go about modifying user behavior?
- think: communication first and the Wouff Hong/Rettysnitch second...it
works for Riley and can work for APRS through the magic of email and
SUPLIST to name just two)
How does the APRS community go about maximizing network capacity without
breaking anything?
- think: studying payload size, TXD, cellularizing digi cover-areas and
decaying TX intervals...and referring to 'user behavior' above...but
including digi operators among the group)
Regards,
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: An alternative to the proposed "NEW WIDEn-N Paradigm"
From: Wes Johnston <wes@johnston.net>
Date: Mon, 29 Sep 2003 07:15:43 -0400
X-Message-Number: 4
What if ..... you got dupes from a station which you knew was
LOCAL. Rather than dropping the packet on the floor if it's a dupe, modify
it's path (ie set the HID flag in all digipeater slots, and decrement all
wideN-N counters) so that it will not be digipeated by the next digipeater
in the chain. In this way, we have the ability to send as many redundant
packets as we want, ONLY in our LOCAL area. This way, if someone is
flooding our local network, we can get to him and wring his neck, but if we
really really need to flood our area, we can.
Wes
----------------------------------------------------------------------
Subject: Re: LANn-N routing.
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 29 Sep 2003 09:46:41 -0500
X-Message-Number: 5
>But if they changed UIFLOOD to
>something like NMn-N, then their users could use a path of WIDE,NM4-4 and
>know that their packets would cover the entire state, would NOT QRM
>surrounding states, and WOULD keep their state from seeing QRM from 800
>miles away.
Well, we are getting back to UUCP routing now, where you have to know every
magical thing about the network to get traffic beyond your 'machine'. I think
that this simple system has had its limits exceeded. There are too many full
time users for CSMA to really work. And, we appear to have more traffic than
1200 baud will handle in many areas. So, it seems like it is time to finally
create the new network.
We should adopt open-trac for use on all computer based systems immediately
and start a UHF overlay at 9600 baud. This would allow us to deploy a more
robust and extensible protocol for station to station traffic where we have
the ability to install new software immediately. There should be APRS to
open-trac relays established to let existing equipment be used.
We need to think about delayed digipeating to allow packets to accumulate and
reduce the effects of group delay etc on bandwidth availability.
I, personally, would like to see us switch from FM to SSB and use a form of
PSK for multi channel capabilities. We could use SSB at 15khz wide to allow 1
at 1khz plus 7 at 2khz segments to be utilized. 1khz for rendevous, and the
other seven, would be assigned and timed by the digi with incomming stations
asking the digi for a slot, and the digi handing out a segment and timeslot
based on the request from the station. The digi would be able to transmit on
all 7 at a particular time interval if needed to balance the availability of
inbound and outbound bandwidth.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: LAN n-N routing.
From: John <bigjohn45@cox.net>
Date: Mon, 29 Sep 2003 11:58:07 -0400
X-Message-Number: 6
At 09:46 AM 9/29/03 -0500, you wrote:
>
>>But if they changed UIFLOOD to
>>something like NMn-N, then their users could use a path of WIDE,NM4-4 and
>>know that their packets would cover the entire state, would NOT QRM
>>surrounding states, and WOULD keep their state from seeing QRM from 800
>>miles away.
>So, it seems like it is time to finally create the new network.
And who will pay for all the new hardware?
I remember the frequency change fund to support buying new crystals during
the move from 145.070 to 144.390. More recently I seem to recall a big
push to upgrade the Findu servers.
What is being suggested is far beyond either of these.
I think we need to focus on the core goals of APRS (think local) and fix
the immediate problems. I think Bob's idea is a good one as is Henks 29
minute dupe check for fixed non-local stations transmitting unchanged data
at to high a rate.
I suggested over a year ago that Digi_Ned could use path preemption to help
mobiles achieve their goals. The mobile simply states that goal as a
pseudo digi chosen from a published list of options. By placing this
pseudo digi at the end of the path the Intelligent Digi can act on it no
matter where it appears in the path while less smart digis simply ignore
it. This is already being done with the NOGATE and RFONLY pseudo digis
appended to paths.
I see two key issues:
Long paths from out of area stations QRMing local nets.
Client software that fails to educate the user on the impact of their actions.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
