discuss-gnuradio
[Top][All Lists]
Advanced

[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: Charles Swiger
Subject: Re: [Discuss-gnuradio] work function - how it fits in the big picture
Date: Thu, 20 Apr 2006 11:53:03 -0400

On Wed, 2006-04-19 at 17:41 -0700, Eric Blossom wrote:

> To  make the new code match the behavior of GrAtscTrellisEncoder
> (which is what I think you're up to) you'll need to derive from
> gr_sync_block and add this to your constructor:
> 
>   set_output_multiple(atsci_trellis_encoder::NCODERS);
> 

Great - that seems to work.

> I also suggest adding the "paranoid check" that's at the bottom of
> GrAtscTrellisEncoder if you haven't already.

That check is in the atsci_trellis_encoder.cc.



Ok - I'm going to spend time trying to understand all that. Putting
the same thing in atsc_viterbi_decoder.cc compiles and runs and
gets this further down the loopback:

sched: <gr_block atsc_viterbi_decoder (21)> is requesting more input
data
  than we can provide.
  ninput_items_required = 12
  max_possible_items_available = 7
  If this is a filter, consider reducing the number of taps.


It wants 12 4096-byte soft_data_segment, or 49152 bytes. Max
available is 28672.

Well, one solution is to go into
gnuradio-core/src/python/gnuradio/gr/flow_graph.py and change
fixed_buffer_size to:

   self.fixed_buffer_size = 64*1024

from  32*1024

then make, make install.  Don't know if that can by dynamically 
changed from the processing block.

Runs, few issues in the qa script then will update cvs.

--Chuck






reply via email to

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