Re: [Discuss-gnuradio] forecast in infinite loop

[Martin Braun]

On 30.09.2015 16:16, Jared Dulmage wrote:
> Ubuntu 14.04, GR 3.7.8
> 
> I apologize if this question is a duplicate, I never received a
confirmation of my original request in the mailing list digest. I
appreciate any insights or advice to diagnose the issue presented below.

Hey Jared,

I replied to your original email; can you please go back to that thread.

In general, if you're participating in discussions, I recommend not
subscribing to the digest.

Cheers,
M


> 
> From a high level, I am trying to create a block that acts like a
gate, i.e. in the locked state, the block passes all inputs to the
output; in the unlocked state the block consumes its input and provides
no output. The state depends on a count of consecutive events (misses)
where the block's state changes to locked (unlocked) when a threshold is
met. Events are marked by stream tags on the input at a regular
interval. So there is no a priori known relationship between input and
output. I've seen this thread which I believe is related:
> 
> https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00039.html
>
>
> 
but I can't seem to determine a solution from that discussion. My
block is called frame_sync_c and is a python block.
> 
> My test flowgraph looks like
> 
> vector_source_c -> throttle -> frame_sync_c -> null_sink
> 
> The vector source has tags placed periodically with a gap in the tag
sequence. The block behaves completely as expected for a number of
lock/unlock cycles and then devolves into an infinite loop of forecast
calls without calling general_work. Below is a sample log that shows the
forecast calls, noutput_items and nitems_read(0) in each general_work
call and consume calls.
> 
> Consume calls are prefixed by the current block state, Locked or
Unlocked. "Consume & produce X" means the block called self.consume(0,X)
and also returned X. "Consume X" means self.consume(0,X) was called and
0 was returned (i.e. no output was produced). The block generally
consumes up to a state transition and then relies on another call to
general_work to continue processing with the new state. Interestingly,
the block seems to devolve after around 3000 samples regardless of the
vector_source_c data size, tag period, or other parameters related to
the input stream.
> 
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :INFO: frame_sync_c0 - Forecast 2048
> gr::debug :INFO: frame_sync_c0 - Forecast 1024
> gr::debug :INFO: frame_sync_c0 - Forecast 512
> gr::debug :INFO: frame_sync_c0 - Forecast 256
> gr::debug :INFO: frame_sync_c0 - Forecast 128
> gr::debug :INFO: frame_sync_c0 - Forecast 64
> gr::debug :INFO: frame_sync_c0 - Forecast 32
> gr::debug :INFO: frame_sync_c0 - Forecast 16
> gr::debug :INFO: frame_sync_c0 - Forecast 8
> gr::debug :INFO: frame_sync_c0 - Forecast 4
> gr::debug :INFO: frame_sync_c0 - Forecast 2
> gr::debug :INFO: frame_sync_c0 - Forecast 1
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :DEBUG: frame_sync_c0 - noutput_items = 4096, nitems_read(0) = 0, 
> key_tags @ 10, 110, 210, 310, 410, 510, 610, 710
> gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 410
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :INFO: frame_sync_c0 - Forecast 2048
> gr::debug :DEBUG: frame_sync_c0 - noutput_items = 2048, nitems_read(0) = 410, 
> key_tags @ 410, 510, 610, 710
> gr::debug :DEBUG: frame_sync_c0 - Locked: Consume & produce 600
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :INFO: frame_sync_c0 - Forecast 2048
> gr::debug :DEBUG: frame_sync_c0 - noutput_items = 2048, nitems_read(0) = 
> 1010, key_tags @ 
> gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 2048
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :INFO: frame_sync_c0 - Forecast 2048
> gr::debug :INFO: frame_sync_c0 - Forecast 1024
> gr::debug :DEBUG: frame_sync_c0 - noutput_items = 1024, nitems_read(0) = 
> 3058, key_tags @ 
> gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 1024
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :INFO: frame_sync_c0 - Forecast 2048
> gr::debug :INFO: frame_sync_c0 - Forecast 1024
> gr::debug :INFO: frame_sync_c0 - Forecast 512
> gr::debug :INFO: frame_sync_c0 - Forecast 256
> gr::debug :INFO: frame_sync_c0 - Forecast 128
> gr::debug :INFO: frame_sync_c0 - Forecast 64
> gr::debug :INFO: frame_sync_c0 - Forecast 32
> gr::debug :INFO: frame_sync_c0 - Forecast 16
> gr::debug :INFO: frame_sync_c0 - Forecast 8
> gr::debug :DEBUG: frame_sync_c0 - noutput_items = 8, nitems_read(0) = 4082, 
> key_tags @ 
> gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 8
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :INFO: frame_sync_c0 - Forecast 2048
> gr::debug :INFO: frame_sync_c0 - Forecast 1024
> gr::debug :INFO: frame_sync_c0 - Forecast 512
> gr::debug :INFO: frame_sync_c0 - Forecast 256
> gr::debug :INFO: frame_sync_c0 - Forecast 128
> gr::debug :INFO: frame_sync_c0 - Forecast 64
> gr::debug :INFO: frame_sync_c0 - Forecast 32
> gr::debug :INFO: frame_sync_c0 - Forecast 16
> gr::debug :INFO: frame_sync_c0 - Forecast 8
> gr::debug :INFO: frame_sync_c0 - Forecast 4
> gr::debug :DEBUG: frame_sync_c0 - noutput_items = 4, nitems_read(0) = 4090, 
> key_tags @ 
> gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 4
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :INFO: frame_sync_c0 - Forecast 2048
> gr::debug :INFO: frame_sync_c0 - Forecast 1024
> gr::debug :INFO: frame_sync_c0 - Forecast 512
> gr::debug :INFO: frame_sync_c0 - Forecast 256
> gr::debug :INFO: frame_sync_c0 - Forecast 128
> gr::debug :INFO: frame_sync_c0 - Forecast 64
> gr::debug :INFO: frame_sync_c0 - Forecast 32
> gr::debug :INFO: frame_sync_c0 - Forecast 16
> gr::debug :INFO: frame_sync_c0 - Forecast 8
> gr::debug :INFO: frame_sync_c0 - Forecast 4
> gr::debug :INFO: frame_sync_c0 - Forecast 2
> gr::debug :DEBUG: frame_sync_c0 - noutput_items = 2, nitems_read(0) = 4094, 
> key_tags @ 
> gr::debug :DEBUG: frame_sync_c0 - Unlocked: Consume 2
> gr::debug :INFO: frame_sync_c0 - Forecast 4096
> gr::debug :INFO: frame_sync_c0 - Forecast 2048
> gr::debug :INFO: frame_sync_c0 - Forecast 1024
> gr::debug :INFO: frame_sync_c0 - Forecast 512
> gr::debug :INFO: frame_sync_c0 - Forecast 256
> gr::debug :INFO: frame_sync_c0 - Forecast 128
> gr::debug :INFO: frame_sync_c0 - Forecast 64
> gr::debug :INFO: frame_sync_c0 - Forecast 32
> gr::debug :INFO: frame_sync_c0 - Forecast 16
> gr::debug :INFO: frame_sync_c0 - Forecast 8
> gr::debug :INFO: frame_sync_c0 - Forecast 4
> gr::debug :INFO: frame_sync_c0 - Forecast 2
> gr::debug :INFO: frame_sync_c0 - Forecast 1
> ---- repeats Forecast 4096 to Forecast 1 lines forever ----
> 
> Jared.
> ------------------------------------------------------
> Jared Dulmage
> Engineering Specialist
> Digital Comm. and Implementation Dept.
> Aerospace Corporation
> 310-336-3140
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>