Re: Problem with Python OOT
Thanks Tim! George On Wed, Jan 20, 2021 at 1:01 PM Tim Huggins wrote: > George, > > That should be correct; I was more referring to keeping your coding clean > so you don't accidentally make a mistake (I've been bit before :-). You > could conceivably start consuming inputs at different rates but by then you > are probably getting into some more complex signal processing. > > Tim > > On Wednesday, January 20, 2021, 1:29:46 PM EST, George Edwards < > gedwards@gmail.com> wrote: > > > 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 > 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 > 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 > 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
Re: Problem with Python OOT
George, That should be correct; I was more referring to keeping your coding clean so you don't accidentally make a mistake (I've been bit before :-). You could conceivably start consuming inputs at different rates but by then you are probably getting into some more complex signal processing. Tim On Wednesday, January 20, 2021, 1:29:46 PM EST, George Edwards wrote: 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 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 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][:]= v2it 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 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 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
Re: Problem with Python OOT
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 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 > 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 > 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 >
Re: Problem with Python OOT
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 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 > 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: >> >> # *
Re: Problem with Python OOT
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 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 > 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
Re: Problem with Python OOT
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 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 > >
Re: Problem with Python OOT
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 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
