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 <[email protected]> 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 <[email protected]> > 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] >> >
