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

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

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

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

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

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

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

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

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

On 02/13/2018 05:15 PM, Glen I Langston wrote: Hello Your discussions are very relevant to an topic we in the radio astronomy group are interested in. We’re looking for transient events and would very much appreciate examples of block implementations that write out selected events, as time

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

Hi Tellrell - OK so now you're getting somewhere! It might help to know that "input_items" is a 3-dimensional array: [stream#][vec_Length#][data_vector], where: "stream#" is the input stream number index starting with 0; "vec_Length#" is an index into incoming data organized by the vector length;

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

Hello Your discussions are very relevant to an topic we in the radio astronomy group are interested in. We’re looking for transient events and would very much appreciate examples of block implementations that write out selected events, as time series or as spectra. Thansk, Best Regards Glen

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

Updates: @ Michael I followed your advice and "vectorized" the complex to mag^2 block creating a variable for vector length equal to 1024, which I set as the vector length of this block. I noticed that this changed the color of the output port of the block. Next, I "vectorized" the custom ED

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

Just another thought: Why convert every single FFT output vector from linear to dB with a logarithm (that's a very complicated function!) just to then compare it to a threshold, if you could also just convert the threshold to linear once? Best regards, Marcus On Mon, 2018-02-12 at 10:21 -0500,

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

In GRC, you open the "complex to ||^2" block settings & set the vector length to whatever you want. I'd advise using a variable that's defined in GRC, and then use it for any blocks that require the vector setting; that way you can change the variable value & all blocks are updated with it. Hope

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

Michael Thanks for the response. That's exactly what I'm trying to accomplish. You mention the "complex to ||^2 can be vectorized. My question is how exactly do you go about doing that? Tellrell On Mon, Feb 12, 2018 at 9:42 AM, Michael Dickens wrote: > Hi Tellrell -

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

Hi Tellrell - So I'm not sure about the non-sim error / issue, but to me the larger question is: what are you really trying to do? If you're trying to detect energy via converting an FFT vector output to dB and thresholding, on a specific number of items per FFT, then why not just use vectors