Well, I believe I may have been using any() incorrectly. For instance, if I want to compare it to a threshold of x i should be saying " (in1_norm>x). any()" where any() will only evaluate if any of the elements of "in1_norm are greater than x.
Also, I've noticed that the "normalized" values tend to range from below zero to in the hundreds depending on the "vec_length" data. Not sure if i'm doing something incorrect here. Tellrell On Thu, Feb 15, 2018 at 3:36 PM, Tellrell White <rell...@gmail.com> wrote: > > 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
