| |
PA2AGA > TCPDIG 27.10.96 17:47l 144 Lines 5181 Bytes #-10841 (0) @ EU
BID : TCP_96_227A
Read: DG7DAH GUEST
Subj: TCP-Group Digest 96/227A
Path: DB0AAB<DB0PV<DB0MAK<DB0HOT<DB0LPZ<DB0ERF<DB0HSK<DB0SGL<DB0HAG<DB0ACH<
DB0ACC<PI8DRS<PI8DAZ<PI8GCB<PI8MBQ<PI8VNW
Sent: 961027/1253Z @:PI8VNW.#ZH2.NLD.EU #:30573 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA19297 ; Sun, 27 Oct 96 12:39:42 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.62/7.1) with SMTP
id AA00006924 ; Sun, 27 Oct 96 13:23:31 MET
Received: from pa2aga-1 by pa2aga with SMTP
id AA00006921 ; Sun, 27 Oct 96 13:12:23 MET
Received: from pa2aga-1 by pa2aga-1 (NET/Mac 2.3.62/7.5.5) with SMTP
id AA00008270 ; Sun, 27 Oct 96 13:12:21 MET
Date: Sun, 27 Oct 96 13:10:07 MET
Message-Id: <tcp_96_227A>
From: pa2aga
To: tcp_broadcast@pa2aga-1
Subject: TCP-Group Digest 96/227A
X-BBS-Msg-Type: B
TCP-Group Digest Sat, 26 Oct 96 Volume 96 : Issue 227
Today's Topics:
AX25 utils etc in rpm form for linux
HF Multi-Cast
wampes on FreeSCO (3 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from ftp.UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Tue, 22 Oct 1996 22:50:29 +0000 (GMT)
From: Richard Adams <pa3gcu@pa3gcu.ampr.org>
Subject: AX25 utils etc in rpm form for linux
According to pa2aga@pa3gcu.ampr.org:
>
> Date: Sun, 20 Oct 1996 23:03:06 +0200 (MET DST)
> From: Simon J Mudd <sjmudd@bitmailer.net>
> Subject: AX25 utils etc in rpm form for linux
>
> Hello,
>
> I think there was talk of making a redhat rpm file of the various AX25
> utilities. Has this been done yet, or to configure AX25 and use AX25 or
> tcp/ip over AX25 do I need to use the whatever.tar.gz files?
>
> I've just upgraded to the latest Redhat 4.0 Colgate, and would prefer
> rpm's as they make upgrading much more straightforward. I now want to
> configure Linux to run AX25, so a quick answer would save me some time.
>
> 73s Simon, EA4ELS / G0FNB
>
> Simon J Mudd, Madrid, SPAIN
> e-mail: sjmudd@bitmailer.net
A handy WWW site is the author of the ax25-utils G4KLX, here you can find
literlaty all you need to know for installing and using the utils.
http://www.cs.nott.ac.uk/~jsn
Altho' i imagen there might be some small differences between red-hat and
slackware.
Hope this helps.
--
Regards Richard, 73.
AX25 pa3gcu@pi8mid.#zld.nld.eu
smtp pa3gcu@pi1goe.ampr.org
inet pa3gcu%gwpe1cig@HZeeland.nl
------------------------------
Date: Wed, 23 Oct 1996 09:43:21 -0600
From: "Karl F. Larsen" <k5di@acca.nmsu.edu>
Subject: HF Multi-Cast
Reading what Phil wrote about FEC and other new things makes me
think they should be used with any HF Multi-Cast system as well. What Phil
said was:
>I am at least partly to blame for the decision to use CPSK on
>Microsat, as I heavily promoted it in the early 1980s for the Pacsat
>project (that eventually became Microsat). But in my defense, I had
>envisioned much higher data rates than 1200 bps.
>
>The lack of FEC implies an inefficient use of downlink power,
>especially when there is fading caused by spacecraft motion. Good FEC
>with sufficient interleaving can work wonders on a fading
>channel.
>
>Coding would be particularly effective for the broadcast
>protocol. Instead of taking repeat requests from the ground, the
>satellite could compute "parity packets" from a Reed-Solomon code that
>the ground stations use to fill in the missing packets without
>requesting a fill.
>
>Here's an example of how this might work. I'll pick some arbitrary
>numbers just as an example; I do not claim that they're optimal
>choices for a real satellite.
>
>The satellite divides up its transmitted data stream into blocks of
>256 x 32 = 8192 bytes. It then transmits the block as 32 256-byte data
>frames, each with a mod 36 sequence number and a CRC.
>
>After the data frames are sent, the satellite generates 4 256-byte
>"parity frames", also with a sequence number and CRC. These parity
>frames are generated by a shortened (36,32) Reed-Solomon code over
>GF(256) (i.e., 8-bit symbols), with the data field of each RS codeword
>taking one byte from each of the 32 data frames:
>
> 255 (36,32) RS codewords (downwards)
> | | |
> v v v
>Data frame 0: D000 D001 ... D255 (across)
>Data frame 1: D256 D257 ... D511
>...
>Parity frame 0: P000 P001 ... P255
>Parity frame 1: P256 P257 ... P511
>...
>
>
>Now if the receiver gets all of the data frames 0-31 without any CRC
>errors, it can just ignore the four parity frames 32-35 and wait for
>frame 0 from the next block. But if one or more of the data frames
>fail the CRC, they can be reconstructed from the parity frames using
>an erasure- correcting RS decoder. An RS code can fill in as many
>erased symbols in a codeword as there are parity symbols, so in this
>case the receiver can fill in up to four missing data frames assuming
To be continued in digest: tcp_96_227B
Read previous mail | Read next mail
| |
