Forum: GNU Radio block consuming input if there is no output?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Dc48f9c00e3e6de9640898a531c26d89?d=identicon&s=25 Charles Swiger (Guest)
on 2006-05-03 22:41
(Received via mailing list)
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
Dc48f9c00e3e6de9640898a531c26d89?d=identicon&s=25 Charles Swiger (Guest)
on 2006-05-03 23:53
(Received via mailing list)
On Wed, 2006-05-03 at 16:37 -0400, Charles Swiger 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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-05-04 12:48
(Received via mailing list)
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
Dc48f9c00e3e6de9640898a531c26d89?d=identicon&s=25 Charles Swiger (Guest)
on 2006-05-04 21:11
(Received via mailing list)
On Thu, 2006-05-04 at 03:46 -0700, Eric Blossom 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 topic is locked and can not be replied to.