Block consuming input if there is no output?

Will a 2.x block consume an input stream if it returns 0 output items?

All the other atsc blocks are at least passing data and reporting
various states, but fsd = atsc.field_sync_demux() seems to be hung up.
An upstream block connected to fsd, when also connected to a file sink
only produces 28672 (7 * 4096) in the file. fsd, as copied from
gr 0.9 does not produce output untill a field sync is detected.
It is searching thru data, but it looks like it’s just going
thru the input_tags[ii] array off to infinity, i.e,

cerr << "atsc_field_sync_demux: searching for sync at "
<< inputs0_index + ii << endl;

just counts up.

File attached.

Also I’m now using the 0.9 atsc_tx to create test data (20Msps shorts
centered at 5.75MHz), instead of “off the air”.

–Chuck

On Wed, 2006-05-03 at 16:37 -0400, Charles S. wrote:

Will a 2.x block consume an input stream if it returns 0 output items?

appearently not. I just make a simple change

    d_next_input += ii;     // update for forecast
    return ii/DEC;               // no work completed so far
  }
}
// no non-NORMAL tag found
d_next_input += ii;         // update for forecast
return ii/DEC;                   // no work completed so far

with ii/DEC instead of 0, and was rewarded with:

atsc_field_sync_demux: synced (FIELD-2) at 125177021 [delta = 724]
atsc_field_sync_demux: lost sync at 125177021
atsc_field_sync_demux: synced (FIELD-2) at 125177745 [delta = 724]
atsc_field_sync_demux: lost sync at 125177745
atsc_field_sync_demux: synced (FIELD-2) at 125178469 [delta = 724]
atsc_field_sync_demux: lost sync at 125178469
atsc_field_sync_demux: synced (FIELD-2) at 125179193 [delta = 724]
atsc_field_sync_demux: lost sync at 125179193

On Wed, May 03, 2006 at 04:37:49PM -0400, Chuck Swiger wrote:

Will a 2.x block consume an input stream if it returns 0 output items?

Yes, if it’s based on gr_block and you call consume or consume_each
in general_work.

All the other atsc blocks are at least passing data and reporting
various states, but fsd = atsc.field_sync_demux() seems to be hung up.
An upstream block connected to fsd, when also connected to a file sink
only produces 28672 (7 * 4096) in the file. fsd, as copied from
gr 0.9 does not produce output untill a field sync is detected.
It is searching thru data, but it looks like it’s just going
thru the input_tags[ii] array off to infinity, i.e,

–Chuck
Eric

On Thu, 2006-05-04 at 03:46 -0700, Eric B. wrote:

On Wed, May 03, 2006 at 04:37:49PM -0400, Chuck Swiger wrote:

Will a 2.x block consume an input stream if it returns 0 output items?

Yes, if it’s based on gr_block and you call consume or consume_each
in general_work.

Ok, just thinking out loud here - the 0.9 i/o data types are
VrSampleRange

typedef unsigned long long VrSampleIndex;
typedef struct {
VrSampleIndex index;
unsigned long size;
} VrSampleRange;

and my simple solution to the inputs[x].size and inputs[x].index
problem was to create new variables inputs0_size and inputs0_index.
The was sufficient in other blocks but field_sync_demux will need
to be rewritten. Just returning ii/DEC gets it enough data to sync,
THEN it hangs up - this is tantalizingly close to fully working:

gr_fir_fff: using SSE
FSC - 511 pattern is good, errors: 1
FSC - Field 2
tag is start field sync
EQ: Transition to locked
EQ: symbol_num: 0, segment_num: 511, field_num: 1, valid: 1
EQ: symbol_num: 0, segment_num: 511, field_num: 1, valid: 1
EQ - tag_is_start_field_sync_2
EQ - d_offset_from_last_field_sync: 654
atsc_field_sync_demux: synced (FIELD-2) at 1663345 [delta = 1663345]
FSD - returning 3
atsc_field_sync_demux: lost sync at 1663345
atsc_field_sync_demux: synced (FIELD-2) at 1664069 [delta = 724]
FSD - returning 0
atsc_field_sync_demux: lost sync at 1664069
atsc_field_sync_demux: synced (FIELD-2) at 1664793 [delta = 724]
FSD - returning 0

where inputs0_index is 1663345 etc - which I don’t think should just
keep counting symbols indefinitely, and returning 0 I guess means it’s
stuck looping over the same data or something.

Maybe it’s finding a field sync at offset 724 in the input stream,
bumping up inputs0_index by that much and exiting, then reentering
expecting to find the field sync at 0, doesn’t find it (lost sync) -
searches again and finds it out at 724, adds that, exits, lather rinse
repeat.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs