[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] work function - how it fits in the big picture

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] work function - how it fits in the big picture
Date: Thu, 20 Apr 2006 18:44:07 -0700
User-agent: Mutt/1.5.9i

On Thu, Apr 20, 2006 at 06:16:06PM -0400, Charles Swiger wrote:
> On Thu, 2006-04-20 at 13:54 -0700, Eric Blossom wrote:
> > > 
> > > Notice that it does NOT have the interleaver/deinterleaver as I
> > > don't know how to handle the 52 segment delay which causes
> > > trellis to choke on regular segment flag check.
> > 
> > I think that if you move the skiphead to the very end (or just do it
> > by slicing the 52 out of the python expected vs actual vals), it will
> > work with the interleaver in.
> > 
> Done - but I had to drop skiphead alltogether for some reason it
> emits lots of zeros, maybe just on mpeg_packet size items. I don't
> know, but just trimming expected_result and result_data in python
> works and all is ok now. Updated and checked in.


> Oh, and you have to include another 12 packet delay from the viterbi
> decoder. 52+12.

Oh, that ;)

> All that was just tying a ribbon on nearly finished code - going forward
> the field sync and bit timing stuff looks pretty formidable and sketchy.

The segment sync stuff isn't too bad.  It should be pretty straight
forward.  Basically you're looking for the "pulse" at the beginning of
each segment.  The bit timing might take a bit more to understand, but
again, it's not too bad.  You're going to want to base the port on
GrAtscBitTimingLoop3.  The other two were failed experiments ;)

> It'd be nice to find the Wayne Bretl text.

A bit of googling, and then remembering that I found it on the Zenith
site gives:


which contains a doc file.  See also:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]