Hi Tim, Thanks for your help and for sending the links.
One final question, I was under the impression that length of data in each input was the same because the data to each input is streamed in in lock-step sample by sample. Therefore, len(input_items[0] = len(input_items[1] = len(input_items[2], is this not correct? Thanks again for your help and patience. I appreciate it very much! Regards, George , , use the appropriate length for each input On Wed, Jan 20, 2021 at 10:51 AM Tim Huggins <huggins.timo...@yahoo.com> wrote: > 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....@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(self, noutput_items, ninput_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(self, input_items, output_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(0, len(input_items[0])) > > self.consume(1, len(input_items[0])) > > self.consume(2, len(input_items[0])) > return len(output_items]) > > Thank you very much! > George > > On Tue, Jan 19, 2021 at 3:50 PM George Edwards <gedwards....@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 = blocks.vector_source_c(np.array([src0, 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.timo...@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....@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: > > - id: scale > > label: Scale_Value > > dtype: bool > > default: True > > > > # 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: > > - domain: stream > > dtype: complex > > multiplicity: '3' > > > > # - label: in0 > > # dtype: complex > > # - label: in1 > > # dtype: complex > > # - label: in2 > > # dtype: complex > > > > outputs: > > - label: out > > dtype: complex > > > > # 'file_format' specifies the version of the GRC yml format used in the > file > > # and should usually not be changed. > > file_format: 1 > > > > > On Mon, Jan 18, 2021 at 7:50 AM Tim Huggins <huggins.timo...@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....@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 > >
