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

[Tellrell White]

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  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

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

[Tellrell White]

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  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

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

[Michael Dickens]

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

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

[Tellrell White]

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.

Tellrell





On Tue, Feb 13, 2018 at 8:27 PM, Marcus D. Leech  wrote:

> 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

>>> ___
>>> 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
>


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

[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

___
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

[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

[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

[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

[CEL]

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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Michael Dickens]

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

[Tellrell White]

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 - 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 throughout to guarantee the # of items is as desired? The FFT block
> is, of course, vectorized; so is the "complex to ||^2" block (or, rather it
> can be; you're not currently using it in this manner). Then, you set the
> energy detector to take in 1 vector of length N (same-same as the FFT and
> ||^2) & you're good to go. Maybe I'm missing something? Hope this is
> useful. - MLD
>
> On Sun, Feb 11, 2018, at 9:00 PM, Tellrell White wrote:
>
> I've created a customized block that takes in a number of input items and
> once that number of input items surpasses a certain number, 1024 of the
> input items are taken and stored into a list, and then those items are
> converted to dB and lastly compared to a threshold value. If any of the
> values are greater than the threshold value, a message is printed
> indicating a signal is present, and if none of the values are greater than
> the threshold, this is indicated with a message stating "No signal is
> present". I've tested the block in both simulation and currently, I'm
> testing the block over the air using the N210. The block performed
> correctly in simulation, however, over the air, the block gives a response
> of "no signal present" regardless of the input. The error message "
>
> python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0
>
> also printed during runtime. Any suggestions are welcome. Both the
> simulation flow graph and the flow graph used over the air are attached.
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Michael Dickens]

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 throughout to guarantee the # of items is as desired? The
FFT block is, of course, vectorized; so is the "complex to ||^2" block
(or, rather it can be; you're not currently using it in this manner).
Then, you set the energy detector to take in 1 vector of length N (same-
same as the FFT and ||^2) & you're good to go. Maybe I'm missing
something? Hope this is useful. - MLD
On Sun, Feb 11, 2018, at 9:00 PM, Tellrell White wrote:
> I've created a customized block that takes in a number of input items
> and once that number of input items surpasses a certain number, 1024
> of the input items are taken and stored into a list, and then those
> items are converted to dB and lastly compared to a threshold value. If
> any of the values are greater than the threshold value, a message is
> printed indicating a signal is present, and if none of the values are
> greater than the threshold, this is indicated with a message stating
> "No signal is present". I've tested the block in both simulation and
> currently, I'm testing the block over the air using the N210. The
> block performed correctly in simulation, however, over the air, the
> block gives a response of "no signal present" regardless of the input.
> The error message " python: Fatal IO error 11 (Resource temporarily
> unavailable) on X server :0.0> also printed during runtime. Any suggestions 
> are welcome. Both the
> simulation flow graph and the flow graph used over the air are
> attached.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Customized Block Giving Incorrect Output

[Tellrell White]

Hello Guys
I've created a customized block that takes in a number of input items and
once that number of input items surpasses a certain number, 1024 of the
input items are taken and stored into a list, and then those items are
converted to dB and lastly compared to a threshold value. If any of the
values are greater than the threshold value, a message is printed
indicating a signal is present, and if none of the values are greater than
the threshold, this is indicated with a message stating "No signal is
present". I've tested the block in both simulation and currently, I'm
testing the block over the air using the N210. The block performed
correctly in simulation, however, over the air, the block gives a response
of "no signal present" regardless of the input. The error message "

python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0

also printed during runtime. Any suggestions are welcome. Both the
simulation flow graph and the flow graph used over the air are attached.

Tellrell White


ener_dtec_sim1.grc
Description: Binary data


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