Re: [Discuss-gnuradio] hdtv hacking

[Charles Swiger]

On Fri, 2006-04-07 at 18:20 -0700, Eric Blossom wrote:
> On Fri, Apr 07, 2006 at 06:49:07PM -0400, Charles Swiger wrote:
> > 
> > > The most likely reason it doesn't pass, is that there is a 52
> > > segment delay between what you write into the interleaver, and what you
> > > get out of the deinterleaver.  To work around the behavior, drop the
> > > first 52 segments of the output and then compare the remainder with
> > > the input. 
> > > 
> > 

> That's great.  
> Did you figure out how to compare them without writing to files?
> 

Yes, using gr.skiphead(atsc.sizeof_atsc_mpeg_packet_rs_encoded,52)
right after inter/deinterleaving, and also trim 52 * 188 off the
end of expected_result with 

expected_result = src_data[0:len(src_data)-(52*188)]


I'm a little cornfused with the data sizes, in light of this:

"An MPEG transport stream packet is 188 bytes long.  Internally we use a
packet that is 256 bytes long to help with buffer alignment.  This
function adds the appropriate trailing padding to convert each packet
from 188 to 256 bytes."

and these:

>>> atsc.sizeof_atsc_data_segment
1024
>>> atsc.sizeof_atsc_data_segment_pad
188
>>> atsc.sizeof_atsc_mpeg_packet
256
>>> atsc.sizeof_atsc_mpeg_packet_no_sync
256
>>> atsc.sizeof_atsc_mpeg_packet_no_sync_pad
65
>>> atsc.sizeof_atsc_mpeg_packet_pad
68
>>> atsc.sizeof_atsc_mpeg_packet_rs_encoded
256
>>> atsc.sizeof_atsc_mpeg_packet_rs_encoded_pad
45
>>> atsc.sizeof_atsc_soft_data_segment
4096


I would hav expected "atsc_mpeg_packet" to be 188 and
"atsc_mpeg_packet_pad" to be 256 ??

Anyway, seems we should use one of those instead of 188 in
the expected_result trim statement above.

Other than that, make check runs and passes, ready to check
into cvs.

--Chuck