date:20180213

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

2018-02-13 Thread Marcus D. Leech

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 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) 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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

2018-02-13 Thread Michael Dickens

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; and "data_vector" is the
actual "vec_Length" of data of the type requested. In your block's case,
the first index will always be [0]; the 2nd index will vary depending on
the number of vectors provided to the block for work by the scheduler
... use "len(input_items[0])" to get the number to iterate over inside
general_work(); finally, the 3rd index will always be in
"range(vec_Length)", for whatever value of "vec_Length" is provided at
instantiation ... this length is guaranteed by the scheduler. I think
with this info you should be able to write the Python code to do
whatever your block needs to do, whether like the version you started
with or more like what Marcus is suggesting. Keep us posted! - MLD
On Tue, Feb 13, 2018, at 4:39 PM, Tellrell White 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)
>  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
>>  > Discuss-gnuradio@gnu.org
>>  > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> Email had 1 attachment:


>  * ener_dtec_sim1.grc 28k (application/octet-stream)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

2018-02-13 Thread Glen I Langston

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

> On Feb 13, 2018, at 4:39 PM, Tellrell White  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)  
> 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
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

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

2018-02-13 Thread Tellrell White

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) 
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
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

ener_dtec_sim1.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

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

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

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

4 matches

Site Navigation

Mail list logo

Footer information