Block consuming input if there is no output?


#1

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


#2

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


#3

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


#4

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.