Self.set_min_noutput_items() is not a valid python command in gnuradio?

Dear Sir,

In c++ we have: set_min_noutput_items()
What is it equivalent syntax in python ?

I try this:
self.set_min_noutput_items()

Error message:
AttributeError: ‘quadrator_upconverter_python1’ object has no
attribute
‘set_min_noutput_items’

Note:
The self.set_output_multiple() in python seems accepted, is it
functional
…?

Regards,
Activecat

On Thu, Mar 6, 2014 at 2:12 AM, Activecat [email protected] wrote:

‘set_min_noutput_items’

Note:
The self.set_output_multiple() in python seems accepted, is it functional
…?

Regards,
Activecat

Looks like when this feature was added, it didn’t make it into the
block.i swig file. I’ll push a patch for this soon.

But before you try and use this, be very careful. This is an advanced
issue that’s really only meant to be used if you a) really really need
it and b) really really know what you are doing and why.

Tom

Hi Activecat,

to answer question 1):
grepping for “min_noutput_items” instantly shows that in
gnuradio-runtime/lib/block_executor.cc line 299, your block’s
min_noutput_items() is called every iteration. If there isn’t enough
space, the block thread sleeps until there is more. So yes, it works on
the fly.

I remember there was something with returning 0, and I know that
producing 0 items used to mark a source as done, but this mechanism was
commented out about a year ago (l. 483ff, I think for some good reason),
but I can’t remember that being an issue for a non-source block; have
you tried it and did you run into problems?

Greetings,
Marcus

Dear Sir,

Let me explain the reason of why to use the function:
set_min_noutput_items().

I am creating a custom interpolator block.
Says, the interpolation factor is 1000. Hence it is important to call
set_output_multiple(1000).

Meanwhile, for this block the interpolation factor depends on Sample
Rate
(samp_rate). In this flow-graph the samp_rate could be changed by the
user
during runtime. This means the interpolation factor may change during
runtime, and hence we need to call set_output_multile() with different
values during runtime !

The problem arisen when there is no guarantee that set_output_multiple()
will work if you change it on the fly.
(Refer
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-11/msg00504.html)

The workaround is to use set_min_noutput_items() if it work on the fly.
Says, after changing samp_rate, the new interpolation factor is
recalculated as 800.
If the set_output_multiple(800) doesn’t work, the general_work() can
still
consume 1 input and produce 800 output if the noutput_items is at least
800. This enables the flow graph continue to work.

If the noutput_items is less than 800, the only correct thing the
general_work() can do is to consume_each(0) and return 0. This may be
problematic and can cause unforeseen behavior. So it is important to
make
sure the noutput_items is at least 800. Hence I call:
set_min_noutput_items(800)

This means we can make use of set_min_noutput_items() as a workaround,
if
set_output_multiple() doesn’t change on the fly.

The questions are:
1). Can we use this to change setting on the fly:
set_min_noutput_items()
2). Is there any better workaround for this?

Regards,
Activecat

Dear Marcus,

1). The line 299 of gnuradio-runtime/lib/block_executor.cc is:
noutput_items = min_available_space(d, m->output_multiple(),
m->min_noutput_items());

 If this line shows that set_min_output_items() works on the fly, 

does
this also shows set_out_multiple() works on the fly?
(just to confirm because I do not fully understand the source
code).

2). Regarding the returning 0 issue, let me share my experience of
experiments.
I am creating a custom interpolation block with its interpolation factor
can be changed on the fly. Hence it is inherited from gr::block. It
has
one input port and one output port.
During runtime, there will be no problem if the general_work() return 0,
provided it consume a non-zero value.
The flow graph may become unresponsive when the general_work() return 0
and
consume zero.

My explanation:
Says, the instantaneous interpolation factor is 800. The general_work()
is
now called with noutput_items=699 and ninput_items[0]=3. In this case
the
only correct thing that general_work() should do is to consume 0 and
return
0.

But later the general_work() will be repeatedly called again with the
same
arguments, i.e. noutput_items=699 and ninput_items[0]=3. In this case
again
the general_work() has to consume 0 and return 0. This may repeat few
thousand rounds, or infinite rounds. When this happens the flow graph
becomes unresponsive (hang).

That’s why it is important to set_min_output_items() to the
instantaneous
interpolation factor (which is 800), if the set_output_multiple()
doesn’t
work on the fly.

If there is no better workaround, we have to stick to this trick at the
moment.

Regards,
Activecat

Dear Marcus,

This is the forecast, I believe it is correct.
void quadrator_upconverter_impl::forecast (int noutput_items,
gr_vector_int &ninput_items_required)
{ ninput_items_required[0] = noutput_items / d_iFactor; }

Note: d_iFactor is the instantaneous interpolation factor.

Currently this custom block often doesn’t produce correct output when
the
instantaneous interpolation factor changes on the fly. But it doesn’t
hange, thanks to the set_min_noutput_items().
Nevertheless this block produce correct output if the interpolation
factor
doesn’t change on the fly.
Below is the set_samp_rate():

void
quadrator_upconverter_impl::set_samp_rate( float samp_rate )
{
    d_samp_rate = samp_rate;
    if ( d_change_rate > 0.0 )
    {
        d_iFactor = d_samp_rate / d_change_rate;
        set_output_multiple( d_iFactor );
        set_min_noutput_items( d_iFactor );
    }
}

Regards,
Activecat

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

On 08.03.2014 03:34, Activecat wrote:

Dear Marcus,

1). The line 299 of gnuradio-runtime/lib/block_executor.cc is:
noutput_items = min_available_space(d, m->output_multiple(),
m->min_noutput_items());

If this line shows that set_min_output_items() works on the fly,
does this also shows set_out_multiple() works on the fly? (just to
confirm because I do not fully understand the source code).

If set_output_multiple just sets the gr::block’s field that
gr::block::output_multiple() returns, then yes, it works for the next
iteration.

My explanation: Says, the instantaneous interpolation factor is
That’s why it is important to set_min_output_items() to the
instantaneous interpolation factor (which is 800), if the
set_output_multiple() doesn’t work on the fly.

If there is no better workaround, we have to stick to this trick at
the moment.

Hm, I’d call this a bug, iff (!) your forecast does everything right.
Can you confirm?

Regards, Activecat

Greetings,
Marcus

more. So yes, it works on the fly.

set_output_multiple(1000).
(Refer
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-11/msg00504.html)

The workaround is to use set_min_noutput_items() if it work on the fly.

Hence I call: set_min_noutput_items(800)

Dear Sir,

But before you try and use this, be very careful. This is an
mailing

[email protected]://lists.gnu.org/mailman/listinfo/discuss-gnuradio


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGoVpAAoJEBQ6EdjyzlHtXpAH/3rMFjvBQxTzxwPuwb7Vfr2s
afzIB7c0SR16EmbQ7XXwGRc413vJrYz9HSP+mHW+d14EId0tJgbD70M0NjA2rIfO
4qJA+OyKxgG/kchpeqH8thHzS5eE8jQxPhAYuE7dgYOK8pD9XW/z6Tnj7xOr7UVP
Xh8nWoM9HXJXq4xagjkXOqsIW8hxAe7JRNuAx7Jrtbe1g1cyjTfROa2KNRyZbxoa
V8V4UeYBt0ab3LGqCwUGB1uMefoGn2Walnb9rcW38jEaLEQ+l33ZgvD3kDte/Jju
78aglgn15tXU0VMbX5ON9ZkLm4lZCx1TQ2Wyf/PxnNhKow9kSfSaoJYnSZ77U0U=
=638A
-----END PGP SIGNATURE-----

Hi activecat,
The scheduler might be confused if he asked for less than iFactor
samples, because then your forecast tells him you need 0 input to
produce that… The joys of Integer division
Can you modify it so that it always demands at least 1 input?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi activecat,
The scheduler might be confused if he asked for less than iFactor
samples, because then your forecast tells him you need 0 input to
produce that… Integer division


Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9

iQFABAEBCAAqBQJTGuX2IxxNYXJjdXMgTfxsbGVyIDxtYXJjdXNAaG9zdGFsaWEu
ZGU+AAoJEBKNLRrpJvfolIgH+gIhLw9qsywTNzWsP5cKpbWI6I0o15H8NdjRTQp4
3q1Qar28b5m2S3esFnmk1JuKAqILvJQ+lxECFpnz6uY4cViDfdKHul+HW6YAnskA
PS5M+SI7qhTRYrkbFhF2mrtUeuBrCJm1KQryl2rNk+rYGELk6abLjNi+wzFuS7b5
/x4MM0Gs7EhbHjaxTrC8usARPYrBw68hjfKPmUaZrw1kNwXtAgMCMUBoZ5vUIjzk
DRU68DdjA8sqRMo+P4MBAeCrk9HndQ3Mu6kL+fff+t3vyuaGCBblYqSMPT8MWY5R
0xezgCd0P5KAkl3wlDjL8pa/Il3N+sKq90KFMS+QTr7BBZ8=
=B9Vj
-----END PGP SIGNATURE-----

Dear Marcus,

Sure, I have changed it, as follows:

void quadrator_upconverter_impl::forecast (int noutput_items,

gr_vector_int &ninput_items_required)
{ ninput_items_required[0] = std::min( 1, noutput_items /
d_iFactor
); }

This tested has no effect to the flow graph; the block still doesn’t
produce correct output when d_iFactor changes on the fly.

BTW I thought it is redundant to do this change, because as long as
set_min_noutput_items(d_iFactor) works on the fly, the scheduler will
not
ask for less than iFactor samples. Correct…?

Regards,
Activecat

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

your std::min should be a std::max :slight_smile: would you try with that?

On 08.03.2014 12:30, Activecat wrote:

BTW I thought it is redundant to do this change, because as long
as set_min_noutput_items(d_iFactor) works on the fly, the scheduler
will not ask for less than iFactor samples. Correct…?
Yes, in that case the block_executor iteration should return the magic
value “BLKD_OUT”, which will tell the thread scheduler to sleep until
there is more output space available. (refer to min_available_space,
l.70)
However, what you’re seeing is a repeated call of your work, so
something goes wrong here :confused:
What you could try is do some output of the parameters that forecast
and work are called with, and what they returned.
Otherwise, I’m kind of at the end of my ideas how to pinpoint the
problem…

Greetings,
Marcus

you need 0 input to produce that… The joys of Integer division

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGwJWAAoJEBQ6EdjyzlHtaEUIAIU/xwUUg4dUfzpv3cvCBTyM
gT8u9uMw/9vFRXsDRnj/QZvlgkc2EtW1vwyVrjgh165Jm9Vl8AY9SIKlPryOfFMK
7fg8G5hNuXm8wIIL2iCj15Kom9qp+Gh9YK8ULD/ElHh/z2zkSTftsp647DbNcget
miKrjPfEIkN6JQdz5xpEWUvgblGjHUKclI100A2kGajPAcY7YWZczAZ0LxIy/rKZ
CjOpRsHRgIa/hd1WvC5PiaqtFJxoyGHK3weFgPZAAi6IYL2rH5LSmrFTeGQrYgYH
CvXEq8GjbPLwUEv8ubyUWNv95h0fvDJUhMchVUY17v/ZnHdZqE8Bkd6VNELZO3c=
=GUvF
-----END PGP SIGNATURE-----

Dear Marcus,

2). Regarding the returning 0 issue, let me share my experience of

ninput_items[0]=3. In this case the only correct thing that
set_output_multiple() doesn’t work on the fly.

If there is no better workaround, we have to stick to this trick at
the moment.

Hm, I’d call this a bug, iff (!) your forecast does everything right.
Can you confirm?

This problem happens because general_work() is called with noutput_items
equals to a value less than d_iFactor.
So we need to do something to handle the noutput_items, not the
ninput_items[].

Hence, the issue is not with the forecast() because forecast() only
affects
ninput_items[].

Note:
d_iFactor is the instantaneous interpolation factor of this custom
block.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

On 08.03.2014 13:54, Activecat wrote:

that could cause the flow graph to produce wrong result too.

But, well, these blocks don’t change output ratios based on
sample_rate…

My main concern is whether set_output_multiple() and
set_min_noutput_items() works on the fly in general. As your answer
is yes to both, then I think that is good enough for this thread.
:slight_smile:
At line 24 the samp_rate is changed to 64k on the fly by the user.
So now d_iFactor = 64k/64 = 1000. Every parameters and return
values seem to be correct, but the flow graph output becomes wrong
after line 24.
Wrong in which way?

Greetings,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGxZlAAoJEBQ6EdjyzlHtzVkH/2yu6GyvUr2aevwric3ER7iS
kuZ0drhy9C1PweSqPeBBPSRdOxqX0nDsYD9O+f+k03bGLyfidwLQ8jlt0J9wX9Vv
82yvxGkEVf3OShAUB44uPFEUOvbAYef697jjP0YmDSrbGc/XQ7+FpngJmOqhqBpe
AsiqmKpLaYJ9rvKsButGaj6mnT98mnWQt2+GTk5bTzZ0w9O1NVKpo6odaFVMp+hM
+OjW7w+vV5YfyRw3OhhyrjoXCMOtw1oXz4aUbHuKqXfFF12GJYA3mrElKuELK7E+
fnC24SD8rrpytdjTTwj+sAoebJhxDymb8oCJ2UwR7f13CgmWrmat+p0J9KS6aUY=
=FeQj
-----END PGP SIGNATURE-----

Dear Marcus,

Thanks for pointing out, I’ve corrected it to std::max.
It still doesn’t seem to produce correct output when the d_iFactor
changes
on the fly.

BTW this flow graph consists of other built-in blocks like Low Pass
Filter,
Signal Source etc, whose outputs also depends on the instantaneous
Sample
Rate (samp_rate). If one of these built-in blocks doesn’t work well when
samp_rate changes on the fly, then that could cause the flow graph to
produce wrong result too.

My main concern is whether set_output_multiple() and
set_min_noutput_items() works on the fly in general.
As your answer is yes to both, then I think that is good enough for this
thread.

The general_work() is called repeatedly and problematically only if it
return 0 and consume 0. With the set_min_noutput_items() works on the
fly,
this problem doesn’t happen anymore. Now the problem is the incorrect
output when the d_iFactor changes on the fly.

Meanwhile, as you had advised, I had tried to see the parameters that
forecast() and general_work() are called with. Refer below verbose
message.
When the flow chart started, the initial values are samp_rate=32k,
change_rate=64; hence d_iFactor = 32k/64 = 500.
At line 24 the samp_rate is changed to 64k on the fly by the user. So
now
d_iFactor = 64k/64 = 1000.
Every parameters and return values seem to be correct, but the flow
graph
output becomes wrong after line 24.

1 forecast(): ninput_items_required[0] is set to 16 while
noutput_items
is 8000 , d_iFactor is 500
2 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
3 forecast(): ninput_items_required[0] is set to 16 while
noutput_items
is 8000 , d_iFactor is 500
4 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
5 forecast(): ninput_items_required[0] is set to 16 while
noutput_items
is 8000 , d_iFactor is 500
6 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
7 forecast(): ninput_items_required[0] is set to 16 while
noutput_items
is 8000 , d_iFactor is 500
8 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
9 forecast(): ninput_items_required[0] is set to 16 while
noutput_items
is 8000 , d_iFactor is 500
10 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
11 forecast(): ninput_items_required[0] is set to 16 while
noutput_items is 8000 , d_iFactor is 500
12 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
13 forecast(): ninput_items_required[0] is set to 16 while
noutput_items is 8000 , d_iFactor is 500
14 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
15 forecast(): ninput_items_required[0] is set to 16 while
noutput_items is 8000 , d_iFactor is 500
16 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
17 forecast(): ninput_items_required[0] is set to 16 while
noutput_items is 8000 , d_iFactor is 500
18 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
19 forecast(): ninput_items_required[0] is set to 16 while
noutput_items is 8000 , d_iFactor is 500
20 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
21 forecast(): ninput_items_required[0] is set to 16 while
noutput_items is 8000 , d_iFactor is 500
22 general_work(): consumed 16 at port 0, noutput_items is 8000 ,
d_iFactor is 500
23 forecast(): ninput_items_required[0] is set to 16 while
noutput_items is 8000 , d_iFactor is 500
24 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
25 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
26 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
27 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
28 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
29 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
30 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
31 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
32 forecast(): ninput_items_required[0] is set to 4 while
noutput_items
is 4000 , d_iFactor is 1000
33 forecast(): ninput_items_required[0] is set to 2 while
noutput_items
is 2000 , d_iFactor is 1000
34 forecast(): ninput_items_required[0] is set to 1 while
noutput_items
is 1000 , d_iFactor is 1000
35 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
36 forecast(): ninput_items_required[0] is set to 4 while
noutput_items
is 4000 , d_iFactor is 1000
37 forecast(): ninput_items_required[0] is set to 2 while
noutput_items
is 2000 , d_iFactor is 1000
38 forecast(): ninput_items_required[0] is set to 1 while
noutput_items
is 1000 , d_iFactor is 1000
39 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
40 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
41 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
42 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
43 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
44 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
45 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
46 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
47 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
48 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
49 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
50 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
51 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
52 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
53 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
54 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
55 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
56 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
57 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
58 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
59 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
60 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
61 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
62 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
63 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
64 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
65 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
66 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
67 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
68 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
69 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
70 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
71 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
72 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
73 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
74 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
75 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000
76 general_work(): consumed 8 at port 0, noutput_items is 8000 ,
d_iFactor is 1000
77 forecast(): ninput_items_required[0] is set to 8 while
noutput_items
is 8000 , d_iFactor is 1000

Done

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

sorry, I neither know your application nor what your work does, so the
question was more like “does GNU Radio do something wrong or is it
just the output of your block”; I don’t understand any of your output :wink:

  • From what I see, there is 65535==0b1111111111111111 in your output;
    this indicates some arithmetic error in your work.
    However, this leaves the scope of this thread, so I suggest we close
    the discussion here.

Greetings,
Marcus

On 08.03.2014 15:42, Activecat wrote:

33, 44, 55, 211, 222, 233, 244, 255, 0 Integer1
11, 22, 33, 44, 55, 211, 222, 233, 244, 255, 0
182, 145, 73, 71, 124, 82, 85, 170, 173, 131,

_______________________________________________ Discuss-gnuradio
mailing list [email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTGy5ZAAoJEBQ6EdjyzlHtdL8IAKtKp+4uw32Y975gbRV+Y+YO
GbC8Jeo8bWoHi3DdyjmlnzLaDCanhxXjNsfU0hwMQcpCQN65Zu0407VYfVYVIXgJ
IRBjOwSleZsTGBkeXS6lFxNQLHn5FkWIHMA8yPZy05jpjdqa6wdShRVmqjl8depe
kLxVPN8Cqfz8wadIV4OcW2l5K/59ZU/O2MqNNL2O5qiMNz8E8TDHmhJXfzCkWjcs
9JePXJ2RDS39o8W7WsPOlXLioNAHwBWy+98oNUClGB07dorkci8TWY6ScEWztKKU
9RJsUj9HUjy70LbXbRuJ88m1qZhBwNYDx4CGjX9PMJAMeM5ehnCQkNjRx3mFm20=
=u8XF
-----END PGP SIGNATURE-----

Dear Marcus,

sorry, I neither know your application nor what your work does, so the

question was more like “does GNU Radio do something wrong or is it
just the output of your block”; I don’t understand any of your output :wink:

  • From what I see, there is 65535==0b1111111111111111 in your output;
    this indicates some arithmetic error in your work.
    However, this leaves the scope of this thread, so I suggest we close
    the discussion here.

Sure, let’s end this thread.
Thanks for the help.
Thank you very much.

Regards,
Activecat

Dear Marcus,

Meanwhile, as you had advised, I had tried to see the parameters
that forecast() and general_work() are called with. Refer below
verbose message. When the flow chart started, the initial values
are samp_rate=32k, change_rate=64; hence d_iFactor = 32k/64 = 500.
At line 24 the samp_rate is changed to 64k on the fly by the user.
So now d_iFactor = 64k/64 = 1000. Every parameters and return
values seem to be correct, but the flow graph output becomes wrong
after line 24.

Wrong in which way?

Refer below, row_002 to row_010 are correct outputs.
At row_011, the samp_rate was changed from 64k to 32k, by using WX GUI
Slider. This were wrong outputs.

Executing: “/home/sgku/gnuradio/flow_graphs/top_block.py”
Using Volk machine: ssse3_32_orc
Integer1 [row_001] = 3, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_002] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_003] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_004] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_005] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_006] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_007] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_008] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_009] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_010] = 11, 22, 33, 44, 55, 211, 222,
233, 244, 255, 0
Integer1 [row_011] = 11, 22, 33, 700, 23, 863, 15,
1530, 165, 0
Integer1 [row_012] = 65535, 3, 1, 3, 1646, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,
71, 124, 82, 85, 170, 173, 131, 184, 182, 145, 73,

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