| |
ZL3AI > APRDIG 04.05.03 19:16l 251 Lines 9661 Bytes #999 (0) @ WW
BID : 1238-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 27, 1/4
Path: DB0FHN<DB0ZWI<DB0HDF<DB0ERF<DB0MRW<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<VK7AX<
ZL2BAU<ZL3VML
Sent: 030430/1331Z @:ZL3VML.#80.NZL.OC #:64846 [Chch-NZ] FBB7.00i $:1238-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Sunday, April 27, 2003.
1. RE: Ver.2: Another thing I'd like to see..
2. Re: Multiple Sound Cards
3. Re: PCSAT2 on the air
4. Re: Ver.2: Another thing I'd like to see...
5. Re: PCSAT Question
6. RE: Ver.2: Another thing I'd like to see...
7. Re: Recommendations
8. RE: Recommendations; Was: Just trying to understand.
9. Re: wide?
10. Re: Recommendations; Was: Just trying to understand.
11. Re: PCSAT2 on the air
12. Re: wide?
13. PCsat turned OFF.
14. RE: Recommendations; Now WIDE path
15. Re: Ver.2: Another thing I'd like to see...
16. Re: Ver.2: Another thing I'd like to see...
17. d7a power plug
18. Filtering of Internet feed?
19. RE: Ver.2: Another thing I'd like to see...
20. K0FAO-5>EMERGENCY
21. Re: Filtering of Internet feed?
22. Re: Filtering of Internet feed?
23. RE: Ver.2: Another thing I'd like to see...
24. Re: [ BobDonnell@arkalmus.com ] Re: [ "Curt Mills, WE7U" ] Re: Another
thing I'd like to see...
25. AX.25 & TCP/IP [was: Another thing I'd like to see...]
26. Re: Filtering of Internet feed?
27. Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
----------------------------------------------------------------------
Subject: RE: Ver.2: Another thing I'd like to see..
From: "Darryl Smith" <Darryl@radio-active.net.au>
Date: Sun, 27 Apr 2003 20:23:51 +1000
X-Message-Number: 1
From: "Ev Tupis (W2EV)" <w2ev@arrl.net> made some comments...
>First, a huge thanks to taking the time to lay out the issues. My
>question was based in true inquiry and not tongue-in-cheek.
You never can tell :-)
>It appears to me as if the "problems" of connected mode are rooted in
the way the hobby has
>implemented it, rather than the mode itself. The question then
becomes, "Is there a different
>implementation that would showcase its advantages and minimize its
disadvantages?".
Seems to me that messaging on a low bandwidth network such as APRS has
some issues... Even for messaging... Lets have a think...
1. Channel Setup requires 2-3 packets
2. Every packet transmission requires an Ack, and a retry if the ack
does not go through
3. Channel Keepalive takes some packets
4. Channel takedown takes some packets
>"Is there a different implementation that would showcase its
advantages and minimize its disadvantages?".
Can we develop a protocol that is more suited to this type network?
Maybe even maintain compatibility with most applications?
Umm... Lets see. Lets get rid of the channel setup, and assume that the
setup is there... Also the same with the takedown. Keepalive is not all
that useful too if you don't have takedown.. Connected mode does not
work well...
So we need to either do a Connected Mode with no overhead, or a UI mode
with stuff built on like existing APRS. Assuming that we don't want to
go with the UI mode, how about some type of Connected or Acknowledged
UI... A new packet type that sends an ACK when receieved.... And allows
the application program to determine what happens next...
Darryl
---------
Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International]
Darryl@radio-active.net.au | www.radio-active.net.au
----------------------------------------------------------------------
Subject: Re: Multiple Sound Cards
From: Hamish Moffatt <hamish@cloud.net.au>
Date: Mon, 28 Apr 2003 00:24:20 +1000
X-Message-Number: 2
Sorry, late reply here.
On Mon, Apr 21, 2003 at 01:24:06PM -0500, Mark Fellhauer wrote:
>Getting two soundcards to work together is almost as much fun as getting
>two video cards to work together. The main problem is that if you put a
>PCI video card into a system with an AGP video card, the PCI card is always
>asserted as the "primary" video solution, when obviously you want the AGP
>card to be the primary. Why they don't/can't make a motherboard with two
>AGP slots is beyond me... At least they make dual-head video cards.
Standard Award BIOS (on most clone PCs) has an option to choose whether
the AGP or PCI video card is the primary. Set it to AGP and off you go.
Works well in Windows and XFree86.
I've been running dual-head this way for a year or more. I had a single
dual-head AGP card before that but overall it wasn't as good - the
second head was limited and the 3D performance of the overall card was
less than stellar.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
----------------------------------------------------------------------
Subject: Re: PCSAT2 on the air
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 27 Apr 2003 15:57:13 -0400 (EDT)
X-Message-Number: 3
On Fri, 25 Apr 2003, Reid Crowe wrote:
>I assume PCSAT2 is NOT in space. Is that correct?
>
>Bob Bruninga <bruninga@usna.edu> wrote:PCSAT2 is on the air for its 200
>hour pre-flight burn in test. Now scheduled for flight on ISS in
>September, it should be a fun payload.
Yes that is correct
Bob
----------------------------------------------------------------------
Subject: Re: Ver.2: Another thing I'd like to see...
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 27 Apr 2003 15:58:31 -0400 (EDT)
X-Message-Number: 4
On Fri, 25 Apr 2003, Ev Tupis (W2EV) wrote:
>>Then you need the whole AX.25 protocol stack, and APRS software isn't
>>designed to support connected-mode operations.
>
>I wonder why APRS hasn't exploited the advantages of connected mode
>more. Hmmm.
Because connected mode is terrribly innefficient for delivering lots of
infomration between everyone at once.
Bob
----------------------------------------------------------------------
Subject: Re: PCSAT Question
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 27 Apr 2003 16:20:11 -0400 (EDT)
X-Message-Number: 5
On Fri, 25 Apr 2003, Dakota Summerhawk wrote:
>What is the best [elevation] degree for hitting PCSAT?.... I was
>thinking about 10 or 15... Can someone give me a hint?
For each elevation degree there is a calaulatable probability of passes
in that range. 30% of all pass times are 10 degrees or below. 67% of all
pass times are 20 degrees or below. About 95% of all pass times are below
45 degrees,etc.
But then also, the DISTANCE to the bird is inversly proportional to
elevation angle as well. Below 10 degrees the bird is 3000 km away. At
30 deg she is half that far or 6 dB stronger.
See my http://www.ew.usna.edu./~bruninga/rotator1.html for a table.
For PCsat where your objective is to just get your wilderness position
into the bird once a pass, I'd set for 30 degress as about the best.
This is why a 1/4 vertical whip over a metalic ground plane (car roof)
does so well for low earth orbiting satellites. It combines the closer
pass, and peak lobe of the antenna for best mobile performance..
Notice that this is NOT your typical mobile dual-band "gain" antenna that
puts most of its gain at the horizon. In fact, a 5/8ths wave antenna has
a BIG null between 15 to 30 degrees where the satellite spends 35%
of its time! and where it is 6 dB stronger!
See the plot near the bottom of
http://www.ew.usna.edu/~bruninga/astars.html
de WB4APR, Bob
----------------------------------------------------------------------
Subject: RE: Ver.2: Another thing I'd like to see...
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 27 Apr 2003 16:40:57 -0400 (EDT)
X-Message-Number: 6
On Sat, 26 Apr 2003, Ev Tupis (W2EV) wrote about connected mode in APRS:
>It appears to me as if the "problems" of connected mode are rooted in
>the way the hobby has implemented it, rather than the mode itself.
No it has nothing to do with implementation, it has to do with ACKS. APRS
is for distributing small bits of informaiton to EVERYONE on the net. If
that is 100 people, then APRS can do that with ONE PACKET. In connected
mode it would take 101 packets with PERFECT delivery. Hundreds with
retries...! A lot compared to ONE...
APRS was designed to send packets redundantly. A new packet is
transmitted once, then a second copy is transmitted 16 seconds later, and
another 32 seconds after that. The period DOUBLES after every
transmission. After 6 tries you are down to only one packet in 10 minutes
which is the net cycle time for special events.
Thus NEW data is transmitted quickly with frequent redundancy, but old
data uses up less and less air time. Yet a new participant into the
network will get fully updated with everything going on in at least 10
minuets.
UNFORTUNATELY, many client software programs ignored this fundamental
principle and so they only transmit the same packet over and over at a
fixed rate. This ruins the fundamental design concepts of APRS in two
ways. It makes no distinction between NEW fresh data that needs to be
transmitted quickly and OLD stale data that is of less and less
importance and only adds QRM to the channel.
It is too bad that some of the most popular APRS programs ignored this
fundamental design principle of APRS..
That is why stations that run APRSdos or other programs that properly
implemented the decay-algorithm, can send Keyboard messages Quickly with
as little as 8 second turn around per line, while some of the more popular
programs take many minutes becuase they only do a RETRY once a minute...
And if stations implemented the REPLY-ACK algorithm (like APRSdos and
some others) then messages really FLY an order of magnitude faster than in
some of the more popular programs in a dialog situation.
APRS is for tactical REAL-TIME information. Not for 24/7 moniroing of
nothing happening.
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
