A two blocks synchronizing problem

Hello

I created 2 new blocks, one is an encoder and the other one a decoder. I
needed the encoder block to had 8 input items (from a vector source) and
11
output items, so I set: consume each(8) and return(11). I did not have
any
problem with it.

Now, for the decoder block, I needed to had 11 input items and 8 output
items, so I set: consume each(11) and return (8).

I printed out the outputs with “cout << out[i];” .

The problem: The encoder´s outputs are fine, they are what I expected
them
to be.
But, the decoder´s outputs are giving me trouble: At first, it behaves
well,
the decoder´s input corresponds with encoder´s output and the decoder´s
output corresponds with the vector source´output. But then, after a
while,
the decoder´s input do not begin in the first value as the encoder´s
output
and thus, the decoder´s output is not equal to the vector source´s
output.

For example, if the encoder´s output is: 20.57, 11.45, 14.82, 17.81,
16.95,
16.63, 20.57, 15.14, 16.95, 11.45, 20.57. At first, the decoder´s input
is
exactly the same, but after a while, are: 17.81, 16.95, 16.63, 20.57,
15.14,
16.95, 11.45, 20.57, 20.57, 11.45, 14.82. It begins in the fourth value
instead the first.

Is there a way to synchronize these two bloks? So the decoder´s input is
always the same as the encoder´s output?

am I missing something? What should I do?

Thank you

David


View this message in context:
http://gnuradio.4.n7.nabble.com/a-two-blocks-synchronizing-problem-tp54499.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi David,

GNU Radio really makes sure you are only greeted with samples you did
not already consume, and you don’t miss a single one, so in principle,
this should work.

Do you check that you a) don’t produce more samples than you are allowed
to (noutput_items) in your encoder and b) don’t consume more input items
then there are (ninput_items) in your decoder?

There’s a handy trick to ensure that GNU Radio always calls you with a
multiple of 8 (encoder) or 11 (decoder) items:
set_output_multiple as well as set_relative_rate allow you to define how
GNU Radio handles the amount of items.

Best regards,
Marcus

Hello Marcus.

Thank you for your response.

<There’s a handy trick to ensure that GNU Radio always calls you with a
multiple of 8 (encoder) or 11 (decoder) items:
set_output_multiple as well as set_relative_rate allow you to define how
GNU Radio handles the amount of items.>

I I had already done that when I made the question, I’m sorry I didn’t
specified it.
This is how I set it:
<void set_output_multiple (int tamano_entrada + nsimbolo);
set_relative_rate (double relative_rate);>

In another topic, you wrote me that was syntactically incorrect and you
advice me to set it like this:
set_output_multiple(tamano_entrada+nsimbolo);

But this way I get the errors <‘tamano_entrada’ is not a type> and
<expected
‘,’ or ‘…’ before ‘+’ token>

Again, when I set this parameters the first time I asked (void
set_output_multiple (int tamano_entrada + nsimbolo);
void set_relative_rate (double relative_rate):wink: I did not get any
errors,
but I had the problems I wrote in the original message.
<The problem: The encoder´s outputs are fine, they are what I expected
them

16.95,
16.63, 20.57, 15.14, 16.95, 11.45, 20.57. At first, the decoder´s input
is
exactly the same, but after a while, are: 17.81, 16.95, 16.63, 20.57,
15.14,
16.95, 11.45, 20.57, 20.57, 11.45, 14.82. It begins in the fourth value
instead the first. >

Is there something else I am missing?

Thank you very much!

David


View this message in context:
http://gnuradio.4.n7.nabble.com/a-two-blocks-synchronizing-problem-tp54499p54561.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hello again

I’m sorry, in the last message, tamano_entrada is 8 and nsimbolo is 3
(this
is for the encoder).

Also, I had probed doing this scheme in two parts:
First I took a vector source as a binary entry for the encoder. The
encoder’s output was what I have expected it to be. I had the same 11
float
values in the same order all the time.
Then, I took a vector source with the float values that would be in the
encoder’s output, and I connected it to the decoder’s input. The values
at
the decoder’s output were corrects too (were the same bits that I put
into
the vector source in the first part).

So, I think the problem is when I connect both encoder and decoder
blocks
but I don’t know how to solve it.

Than you.
David.


View this message in context:
http://gnuradio.4.n7.nabble.com/a-two-blocks-synchronizing-problem-tp54499p54562.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi!

In another topic, you wrote me that was syntactically incorrect and you
advice me to set it like this:
set_output_multiple(tamano_entrada+nsimbolo);

But this way I get the errors <‘tamano_entrada’ is not a type> and <expected
‘,’ or ‘…’ before ‘+’ token>
Different things are correct to do different things: When you call a
function, you must not say which types the parameters have.
If you do something that your compiler thinks is a function declaration,
you must.

Again, when I set this parameters the first time I asked (void
set_output_multiple (int tamano_entrada + nsimbolo);
void set_relative_rate (double relative_rate):wink: I did not get any errors,
I’d like to address these two lines, and then remove myself from this
discussion. You make C++ beginner’s mistakes, which is totally ok, and
can be overcome with a little training, but this is really not the place
to discuss this, I’m afraid. I must apologize if I came across harsh at
times, but you must understand that there’s a gap between the level of
questions you’re asking and your ability to autonomously write correct
C++ code, and I can’t help you bridge that.

void set_output_multiple (int tamano_entrada + nsimbolo);

This doesn’t really make sense. Either you’re in a situation where you
need to supply the type (you declare or define the function/method
set_output_multiple), then your arguments must have types but need to be
identifiers and can be expressions that give you a value (such as
tamano_entrada + nsimbolo).

OR you’re in a place to use that already existing function or method
(that’s the case here), and the typename is wrong.
I can’t find any way that GCC won’t give an error for this line, sorry;
I think you might be missing some compiler errors.

void set_relative_rate (double relative_rate);

That is not a call to gr::block::set_relative_rate. That is a
function declaration, possibly hiding the original method. C++ in some
compilers/versions supports local-scope function declarations like
these. A call would simply look like
set_relative_rate(12.12);
or
set_relative_rate(relative_rate);
but can never declare the type of either the arguments or the return
value of that function. That’s logical, because the function must
already be declared if you want to use it. The fact that this seems to
work better than what I told you to do means that you have more mistakes
that get hidden by this mistake.

Best regards,
Marcus

Sorry, typo:

then your arguments must have types but need to be identifiers and can be
expressions that give you a value

is wrong,
needs to read
can not be expressions that give you a value
Full text, corrected:

Thank you Marcus.

I saw my mistakes, now both blocks are finally working fine! Thank you
for
all your help. And thank to all that helped me.


View this message in context:
http://gnuradio.4.n7.nabble.com/a-two-blocks-synchronizing-problem-tp54499p54575.html
Sent from the GnuRadio mailing list archive at Nabble.com.