Hi,
I would like to thank you for the support,
my issue is entirely solved applying the patch suggested in #797
Cheers :-)
Il 2016-07-24 21:31 Marcus Müller ha scritto:
Ah, great! This is really the patchset of my dreams :D
Thanks! Should've thought of checking out next… or the redmine issue
t
Ah, great! This is really the patchset of my dreams :D
Thanks! Should've thought of checking out next… or the redmine issue
tracker. Must be the heat.
Cheers,
Marcus
On 24.07.2016 21:18, Bastian Bloessl wrote:
> Maybe you want to try the flow graph with the next branch. What you
> describe was
Maybe you want to try the flow graph with the next branch. What you describe
was supposed to be addressed by
https://github.com/gnuradio/gnuradio/pull/797
Best,
Bastian
> On 24 Jul 2016, at 12:39, Marcus Müller wrote:
>
> If I had to pinpoint a culprit, it'd be in gnuradio-runtime/lib/block
If I had to pinpoint a culprit, it'd be in gnuradio-runtime/lib/block.cc
750 bool
751 block::finished()
752 {
753 if((detail()->ninputs() != 0) || (detail()->noutputs() != 0))
754 return false;
755 else
756 return d_finished;
757 }
758
Meaning that blocks with
Hi,
'doh.
Which leaves one to wonder why the finished state never gets checked.
I'll be back after a bit of tracing.
Cheers,
Marcus
On 24.07.2016 08:04, Sylvain Munaut wrote:
> Hi,
>
>> 52 int pdu_to_tagged_stream_impl::calculate_output_stream_length(const
>> gr_vector_int &)
>> 53
Goodmorning list,
thanks to everybody for your replies.
I attached a minimal example illustrating the problem.
Specifically, the block that causes the non stop behavior is the
[PDU to tagged stream], the same encountered by Piotr and discussed in
the other replies.
In my case we can restrict t
Hi,
> 52 int pdu_to_tagged_stream_impl::calculate_output_stream_length(const
> gr_vector_int &)
> 53 {
> 54 if (d_curr_len == 0) {
> 55 /* FIXME: This blocking call is far from ideal but is the best
> we
> 56*can do at the moment
> 57
Hi Piotr,
I let gdb loose on your minimal example [1], and found this:
52 int pdu_to_tagged_stream_impl::calculate_output_stream_length(const
gr_vector_int &)
53 {
54 if (d_curr_len == 0) {
55 /* FIXME: This blocking call is far from ideal but is the best we
56
Hi Marcus,
>Debugging your flowgraphs on a C++ and threat level when they ought to
>be exiting would be pretty interesting!
An example of my flowgraph where I used PDU to tagged stream convertion
is this:
https://github.com/ptrkrysik/examples/blob/master/voice_decoding_in_grc/tch_f_reception.grc
Hi Piotr,
> Maybe it can be some "exit" tag that would be propagated to all blocks
> in a flowgraph.
In fact, GR does have something like that: It's a built-in message
handler for a message port called "system"; see block.cc:60:
60 message_port_register_in(pmt::mp("system"));
61 set_msg
Hi Simone and all,
Can you provide your GRC flow-graph? I think that source of the problem
might be somewhere in this part
"PMT MESSAGE TO FILE SOURCE" as there is message to samples stream
conversion involved here. But it's not clear for me what it actually is
as you described it.
I have problem
Simone,
a file source *will* terminate the flow graph once its read the file
(unless you specify 'repeat').
M
On 07/21/2016 12:32 AM, Simone Ciccia S210664 wrote:
> Goodmorning,
> I would like to Know some methods to Close flowgraph automatically when
> it has finished. Some example, stop when U
Goodmorning,
I would like to Know some methods to Close flowgraph automatically when
it has finished. Some example, stop when USRP has no more samples to
transmits, or a file source has read until EOF.
The Run of completion option works when (for instance) you have a file
source connected to ot
13 matches
Mail list logo
