discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] a two blocks synchronizing problem


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] a two blocks synchronizing problem
Date: Wed, 01 Jul 2015 22:37:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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);) 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


On 07/01/2015 07:53 PM, dcardona wrote:
> 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);) 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
>> 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 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.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

[Prev in Thread] Current Thread [Next in Thread]