[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]
Re: Fade remover
- Subject: Re: [amsat-bb] Fade remover
- From: "MCGWIER ROBERT" <rwmcgwier@xxxxxxxx>
- Date: Sat, 3 Feb 2001 15:54:25 -0500
I get to transmit several fewer symbols and
I get nearly the same performance as going
into a known state. Having done several
implementations, it is not a horror to decode.
It is a completely trivial extension to the "normal"
decoding.
Since the command stations will never do any
of this, we are all wasting amsat-bb bandwidth.
I think the only thing we could even hope to get
is repeat sends.
Bob
----- Original Message -----
From: "Jens David" <dg1kjd@afthd.tu-darmstadt.de>
To: "MCGWIER ROBERT" <rwmcgwier@home.com>
Sent: Saturday, February 03, 2001 2:04 PM
Subject: Re: [amsat-bb] Fade remover
> Hi Robert,
>
> > Tail biting is where you write the data to be encoded
> > on a "circular" shift register the length of the data and
> > then pass the encoder around the circle until each
> > bit has been passed over once. You can then glue
> > as many copies together of the transmission as you
> > need to decode. Tail biting also relieves you of the
> > need to have a flush sequence. This could be done.
> > It takes only will power.
> >
> > Bob
>
> Hmmm, why?
> This is a horror to decode...
> Why not the straight line? The trellis is already terminated
> by the frame idle sequence and we can obtain block synchronization
> through - well, the block preamble.
> As far as I know you would only employ tail biting if you are concerned
> about the loss in code rate which would occur if you had to pad each
> transmitted block to get back to a known state at the end of the trellis.
> (Because if you did not, the last symbols would be less protected.)
> We have known start and termination states so whats the point?
>
> -- Jens
>
----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org
AMSAT Home