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: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Customized Block Giving Incorrect Output
Date: Tue, 13 Feb 2018 20:27:16 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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 series or as spectra.

Thansk,

Best Regards

Glen
My old "meteor_detector" application did something like this, in that it looked for sudden transients, and then recorded while the signal was above threshold,
  along with some history.

For transients of not-tiny timescales, a Python block, using the GRC Python-block infrastructure could easily be constructed, I'm sure to do this sort of thing.


On Feb 13, 2018, at 4:39 PM, Tellrell White <address@hidden> wrote:

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 block as well. One question I do have is is 
there a way to find out the length of the input vector that is passed to the block just 
to confirm that there are 1024 values being passed? I checked the length of the 
input_items used in the work function and it prints 1, which I'm assuming is equal to an 
array of length 1024 since this is the vector length parameter i set in the ED block and 
also, because this is the vector length I set for the complex to mag^2 block as well.

As a result of making these changes to the custom block, now, I'm simply taking 
the array of input_items, normalizing them, and then comparing to a threshold 
as before. I'm assuming this is all that needs to be done assuming the block is 
taking in vectors of length 1024.

@Marcus I think your question does warrant some consideration and perhaps is 
the better approach. Besides this approach being easier, and I'm assuming less 
of a strain on the cpu are there any other reasons for this approach?


I've attached an updated flow graph used for testing

On Mon, Feb 12, 2018 at 11:36 AM, Müller, Marcus (CEL) <address@hidden> wrote:
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, Michael Dickens wrote:
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 this is useful. - MLD

On Mon, Feb 12, 2018, at 10:17 AM, Tellrell White wrote:
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?
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<ener_dtec_sim1.grc>_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

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