1) Except the initial setting of in0, you can replace "input_items[0]" by
"in0".
Duly noted.

2) I think you can then replace "in1 = input_items[0][:][i]" with just "in1
= in0[i]". This works for me & makes sense based on the input_items
structure.

I have a question on this one. I saw in the "Block Coding Guide" as well
other sources that input_items is a 2D array, however, you mentioned in a
previous message that in my case its 3D. Why the difference? Does it have
to do with the data being "vectorized?Also, how are you able to simplify
the structure to just "in1= in0[i]??? What happens to the add'l
information, first and second dimensions,  of data included in input_items?

3) The rest looks good. You might consider using NumPy to simplify (and
possible speed up) computations.
I agree.

4) "sync_block" might not be what you want: it assumes 1:1 input:output by
default. The return value is both the number of items to be consumed as
well as were generated. Currently your block isn't generating items, so if
you want to use this inheritance with your block as-is you'll want to call
"consume_each" with the correct number of items & then return 0.

I reverted back to gr.basic_block that I was using where I was returning 0.


The block seems to be working now, however, I've noticed when comparing the
"normalized" values to a generic threshold of 1 or 1.5 for instance, I
always get a message of "No signal present", although I've computed the
median value of each vector length of data and I always get a value greater
than 1 so I'm not quite sure about any() as a comparator. I only notice
this issue with threshold values around 1.

Thanks for all the help you've been able to provide thus far. This effort
is a part of my thesis work for my Master's so your help is greatly
appreciated.



I've included an updated .grc file.


On Thu, Feb 15, 2018 at 10:18 AM, Michael Dickens <michael.dick...@ettus.com
> wrote:

> Hi Tellrell - Yes you're making progress! A few thoughts on the Python:
>
> 1) Except the initial setting of in0, you can replace "input_items[0]" by
> "in0".
>
> 2) I think you can then replace "in1 = input_items[0][:][i]" with just
> "in1 = in0[i]". This works for me & makes sense based on the input_items
> structure.
>
> 3) The rest looks good. You might consider using NumPy to simplify (and
> possible speed up) computations.
>
> 4) "sync_block" might not be what you want: it assumes 1:1 input:output by
> default. The return value is both the number of items to be consumed as
> well as were generated. Currently your block isn't generating items, so if
> you want to use this inheritance with your block as-is you'll want to call
> "consume_each" with the correct number of items & then return 0.
>
> Hope this continues to help & Keep it going! - MLD
>
> On Thu, Feb 15, 2018, at 9:45 AM, Tellrell White wrote:
>
> Thanks Michael for your feedback. I appreciate all the help from you and
> Marcus.
> Updates:
>
> 1) I created a new block "ED Block" derived from gr.sync_block. I believe
> this simplifies things a bit.
>
> 2) Based on the info you provided me Michael on input_items, the
> "vec_length" data, which comes from the third index of input_items is the
> data I want to use in my work function. With this in mind, I've made some
> changes to my work function.
>
> I believe I'm making some progress on the block. I've attached an updated
> copy of the .grc file. Also, is consume_each() needed here? Currently, I'm
> not using it in my script.
>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to