[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

R: Observed AO-40 FEC coded telemetry



Bob and Douglas,

The OSCAR-10 , OSCAR-13 and now AO40 dpsk telemetry is
a syncronous flux of data+clock at a bit rate of 400 bit/sec

Every block,like the A block,is made of 4096 bit and each byte
is 8 bit long so that each block is formed by 4096/8=512 byte

The dpsk demodulator (hardware) or dpsk software at the
ground station must detect the bebinning of the first valid bit
of the flux of 4096 bit that make it a valid block of 512 byte.

To allow  this possible the AO40 telemetry send a syncronization
vector after succesfully decoding that the first received bit is the
beginning of the 4096/8=512 byte long valid block.

The syncronization vector sent by AO40 is formed by  4 byte  i.e.
39 15 ED 30 in exadecimal code and repeats it continuosly at the
beginning of each transmitted block.

To detect the beginning of a valid block of data the dpsk demodulator
or any software like AO40rcv internally generates the same syncronization
vector to wich every received telemetry bit is compared in it.

When a received bit match with the beginning of the syncronization vector
than the 39 15 ED 30 sequence advances and than the following received bit
is compared.

If for example the third received bit is not maching with the third
internally generated bit of syncronization vector than the sequence
39 15 ED 30  automatically reset  and starts again because the beginning of
a valid block has not been detected.

When all received bit of the transmitted sincronization vector are
succesfully matching in sequence it mean that the beginning of the valid
block made of  4096 bit has been detected to form a valid block of 512 byte
and 512 byte are immediately counted in the demodulator to form a block
of telemetry data.

If a different syncronization vector is transmitted by AO40 at the beginning
of a FEC coded A block than the beginning of  this block cannot be
recognized by the actual demodulators or by the actual software until
modifications are made by the experts to make possible to manage 39 15 ED 30
and the other code for FEC at the same time.

73" de i8CVS Domenico

----- Original Message -----
From: Robert McGwier <rwmcgwier@comcast.net>
To: <amsat-bb@AMSAT.Org>
Sent: Monday, June 09, 2003 1:57 PM
Subject: RE: [amsat-bb] Observed AO-40 FEC coded telemetry


> This correct.  Phil made the assumption that
> after initially finding a sync vector, that
> the data+fec blocks would more or less arrive
> synchronously after that.  Since there is a
> long delay every time that is not fixed in
> length between these frames of telemetry,
> the assumption that Phil made is false and
> the code cannot leave search mode.
>
> Bob
>
>
> -----Original Message-----
> From: owner-AMSAT-BB@AMSAT.Org [mailto:owner-AMSAT-BB@AMSAT.Org]On
> Behalf Of Dquagliana@aol.com
> Sent: Monday, June 09, 2003 05:30
> To: amsat-bb@AMSAT.Org
> Subject: Re: [amsat-bb] Observed AO-40 FEC coded telemetry
>
>
> Kazu Sakamoto writes:
> >On Saturday June 7th 2003 around 03z, I am sure
> >that I observed the experimental transmission of
> >FEC coded telemetry of AO-40 on the S2 beacon.
> [some text deleted]
> > Unfortunately since I'm not ready to decode
> >the FEC coded blocks, I coundn't confirm what
> >contained in the 13 seconds.
>
> It looks like a FEC block after the normal telemetry
> block, I think.
>
> I downloaded the WAV files from
> http://www.ne.jp/asahi/hamradio/jj1wtk/
> and tried to process them using Phil Karn's AO-40
> FEC code.  To do this I first converted a small
> portion of the WAV file from 16bit 8000 samples per
> second to 16bit 9600 samples per second, which is
> the format that Phil's programs use.
>
> Running dpsk_demod on the converted portion of the
> WAV file shows that the Phil's code is able to
> correctly detect the carrier just below 1600 Hertz,
> and the sync is mostly zeros with a few -1's which I
> think means that the symbol sync is working fine.
> I take this to mean that the dpsk_demod is seeing
> the bits and bit transitions okay.
>
> However, the program doesn't get out of search mode.
> The Viterbi decoder histogram shows that most of the
> bits are being decoded as nearly halfway between
> "strong one" and "strong zero".  For most frames the
> biggest number is near the center of the list.
> The Reed Solomon decoder says "FAIL FAIL" indicating
> that it sees too many errors to correct.
>
> Probably I'm doing something wrong here.  Has anyone
> gotten a FEC block to demodulate ?
>
> Douglas KA2UPW
> "I'm working on putting the code into AO40Rcv...want to help?"
> ----
> Sent via amsat-bb@amsat.org. Opinions expressed are those of the author.
> Not an AMSAT member? Join now to support the amateur satellite program!
> To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org
>
>
> ----
> Sent via amsat-bb@amsat.org. Opinions expressed are those of the author.
> Not an AMSAT member? Join now to support the amateur satellite program!
> To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org














----
Sent via amsat-bb@amsat.org. Opinions expressed are those of the author.
Not an AMSAT member? Join now to support the amateur satellite program!
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org



AMSAT Top AMSAT Home