Re: OutofTree Block C++ problem

[Malte Lenhart]

Hey, sorry from that description I am cannot tell what the issue is.

Could be that there isn't enough data as you guessed.
If you don't have a hardware related block, you might need a throttle to see the output. (if the entire execution just freezes it might as well be this).
Is your block telling the gnu radio scheduler how many samples it produced?
...

If that doesn't help you'll need to add more information to your error.

/Malte

On 16.11.21 00:20, Mario Moran wrote:

Well, actually I want the block to return bytes, but when I was trying to fix the problem I first thought that I was using the wrong data type so I changed it to different types and when I shared this my error I had as double at that point. So it was not intended, the goal is bytes. Those open questions were a great help. I will consider getting rid of the chunks to symbols block, might be a little easier but before that I fixed the block to now run with no errors but I am not getting anything from my QT GUI Time Sink block and the return code is -11. I have been looking into return codes and I am not sure what that means. Would you know where to look? For the QT GUI Time Sink block not showing anything, could that be because it is not receiving enough data to plot anything? 

Thank you for your help.

- Mario Moran

On Mon, Nov 15, 2021 at 3:47 PM Malte Lenhart <malte.lenhart@mailbox.org> wrote:

Hi,

happy to hear that. The itemsize mismatch is usually indicating that two connected blocks operate on different data types.

You want to return doubles, which typically take up 64bits = 8bytes (which gnu radio indicates without giving the unit as reference unfortunately). So the question is to what kind of block your OOT block is connected to, and if that one also is set to operate on doubles (although many blocks don't seem to be able to operate on doubles if I see that right.. youbles should be float64 in gnu radio, but e.g. the null sink doesn't have that one..). If the other block expects 1 (8bits) that probably is set to char or byte.

You could either ask yourself if you need doubles or if floats suffice (in which case you can omit the static_cast). Alternatively you have to modify blocks down the flow to operate on doubles.

I just checked what the chunks to symbols block does, and that raised a few more questions...
- the chunks to symbols does a 1-to-N conversion of samples. why not just let the random source produce as many samples as required and skip that block?
- your block is named random byte source, but returns doubles. is that intended?

Concluding: yes, your initial assumption on the error is correct, I hope that the open questions can help you to decide what fix to choose when adjusting your block :-)

Cheers,

Malte

On 15.11.21 21:18, Mario Moran wrote:

This fixed my problem. Thank you so much. I am wondering if you know anything about runtime error: itemsize mismatch? Would this mean that I am returned a value that the chunks to symbols block can't handle it? Because it says that my random block is 8 while the chunks to symbol is 1. 

On Mon, Nov 15, 2021 at 4:23 AM Malte Lenhart <malte.lenhart@mailbox.org> wrote:

Hi Mario,

have a look at the header file here: https://github.com/gnuradio/gnuradio/blob/eb91fb04b3d0ca8124b9bea375e3bf72963fa172/gnuradio-runtime/include/gnuradio/random.h

61|    double X = gr::random(0,0,2)
    |                           ^~~~~~~~~~~
    |                           gr::random

you are calling the constructor of gr::random here, which does not return anything.

Instead you need to assign it something and then query it for random numbers

like

gr::random foo = gr::random(0,0,2);

int i = foo.ran_int();
// .. you can then do it again of course
int j = foo.ran_int();

you seem to be wanting a double, where you have to check which distribution you want (see the header file).

One example could be

double d = static_cast<double>(foo.gasdev());

which will, if I looked right, give you a float in the range of -1 and 1. To get it in range 0 to 2, you can just add 1.0 to it.

Best regards,

Malte

[my mail program/me took the wrong mail address when replying to the digest, therefore answer delayed a bit]

OpenPGP_signature
Description: OpenPGP digital signature