discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: Problem with Python OOT


From: Tim Huggins
Subject: Re: Problem with Python OOT
Date: Wed, 20 Jan 2021 16:51:46 +0000 (UTC)

George,

I'm not completely certain exactly why that doesn't result in a 1 to 1 (you might be able to look at the code for the basic sync block to see if there is anything you could add: https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/sync_block.cc (this would be an instance to use the sync block instead of a general block which forces the 1:1 relationship). That being said, take a look here:
https://wiki.gnuradio.org/index.php/Types_of_Blocks

Mainly the implementation using a general block at the very bottom. You can see how the input is limited to be no bigger than the output buffer in the work implementation:

in0 = input_items[0][:len(output_items[0])]

Also, be careful about your consumes - instead of using len(input_items[0]) for each, use the appropriate length for each input to get into good habits.

Tim

On Tuesday, January 19, 2021, 9:07:00 PM EST, George Edwards <gedwards.eng@gmail.com> wrote:


Hi Tim,

I thought I had it working. However, it is dropping the last output sample. In the QA file, there are 5 complex samples going into each of the 3-inputs to the module. When the general_work() method runs with the for loop, it throws an exception error stating that index 4 (meaning out[4]) is out of bounds. If I comment out the for loop and run the program with the line commented out below: 
output_items[0][:]= v2
it results in 4 out of  5 samples going to the output. I am using the documented default approach in coding for a 1:1 input/output sample relationship as you can see in the forecast() and general_work() methods below, please let me know if you see something that is wrong.

    def forecast(selfnoutput_itemsninput_items_required):

        #setup size of input_items[i] for work call

        for i in range(len(ninput_items_required)):

            ninput_items_required[i] = noutput_items

 

    def general_work(selfinput_itemsoutput_items):

        global v1, v2

        if self.scale == True:

            v1 = self.v1

            v2 = self.v2

            self.scale = False

 

        in0 = input_items[0]

        in1 = input_items[1]

        in2 = input_items[2]

        out = output_items[0]

 

        v2 = 1.0+1.0*1j

        for ii in range(0,len(in0)):

            out[ii] = v2

        # output_items[0][:] = v2

        self.consume(0len(input_items[0]))       

        self.consume(1len(input_items[0]))

        self.consume(2len(input_items[0]))        

        return len(output_items])  

Thank you very much!
George

On Tue, Jan 19, 2021 at 3:50 PM George Edwards <gedwards.eng@gmail.com> wrote:
Hi Tim,

Thank you very much for your help! 

The problem was with the QA file. I tried to input the 3 source streams as:
src = "" src1, src2])) 
where each srcX was defined as a complex array. Based on the link into the github QA files that you sent me, it showed that each srcX must be connected individually to the processing block. Also, I overlooked the fact that when I ran the QA, it pointed to that line in the code as a problem.

I will now try to see if I can get the output to provide a stream of 8 samples (maybe do 3 as a start) based on one sample from each of the 3-input streams.

Thanks again for the help!

Regards,
George  

On Tue, Jan 19, 2021 at 2:05 PM Tim Huggins <huggins.timothy@yahoo.com> wrote:
George,

Unfortunately I'll still not seeing anything wrong with what you have (and I realized that the QA code caused the issue so it is probably not in your yml file). I'd probably have too see your entire code to try to reproduce the error as all my tests to create the error didn't.

Regarding your other questions:
1. There isn't really a correct/incorrect as the answer can depend on the work that you want the block to do but general will work. I mainly use general or sync.
2. Yes, as you have a 1 to 1 stream.
3. This doesn't look quite correct. Are you planning on working with vector inputs or steams to your block? if you are using streams then there is no need to change vlen in the yml file. Also it sounds like whatever computations are basically doing an interpolation (1 input to 8 outputs), you may want to look at the interp_block type instead of the general block that you are using (it might make your life a little easier, take a small glance here: https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/python/blocks/qa_block_gateway.py). Alternatively I think you could look at the set_output_multiple() call. 

Tim







On Monday, January 18, 2021, 8:27:28 PM EST, George Edwards <gedwards.eng@gmail.com> wrote:


Hi Tim,
Thanks for the offer to help! I appreciate it very much.
Here is the rest of yml file. I also have some further questions:
1. In the gr-modtool design, I picked the "general" block, is this correct?
2. The current model has 3 streaming inputs. Each output sample computation takes one sample from each input. So I leave the forecast() method as the default which is:
    ninput_items_required[i] = noutput_items, is this correct?
     And, in the general_work() method, I also leave the default:
    return len(output_items[0]), is this correct?
3. The final model will have the same 3 input streams, but each computation will produce a stream of 8 output samples. So, do I now change the forecast() method to:
    ninput_items_required[i] = noutput_items - 7
    Then, in the general_work() method do:
     return len(8*input_items[0])
     Then, for the yml file set, vlen = 8              "The setting of these parameters in Item 3 are all confusing to me"

parameters:

idscale

  labelScale_Value

  dtypebool

  defaultTrue

 

#  Make one 'inputs' list entry per input and one 'outputs' list entry per output.

#  Keys include:

#      * label (an identifier for the GUI)

#      * domain (optional - stream or message. Default is stream)

#      * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)

#      * vlen (optional - data stream vector length. Default is 1)

#      * optional (optional - set to 1 for optional inputs. Default is 0)

inputs:

domainstream

  dtypecomplex

  multiplicity'3'

 

# - label: in0

#   dtype: complex

# - label: in1

#   dtype: complex

# - label: in2

#   dtype: complex

 

outputs:

labelout

  dtypecomplex

 

#  'file_format' specifies the version of the GRC yml format used in the file

#  and should usually not be changed.

file_format1

 



On Mon, Jan 18, 2021 at 7:50 AM Tim Huggins <huggins.timothy@yahoo.com> wrote:
George,

I have made several OOT Python blocks with variable numbers of inputs and outputs and while I could very easily be overlooking something the error does not, at first glance, appear to be in the code that you have sent out. Can you send the rest of your yml file (and potentially the rest of the python)? I am curious if there is something missing in either the templates or parameters sections of your yml file.

Tim

On Friday, January 15, 2021, 2:56:48 PM EST, George Edwards <gedwards.eng@gmail.com> wrote:


Hello,

I am trying to make a Python OOT block which accepts a stream of 3 inputs complex valued data and for each single input sample (one on each input line) the block will output 8 complex samples. For my first cut, I am simply trying to get the module to work outputting one complex sample (rather than 8). Below are the essential parts of my program.

1. In the def __init__ (self.), I set the inner method gr.basic_block.__init__(self,
       name="my_block_name_py_cc",
       in_sig = [numpy.complex64, numpy.complex64,  numpy.complex64  ],
       out_sig = [ numpy.complex64 ])       # with 3 inputs and one output

2. In the general_work() method for now I set the output to a constant complex value as follows
      out_items[0][:] = 1.0+1.0*1j

3. In the *.yml file, the input is set as:
        inputs:
        - domain: stream
           dtype: complex
           multiplicity: '3'

The module compiles. However, when I run the QA file, it gives an error stating something is wrong in File "..........blocks_swig1.py at line 8354.
TypeError: in method 'vector_source_c_make', argument 2 of type 'bool'

I went to the file and the line stated, but I have not seen anything to help me make corrections. As far as a TypeError of 'bool', I do not see where I would have made such an error. I have an input parameter in the def __init__(self, start = True) method, 'start', which comes in as bool, but that is the only bool variable I am using. The documentation I read for the method states "This block produces a stream of samples based on an input vector" (which is my goal if I can get it to work).

I will appreciate any help to get me on the right track.

Regards,
George


reply via email to

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