| |
ZL3AI > APRDIG 04.05.03 19:42l 219 Lines 9774 Bytes #999 (0) @ WW
BID : 1243-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 28, 1/3
Path: DB0FHN<DB0ZWI<DB0HDF<DB0ERF<DB0FBB<DB0GOS<DB0EEO<PI8DAZ<PI8WFL<ON0AR<
ZL2BAU<ZL3VML
Sent: 030501/1342Z @:ZL3VML.#80.NZL.OC #:64895 [Chch-NZ] FBB7.00i $:1243-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Monday, April 28, 2003.
1. Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
2. RE: Ver.2: Another thing I'd like to see...
3. Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
4. Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
5. findu Down???
6. Re: findu Down???
7. RE: findu Down???
8. Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
9. Re: [ wes@johnston.net ] Re: AX.25 & TCP/IP [was: Another thing I'd like to
see...]
10. Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
11. Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
12. Re: Filtering of Internet feed?
13. Re: Filtering of Internet feed?
14. Re: Filtering of Internet feed?
15. Filtering of Internet feed?
16. Re: Filtering of Internet feed?
17. Re: Filtering of Internet feed?
18. Re: Filtering of Internet feed?
19. Re: Filtering of Internet feed?
20. Re: Filtering of Internet feed?
21. Santa Maria IGATE back online
----------------------------------------------------------------------
Subject: Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
From: Gerry Creager N5JXS <gerry.creager@tamu.edu>
Date: Sun, 27 Apr 2003 23:12:14 -0500
X-Message-Number: 1
I suspect we're about to engender a flame war, but...
I tend to agree that Layers 3 & 4 need to migrate toward ip/tcp. And
that we need to investigate a Layer 2protocol of some substance, for a
redesign of the network.
Lest everyone tell me APRS has done fine with ax.25 and there's no
reason to change, I can enumerate several:
1. The evils of source-based routing
2. Limited routing address lengths
3. short packet designs (which just happen to be prvetty good for radio
but are not really right) which cannot be extended where it'd help
4. No support for fail-over routing
5. No real Address Resolution intelligence
6. No adaptability for lost packets in an RF environment
It's time to reestablish the quest for the holy grail of a new network
design. And that means: identify requirements, plan to the
requirements, write coherent specs.
Gerry
----------------------------------------------------------------------
Subject: RE: Ver.2: Another thing I'd like to see...
From: Juergen Frank <db2fm@jfsattv.de>
Date: Mon, 28 Apr 2003 09:44:51 +0200
X-Message-Number: 2
am 27.04.2003 22:40 Uhr schrieb Bob Bruninga unter bruninga@usna.edu:
>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.
That's not true anymore. As far as I know, programmers of client software
try to make their software better and better. Last time you asked for this
decay algorythm I asked the programmer of my favorite APRS-client to
implement something like that (or may be something better). And, as this
person doesn't read this mailing list anymore because of the endless
discussions, most of the time ending at their beginning, I will tell you
what he implemented: He made it user selectable, what the retry interval is
(default is 30 s, could be adapted to the 16 s you seem to like more),
retries are 5 by default, changeable, it has an expire time (default 120
mins, editable) AND it has a check-box 'Retry on heard', which is the most
important thing!. So when you try to send a message it will be send twice
and then again, right after the addressee has been heard again, which
propably makes more sence than repeating, no matter if this station is ever
heard again.
So, Bob, don't blame other programmers for not having features of APRSdos,
which might have been implemented in the meantime, please. That's in my eyes
really contraproductive. Sometimes I ask myself, what you would do, when
some software would have (really needed) feature(s) your application might
not have (I know that's nearly impossible <grin>).
Please don't get me wrong, Bob, you did do a lot for the (ham-) community by
inventing APRS and always asking for fulfilling it's original purpose
(that's most important), but with always telling 'some software is better'
you can't force anybody to make things change. Just a thought...
>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.
Completely agreed!
>de WB4APR, Bob
73 de Juergen db2fm
----------------------------------------------------------------------
Subject: Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Mon, 28 Apr 2003 06:14:05 -0400
X-Message-Number: 3
"Gregg G. Wonderly" wrote:
>>>As I stated, there's lots of reasons that AX.25 is the wrong protocol...
>>The "least common denominator" is the TNC. AX.25 is what all of the TNC's
>>use, right? Does someone make a TCP/IP based TNC? I ask from ignorance,
>>nothing more.
>
>Well, we know that many used to use TCP/IP with TNCs using various link layer
>protocols... IP doesn't have anything in it for link layer control.
<snip>
Now I think I'm starting to understand better. Is this related to the phrase
that I see so often: "TCP/IP over AX.25"? (allowing the borrowing of the best
of each world?)
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: AX.25 & TCP/IP [was: Another thing I'd like to see...]
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 28 Apr 2003 11:46:56 -0500
X-Message-Number: 4
>Now I think I'm starting to understand better. Is this related to the phrase
>that I see so often: "TCP/IP over AX.25"? (allowing the borrowing of the best
>of each world?)
Plain AX.25 is like ethernet. It provides a link layer of communications
between network devices. So, TCP/IP over AX.25 or in the commercial satellite
world, TCP/IP over X.25, is a natural fit.
At issue for the RF world is effective management of the 'media' use. CSMA
(carrier sense, multiple access) works exactly the same on ethernet as it does
on AX.25. Collisions impair the total usable bandwidth. Ethernet hubs have
given way to ethernet switches specificall to address the collision domain
problems. I.e. why should the transmissions of one 'station' cause another
station with a completely different destination to have to wait? Well, in the
RF world, you can't segment a single channel into multiple channels without
changing the way that the channel is used.
SSB transmission for instance, has no carrier. This means that when everyone
transmits at the same time, you hear all signals, not just the strongest that
the FM capture effect provides. PSK-31 exploits this 'feature'. All stations
using PSK-31 might transmit at the same base frequency, but their audio tones
are location in different segments of the 2.5Khz slice so that they can be
decerned from each other.
I think that the next step would be to use an SSB 2M or 70cm radio, and design
firmware that listened for channel use, and kept statistics about what was
most used and what was least used, and would then pick a segment of the 2.5khz
slice to use based on that. A less flexible solution might include some
manual assignment of slots through a display on the 'rig' that would let you
pick a channel.
FM is really not a great use of spectrum for data, and the information we are
sending is not quite wide enough in bandwidth to allocate the whole 12Khz or
so of FM space for a single channel. That would be around 100 PSK-31 channels
worth of bandwidth...
PSK-31 tones work fine on FM, but the carrier makes it impossible for multiple
users to transmit at the same time on the same frequency...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
