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

RE: Observed AO-40 FEC coded telemetry



Thanks for the information, I hope it was instructive
to everyone.    The issue I think is clear. The data
is, was, and in the future will be all correct and
the beacon is working.  It is not working as Phil
originally thought it might work.  The data, as it
has since the first Phase III bird is indeed being
transmitted synchronously.  The frames are not.
There is a variable time between frames.

Phil's code says  I see a frame now,  I see a frame
later, I will make the assumption that the time between
these frames is always going to be roughly be the time between
frames.  If I do not observe this, I have only
one choice and that is to go back into search mode.

This is correctable.  Phil says he is going it.

A couple of points.  The frames are actually 514 bytes
long.  You have forgotten the CRC check bits.

The correct way to detect synchrony is not to look for
the bits but to search for the appropriate waveform
of those bits and cross correlate for the waveform
over some range of frequencies.  This has a nice SNR
advantage over xor for bits after detection.  This will
also be more tolerant of errors, one does not have to
demodulate until the sync vector is found, and you
find the frequency offset all at once.

I am absolutely ecstatic that Stacey did the PC IPS
compiler and that Phil's FEC code was one of its
first successes.

Bob
N4HY


-----Original Message-----
From: owner-AMSAT-BB@AMSAT.Org [mailto:owner-AMSAT-BB@AMSAT.Org]On
Behalf Of i8cvs
Sent: Tuesday, June 10, 2003 02:21
To: Robert McGwier; AMSAT-BB; Dquagliana@aol.com
Subject: R: [amsat-bb] Observed AO-40 FEC coded telemetry


Bob and Douglas,

>>>>  CORRECTED ABOVE:
>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

>>>>>> Better way suggested above:
>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.

>>>>> Since the IPS software could easily be changed to do exactly
>>>>> what you say here, this is a good idea:

>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


----
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