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 <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][:]= 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 <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
