discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Customized Block Giving Incorrect Output


From: Tellrell White
Subject: Re: [Discuss-gnuradio] Customized Block Giving Incorrect Output
Date: Thu, 15 Feb 2018 15:36:18 -0500


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 <address@hidden> 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.



reply via email to

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