Re: Cant find Qt gui time sink

[Tellrell White]

Sorry.

I cant find it within gnuradio companion. No, there is no error message. I just 
dont see any QT sink options/blocks inside of “instrumentation”. However, all 
of the WX options are visible.



> On Dec 7, 2020, at 3:23 PM, Fabian Schwartau  wrote:
> 
> Hi Tellrell,
> 
> you should provide some more details. Where cant you find it? In GRC? Do
> you have an error message?
> 
> Best regards,
> Fabian
> 
>> Am 07.12.20 um 19:08 schrieb Tellrell White:
>> Hello
>> I cant seem to find the qt gui time sink in version 3.7.11. I downloaded the 
>> binary version available for centos.
>> 
>> Tellrell
>> 
> 
> 

Cant find Qt gui time sink

[Tellrell White]

Hello
I cant seem to find the qt gui time sink in version 3.7.11. I downloaded the 
binary version available for centos.

Tellrell

Ideas for Dissertation Topics

[Tellrell White]

Hello All
I'm in the process of trying to figure out a topic for my dissertation and
I figured I would come here since this forum has provided much help for me
throughout the years. I've done research involving spectrum sensing,
physical layer security and I'm currently looking into lpi/lpd
communications. I think this is a pretty interesting topic, however, I'm
having some difficulty coming up with a unique topic.

Are there any interesting topics you guys have come across?

Tellrell White

[Discuss-gnuradio] "Make Test" fails when installing GNU Radio

[Tellrell White]

Hello All
I'm currently trying to install GNU Radio 3.9.0 on Ubuntu 18.04. Cmake, and
the make command seem to work fine without any issues. When I run make test
I get the following output:

97% tests passed, 10 tests failed out of 364

Total Test time (real) = 142.30 sec

The following tests FAILED:
243 - qa_polar_decoder_sc (Failed)
244 - qa_polar_decoder_sc_list (Failed)
245 - qa_polar_decoder_sc_systematic (Failed)
246 - qa_polar_encoder (Failed)
247 - qa_polar_encoder_systematic (Failed)
360 - qa_zeromq_pub (Failed)
361 - qa_zeromq_pubsub (Failed)
362 - qa_zeromq_pushpull (Failed)
363 - qa_zeromq_reqrep (Failed)
364 - qa_zeromq_sub (Failed)
Errors while running CTest
Makefile:85: recipe for target 'test' failed
make: *** [test] Error 8

>From research, I see some folks have had this issue before and it was
suggested to try

"sudo apt-get install python-scipy" and  "sudo pip install scipy Zmq"

Neither one of these commands worked in my case. Any suggestions?


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

Re: [Discuss-gnuradio] Issue Receiving Messages Using Gr-IEEE-802-15-4

[Tellrell White]

Thanks Bastian
I was able to get it to work by adjusting the tuning frequency and the
gain. I do have an additional question for you. Can the platform be used to
communicate with XBee modules? For example, if I create a message using the
message strobe in the flow graph would I be able to see this message using
an XBee module?

Tellrell

On Thu, Aug 15, 2019 at 5:16 AM Bastian Bloessl  wrote:

> Hi,
>
> there are quite a lot of "XBee" boards. Some of them support multiple
> PHYs etc. So please make sure that the device is actually sending
> standard compliant IEEE 802.15.4 frames on the channel that you are
> tuned to. Use gr-fosphor to make sure that the device is actually
> sending on the frequency that you are expecting.
>
> The transceiver, by default, shows a loopback configuration. Make sure
> it worked, i.e., it showed something in the PCAP file (you have to
> enable the Wireshark block).
> When switching to HW, disable the blocks that loop the samples back to
> the PHY.
>
> If you still have problems, try different gains, make sure the antenna
> is connected to the correct port, make sure there are no overflows. If
> you use an SDR with an uncompensated DC offset, you can also try offset
> tuning.
>
> If that also doesn't work, please provide more information.
>
> Best,
> Bastian
>
>
> On 8/15/19 9:48 AM, Tellrell White wrote:
> > Hello
> > I'm using the GR-IEEE 802.15.4 OQPSK Transceiver and I'm trying to
> > receive a packet from a XBee ZigBee module and then import that packet
> > to wireshark. However, the file sink is always empty after running the
> > flowgraph. I have the rime stack, socket pdu, message strobe, and packet
> > pad all disabled since I'm simply trying to receive a packet. Is there
> > something I need to configure within the MAC block to do this?
> >
> > Tellrell
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> --
> Dr. Bastian Bloessl
> Secure Mobile Networking Lab (SEEMOO)
> TU Darmstadt, Germany
>
> www.bastibl.net
> GitHub/Twitter: @bastibl
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Issue Receiving Messages Using Gr-IEEE-802-15-4

[Tellrell White]

Hello
I'm using the GR-IEEE 802.15.4 OQPSK Transceiver and I'm trying to receive
a packet from a XBee ZigBee module and then import that packet to
wireshark. However, the file sink is always empty after running the
flowgraph. I have the rime stack, socket pdu, message strobe, and packet
pad all disabled since I'm simply trying to receive a packet. Is there
something I need to configure within the MAC block to do this?

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

Re: [Discuss-gnuradio] Symbol to chip Mapping

[Tellrell White]

Okay. Let me make sure i’m clear on this.

My flow graph looks like the following : 

Random source -> packed to unpacked -> chunks to symbols 

The source and packed to unpacked are set to byte and the packed to unpacked is 
outputting 4 bits per chunks so am I setting the dimension of the “chunks to 
symbols” block to 16 (0-15) and inputting 1024 values, 0’s and 1’s, (32 values 
for each dimension) to complete the mapping?

Thanks for the assistance. 

Tellrell

Sent from my iPhone

> On Mar 11, 2019, at 8:28 AM, Achilleas Anastasopoulos  
> wrote:
> 
> Yes this can be done with chunks-to-symbols.
> This is essentially a 16 x 32 lookup table:
> 
> turn your 4 bits into a byte which indices a lookup table with 32 dimensions
> (set the "dimension" variable to 32 in chunks-to-symbols).
> 
> Achilleas

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

[Discuss-gnuradio] Symbol to chip Mapping

[Tellrell White]

Hello All
I have a flow graph in which I'm trying to map 4 bit symbols to 32 bit chip
sequences similar to what was done in GR- IEEE 802.15.4. However, I'm
unsure as to how do this. Is there a way this can be done using an existing
block such as the chunks to symbols block for instance? Attached is a flow
graph of what I have thus far.

Tellrell


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

Re: [Discuss-gnuradio] FFT algorithm used in FFT block

[Tellrell White]

So according to the link the library doesn't utilize one particular algorithm 
but is optimized to use the "best" algorithm depending on n according to this 
link

https://cnx.org/contents/ulXtQbN7@15/Implementing-FFTs-in-Practice

So, is there any particular way to figure out which algorithm is used when 
using the block in a flow graph? 

Tellrell
Sent from my iPhone

> On Apr 1, 2018, at 1:51 AM, Ron Economos <w...@comcast.net> wrote:
> 
> GNU Radio uses the FFTW library.
> 
> http://www.fftw.org/
> 
> Scroll down to the "Literature" section for detailed papers.
> 
> Ron
> 
> 
>> On 03/31/2018 10:01 PM, Tellrell White wrote:
>> Hello
>> Does anyone have any knowledge on the actual FFT algorithm used in the FFT 
>> block in GNU Radio?
>> 
>> Tellrell White
>> 
> 
> 
> ___
> 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] FFT algorithm used in FFT block

[Tellrell White]

Hello
Does anyone have any knowledge on the actual FFT algorithm used in the FFT
block in GNU Radio?

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

[Discuss-gnuradio] XML file for custom python block

[Tellrell White]

Hello
Out of curiosity, I created a custom block by inserting python code into
the "Embedded python Block" from the Misc category. Is there a .xml file
somewhere for this block or a way to easily create one. I'm trying to
transfer the block over to a flow graph running on a a different machine.

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

[Discuss-gnuradio] Performance Issues

[Tellrell White]

Hello Guys
Currently I'm running a flow graph that looks like the following:

UHD Source -> Stream2Vec -> FFT -> Vec2Stream -> Com2Mag^2 ->
CustomBlock(Python)

I'm running this block inside of a virtual machine running ubuntu 14.04
LTS. The host machine runs Windows with an Intel Core i7-4700 MQ processor
running at 2.4GHZ with 8GB of RAM.

Running the flow graph shown above in the VM is a struggle resulting in
freezing after a few seconds so my question is would it better to go
another route for performance, either, by installing UHD and Gnu Radio on
the host machine running windows or using another machine and dual booting
and installing linux, GNU Radio, and UHD for this application?

Regards
Tellrell White
___
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]

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

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

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 <mle...@ripnet.com> 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 <rell...@gmail.com> 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) <muel...@kit.edu>
>>> 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

[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) <muel...@kit.edu>
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

[Discuss-gnuradio] Changing data type of custom block

[Tellrell White]

Hello All
I have a custom sink block that I want to be able to a vector input of
length 1024, however, I can't seem to change the data type of the block.
The code I'm using is the following in which the data type is float and
I've made the vector length equal to 1024, a parameter. The flow graph is
attached.


def __init__(self, num_values=1024, V_len=1024):
gr.basic_block.__init__(self,
name="ED_block",
in_sig=[(np.float, V_len)],
out_sig=[])
self.V_len = V_len
self.num_values = num_values
self.seen = 0


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

[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 <michael.dick...@ettus.com>
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

[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

[Discuss-gnuradio] Analog Bandwidth of UHD Block

[Tellrell White]

Hello
I'm currently using the N210 with the UBX-160 daughterboard and the link
below says the analog bandwidth is 160 MHZ. So, I'm assuming this BW isn't
changeable so what do I put for the channel BW within the UHD block within
GNU Radio?

https://kb.ettus.com/About_USRP_Bandwidths_and_Sampling_Rates

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

[Discuss-gnuradio] OOT Module Not Working Properly

[Tellrell White]

Hello Guys

I'm creating a customized block in the GNU Radio framework using python
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 an array, and then those items are converted to dB and lastly compared
to a threshold value, 5 in this case. 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 5, this is indicated with a
message stating "No signal is present".

In the flow graph attached, I'm using a cosine source and a gaussian noise
source to test my block in two different scenarios.

In scenario 1, I run the flow graph with both signal sources and I expect
to receive a message stating "A signal is present" because the power of the
signal will be greater than the threshold.

In scenario 2, the cosine source is disabled and only the noise source is
runing. In this scenario I expect to get a message indicating no signal is
present because the calculated power will be lower than the threshold.

Scenario 1 works, however, scenario 2 doesn't work no matter how high I
raise the threshold value and, at this point, I'm not quite sure as to why.

Any help would be appreciated. Both the .py script for the oot block and
the .grc file are included.

Tellrell


Ener_detec.py
Description: Binary data


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

Re: [Discuss-gnuradio] Float is required error for customized Block

[Tellrell White]

I made two edits to the code. I took out float() and took Gilad's
suggestion to use np.log10() which operates on a list. Making these changes
results in the following error

 c = np.log10(in1) #converts 1024 values stored in in1 to dB and
stores them in c
AttributeError: log10
thread[thread-per-block[8]: ]: caught unrecognized
exception

I'm assuming its because of the size of the values.

On Tue, Jan 2, 2018 at 11:26 PM, Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> Have just looked at your code from my mobile.
> You want to check numpy.log10 and numpy.greater (there will be other ways
> to do the same thing).
>
>
> On Tue, Jan 2, 2018, 20:18 Gilad Beeri (ApolloShield) <
> gi...@apolloshield.com> wrote:
>
>> This is related to Python, not GNU Radio per se. It seems that you pass
>> in1 to math.log10().
>> I assume that you define in1 as input_items[1], which is a list of items
>> to process (not a single item), while the log function expects to get a
>> float, not a list.
>>
>> Something like:
>> for item in in1:
>>   c = math.log10(item)
>>
>> should work for you. I guess there's a numpy function that will run the
>> log function on a list more efficiently.
>>
>>
>>
>> On Tue, Jan 2, 2018, 20:10 Tellrell White <rell...@gmail.com> wrote:
>>
>>> Hello Guys
>>>
>>> I'm creating a customized block in the GNU Radio framework using python
>>> 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 an array, and then those items are converted to dB and lastly compared
>>> to a threshold value, 5 in this case. 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 5, this is indicated with a
>>> message stating "No signal is present".
>>>
>>> When I run the flow graph which uses this block I get the following
>>> error.
>>>
>>> handler caught exception: a float is required
>>> Traceback (most recent call last):
>>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
>>> line 55, in eval
>>> try: self._callback()
>>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
>>> line 144, in __gr_block_handle
>>> ) for i in self.__out_indexes],
>>>   File "/home/tellrell/Ener_detec.py", line 42, in general_work
>>> c = math.log10(in1) #converts 1024 values stored in in1 to
>>> dB and stores them in c
>>> TypeError: a float is required
>>> thread[thread-per-block[8]: ]: caught unrecognized
>>> exception
>>>
>>>
>>>
>>> The .py script for the customized block along with the corresponding
>>> .grc file are attached below.
>>>
>>> Any help would be great.
>>>
>>> Tellrell
>>> ___
>>> 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] Float is required error for customized Block

[Tellrell White]

Hello Guys

I'm creating a customized block in the GNU Radio framework using python
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 an array, and then those items are converted to dB and lastly compared
to a threshold value, 5 in this case. 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 5, this is indicated with a
message stating "No signal is present".

When I run the flow graph which uses this block I get the following error.

handler caught exception: a float is required
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
line 55, in eval
try: self._callback()
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
line 144, in __gr_block_handle
) for i in self.__out_indexes],
  File "/home/tellrell/Ener_detec.py", line 42, in general_work
c = math.log10(in1) #converts 1024 values stored in in1 to dB
and stores them in c
TypeError: a float is required
thread[thread-per-block[8]: ]: caught unrecognized
exception



The .py script for the customized block along with the corresponding .grc
file are attached below.

Any help would be great.

Tellrell


Ener_detec.py
Description: Binary data


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

Re: [Discuss-gnuradio] Data types

[Tellrell White]

No Marcus I haven't. Thanks for the response. Honestly, I didn't know I had
to in order to configure the data type of my block. How exactly do I go
about doing this and is there any documentation on the process??

Regards
Tellrell

On Wed, Nov 1, 2017 at 12:47 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Have you modified the GRC .xml file accordingly?
>
> On 01.11.2017 16:29, Tellrell White wrote:
>
>  Thanks for the response. In the code below, I'm matching the output type
> of the divide block which is float and also the length which I'm setting
> here as  for v_len. However, I'm still not seeing any change. I'm also
> doing this in python. Any ideas?
>
> def __init__(self, num_values=1024, V_len=1024):
> gr.basic_block.__init__(self,
> name="ED_block",
> in_sig=[(np.float, V_len)],
> out_sig=[])
> self.V_len = V_len
> self.num_values = num_values
> self.seen = 0
>
> Regards
> Tellrell
>
> On Wed, Nov 1, 2017 at 3:46 AM, Andrej Rode <m...@andrejro.de> wrote:
>
>> Hir ,
>>
>> On Tue, Oct 31, 2017 at 11:03:57PM -0400, Tellrell White wrote:
>> > Hello All
>> > I have a question concerning data types. I'm creating a sink block in
>> python that takes float values from a "divide" block that has a vector
>> length of 1024. The output port on the divide block is red. How can set the
>> input of my block to have a red input port?
>>
>> You need to match the output type of the divide block (which is probably
>> float) _and_ you need to match the vector length of the divide block.
>> Best done with setting a parameter `vlength` and setting this as your
>> io_signature in the constructor:
>> `io_signature::make (1,  1, sizeof (float)*vlen)),`
>>
>> This creates a block with a configurable vector length as input.
>>
>> Cheers
>> Andrej
>> --
>> Andrej Rode
>> GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
>>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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] Data types

[Tellrell White]

 Thanks for the response. In the code below, I'm matching the output type
of the divide block which is float and also the length which I'm setting
here as  for v_len. However, I'm still not seeing any change. I'm also
doing this in python. Any ideas?

def __init__(self, num_values=1024, V_len=1024):
gr.basic_block.__init__(self,
name="ED_block",
in_sig=[(np.float, V_len)],
out_sig=[])
self.V_len = V_len
self.num_values = num_values
self.seen = 0

Regards
Tellrell

On Wed, Nov 1, 2017 at 3:46 AM, Andrej Rode <m...@andrejro.de> wrote:

> Hir ,
>
> On Tue, Oct 31, 2017 at 11:03:57PM -0400, Tellrell White wrote:
> > Hello All
> > I have a question concerning data types. I'm creating a sink block in
> python that takes float values from a "divide" block that has a vector
> length of 1024. The output port on the divide block is red. How can set the
> input of my block to have a red input port?
>
> You need to match the output type of the divide block (which is probably
> float) _and_ you need to match the vector length of the divide block.
> Best done with setting a parameter `vlength` and setting this as your
> io_signature in the constructor:
> `io_signature::make (1,  1, sizeof (float)*vlen)),`
>
> This creates a block with a configurable vector length as input.
>
> Cheers
> Andrej
> --
> Andrej Rode
> GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Data types

[Tellrell White]

Hello All
I have a question concerning data types. I'm creating a sink block in python 
that takes float values from a "divide" block that has a vector length of 1024. 
The output port on the divide block is red. How can set the input of my block 
to have a red input port?

Regards
Tellrell

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

[Discuss-gnuradio] PSD Estimation in GRC

[Tellrell White]

Hello All
Does anyone have any experience with implementing an averaged periodogram in 
grc?? Would this be something that could be done with pre-existing blocks or 
would a custom block be better?

Regards
Tellrell 

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

Re: [Discuss-gnuradio] Energy Detection output incorrect

[Tellrell White]

Sorry for the confusing explanation, but yes, I'm trying to find the
average energy over frequencies.

1. What I'm doing, at least as a start, is signal detection of 802.15.4
waveform using energy detection focusing on the O-QPSK PHY operating at the
2.4 Ghz band. The O-QPSK PHY uses a 32 bit chip sequence for spreading the
signal.

2. From research, I can see that other forms of detection such as matched
filter detection would be a lot better for an application of this sort.
However, energy detection was chosen to start with because of its lack of
complexity. The focus at the moment is more on the feasibility of this
approach. In the future, other approaches or methods will be considered
also.

Tellrell

On Thu, Sep 21, 2017 at 8:40 PM, Tellrell White <rell...@gmail.com> wrote:

> Thanks Marcus
>
> Sorry for the confusing explanation, but yes, I'm trying to find the
> average energy over frequencies.
>
> 1. What I'm doing, at least as a start, is signal detection of 802.15.4
> waveform using energy detection focusing on the O-QPSK PHY operating at the
> 2.4 Ghz band. The O-QPSK PHY uses a 32 bit chip sequence for spreading the
> signal.
>
> 2. From research, I can see that other forms of detection such as matched
> filter detection would be a lot better for an application of this sort.
> However, energy detection was chosen to start with because of its lack of
> complexity. The focus at the moment is more on the feasibility of this
> approach. In the future, other approaches or methods will be considered
> also.
>
> Tellrell
>
>
> On Thu, Sep 21, 2017 at 5:36 PM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Hi Tellrell,
>>
>> I know you can find the PSD
>>
>> Ah, so you're actually after a PSD estimate – It wasn't clear to me what
>> you were looking for, because the FFT-> frequency sink flowgraph didn't
>> make sense. And you just said "average energy" (not "average energy over
>> frequencies"), so I was kind of confused; sorry!
>>
>> So, ultimately, if the way that I'm implementing the algorithm is correct
>> thus far, I'm looking for a way to display(graphically or otherwise) my
>> result or the avg power.
>>
>> It's impossible to say whether an algorithm is correct without specifying
>> what it should be doing - so maybe we need to take a step back:
>>
>> 1. you want to do detection of IEEE 802.15.4 signals. Which PHY are we
>> talking about? There's multiple physical layers for that standard. The DSSS
>> types aren't really … friendly towards energy detection at all.
>> 2. pure DFT-bases spectral estimation without preprocessing or
>> postprocessing is usually not the optimum method for signals that don't
>> have a spectral sinc shape; they're just easy to implement. Usually, you'd
>> try to detect using as much info about what the signal of interest is as
>> possible – especially in the presence of other systems.
>>
>> Best regards,
>>
>> Marcus
>> On 09/21/2017 11:32 AM, Tellrell White wrote:
>>
>> Thanks for the replies guys
>>
>> Marcus I know you can find the PSD of a signal in both the time and
>> frequency domain. The only reason I'm choosing to use the frequency domain
>> is because it was one of the earlier methods that I learned about. That's
>> really all. From the archives I've read about people trying to implement
>> energy detectors in GNU Radio for various applications but I never saw
>> anybody display the results in any way or form. They mostly just send the
>> statistics to a file sink and export to matlab or some other software for
>> further processing. So, ultimately, if the way that I'm implementing the
>> algorithm is correct thus far, I'm looking for a way to display(graphically
>> or otherwise) my result or the avg power.
>>
>> Nathan would you remove the vector to stream block as well? And, why
>> would you have to remove the stream to vector block? Isn't that the format
>> that I want the data in? Also, how do you go about adding "vector modes" to
>> the remaining blocks?
>>
>> Tellrell
>>
>> On Thu, Sep 21, 2017 at 1:30 PM, West, Nathan <
>> n...@ostatemail.okstate.edu> wrote:
>>
>>> You can use the qt gui vector plot to plot a vector. That means removing
>>> the stream to vector block. You might have to add "vector" modes to some
>>> blocks to do the other operations you want.
>>>
>>> On Wed, Sep 20, 2017 at 6:31 PM, Tellrell White <t_whit...@yahoo.com>
>>> wrote:
>>>
>>>> Hello Marcus
>>>> You are absolutely correct. Is there an

Re: [Discuss-gnuradio] Energy Detection output incorrect

[Tellrell White]

Thanks for the replies guys

Marcus I know you can find the PSD of a signal in both the time and
frequency domain. The only reason I'm choosing to use the frequency domain
is because it was one of the earlier methods that I learned about. That's
really all. From the archives I've read about people trying to implement
energy detectors in GNU Radio for various applications but I never saw
anybody display the results in any way or form. They mostly just send the
statistics to a file sink and export to matlab or some other software for
further processing. So, ultimately, if the way that I'm implementing the
algorithm is correct thus far, I'm looking for a way to display(graphically
or otherwise) my result or the avg power.

Nathan would you remove the vector to stream block as well? And, why would
you have to remove the stream to vector block? Isn't that the format that I
want the data in? Also, how do you go about adding "vector modes" to the
remaining blocks?

Tellrell

On Thu, Sep 21, 2017 at 1:30 PM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> You can use the qt gui vector plot to plot a vector. That means removing
> the stream to vector block. You might have to add "vector" modes to some
> blocks to do the other operations you want.
>
> On Wed, Sep 20, 2017 at 6:31 PM, Tellrell White <t_whit...@yahoo.com>
> wrote:
>
>> Hello Marcus
>> You are absolutely correct. Is there an existing sink that would allow me
>> to display avg power given some threshold ?
>>
>> Tellrell
>>
>>
>> On Wednesday, September 20, 2017 5:54 PM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>
>> Hi Tellrell!
>> Why should both plots show the same? You send in completely different
>> signals!
>> Best regards,
>> Marcus
>>
>> On 09/20/2017 09:27 AM, Tellrell White wrote:
>>
>> Hello All
>> I'm working on a project involving signal detection of an IEEE 802.15.4
>> waveform using energy detection.
>> The algorithm for energy detection goes as follows:
>>
>>   A/D conversion ->  FFT -> mag^2 -> (1/N) ^ M -> threshold
>> comparison
>>
>> Currently, I'm doing simulations in gnuradio companion with a focus of
>> just trying to construct the the algorithm and get an output. Below I've
>> attached the current flowgraph i'm using along with screen shots of the
>> flowgraph and the outputs from the fft sinks.
>>
>> In the flowgraph i'm using gaussian noise as my source. I send this noise
>> to both an FFT sink and also through the energy detection algorithm. My
>> expectation is that both sinks will give me the same result, however, the
>> output coming from the algorithm doesn't match the other sink and I'm
>> currently now sure why this is. Are there some blocks I'm currently missing
>> and/or is the FFT sink an incorrect way of trying to display the power
>> coming from the energy detection algorithm?
>>
>> Any suggestions are welcome.
>>
>> Regards
>> Tellrell
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Energy Detection output incorrect

[Tellrell White]

Hello MarcusYou are absolutely correct. Is there an existing sink that would 
allow me to display avg power given some threshold ?
Tellrell  

On Wednesday, September 20, 2017 5:54 PM, Marcus Müller 
<marcus.muel...@ettus.com> wrote:
 

  Hi Tellrell! Why should both plots show the same? You send in completely 
different signals!
  Best regards, Marcus
  
 On 09/20/2017 09:27 AM, Tellrell White wrote:
  
 
 Hello All
  I'm working on a project involving signal detection of an IEEE 802.15.4 
waveform using energy detection. 
 The algorithm for energy detection goes as follows: 
 
           A/D conversion ->  FFT -> mag^2 -> (1/N) ^ M -> threshold comparison
 
 Currently, I'm doing simulations in gnuradio companion with a focus of just 
trying to construct the the algorithm and get an output. Below I've attached 
the current flowgraph i'm using along with screen shots of the flowgraph and 
the outputs from the fft sinks. 
 
  In the flowgraph i'm using gaussian noise as my source. I send this noise to 
both an FFT sink and also through the energy detection algorithm. My 
expectation is that both sinks will give me the same result, however, the 
output coming from the algorithm doesn't match the other sink and  I'm 
currently now sure why this is. Are there some blocks I'm currently missing 
and/or is the FFT sink an incorrect way of trying to display the power coming 
from the energy detection algorithm?
 
  Any suggestions are welcome.
 
  Regards
  Tellrell
  
  
 ___
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] OOT Block to Automatically adjust Transmit Gain

[Tellrell White]

In the attached flow graph, I've created a block, "gain setter" that takes
in a number of input items and after the input items reach a certain
amount, the block will issue a command to the ursp sink to change the gain
to a certain value. I basically did this using a loop. However, it doesn't
seem like the gain of the signal changes according to the freq sink plot of
the received signal. Any ideas??

On Thu, Jul 13, 2017 at 2:48 PM, Bakshi, Arjun <
bakshi...@buckeyemail.osu.edu> wrote:

> Couldn't figure out how to reply from the digest, so I'm making a new
> post. New to this.
>
>
> Original message/context:
>
> ======
>
> *From*: Tellrell White
>
> I'm currently in the process of creating a block in python that does two
> things; takes in? a certain number of input items, and once it reaches a
> certain number of input items 2) it sends a command to the UHD USRP sink
> block to adjust its gain by a certain amount.
>
> I have a few questions. 1) Is it even possible to create a single block
> that can accomplish both these tasks? 2) How exactly do I make this block
> issue the command to adjust the gain after it receives a certain number of
> values??Below is some code that I currently have constructed for this
> purpose. I'm pretty new to python so I'm sure this code is probably not the
> most efficient way but any suggestions are welcome.
>
>
> ===
>
>
> Hey Tellrell,
>
>
> 1) I think it can be achieved using 1 block. The block will need to output
> a * message* with "gain" and the gain value whenever the input matches
> your condition. Connect the output *message* port to the USRP sink's
> command port. Message should be a pmt that looks something like ("gain",
> value).
>
>
> More info on the command port: https://gnuradio.org/doc/
> doxygen/page_uhd.html#uhd_command_syntax
>
>
>
> 2) I went ahead and implemented something as an example. Increases gain
> upto a limit and then starts over again. See attached code, xml for block,
> rxed signal plot, and flowgraph pic.
>
> I'm new to this too, so hopefully other will correct my mistakes.
>
> Regards,
>
> AB
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] OOT Block to Automatically adjust Transmit Gain

[Tellrell White]

I tried responding to this before but I'm not sure if it actually posted so
I'm using a different email address.

Thanks for your response Baskshi. I looked at the code you implemented,  in
addition to looking at the information on message passing on doxygen.

I've tried creating my own code that would adjust the gain by a certain
amount(0.5 dB) after receiving a certain number of samples. However, after
the block receives the required number of input samples, I want it to send
out 12 0's in addition to sending the sink block a command to adjust the
gain. I believe sending out the 12 0's should be handled in the forecast
function but I'm not sure if I'm going about doing this correctly.

I've attached my flow graph and the code for this "gain setter" block. Any
feedback would be great.

Tellrell

On Mon, Jul 17, 2017 at 1:07 PM, Tellrell White <t_whit...@yahoo.com> wrote:

> Thanks for your response Baskshi. I looked at the code you implemented,
> in addition to looking at the information on message passing on doxygen.
>
> I've tried creating my own code that would adjust the gain by a certain
> amount(0.5 dB) after receiving a certain number of samples. However, after
> the block receives the required number of input samples, I want it to send
> out 12 0's in addition to sending the sink block a command to adjust the
> gain. I believe sending out the 12 0's should be handled in the forecast
> function but I'm not sure if I'm going about doing this correctly.
>
> I've attached my flow graph and the code for this "gain setter" block. Any
> feedback would be great.
>
> Tellrell
>
>
> On Thursday, July 13, 2017 2:48 PM, "Bakshi, Arjun"
> <bakshi...@buckeyemail.osu.edu> wrote:
>
>
> Couldn't figure out how to reply from the digest, so I'm making a new
> post. New to this.
>
> Original message/context:
> ==
> *From*: Tellrell White
>
> I'm currently in the process of creating a block in python that does two
> things; takes in? a certain number of input items, and once it reaches a
> certain number of input items 2) it sends a command to the UHD USRP sink
> block to adjust its gain by a certain amount.
>
> I have a few questions. 1) Is it even possible to create a single block
> that can accomplish both these tasks? 2) How exactly do I make this block
> issue the command to adjust the gain after it receives a certain number of
> values??Below is some code that I currently have constructed for this
> purpose. I'm pretty new to python so I'm sure this code is probably not the
> most efficient way but any suggestions are welcome.
>
> ===
>
> Hey Tellrell,
>
> 1) I think it can be achieved using 1 block. The block will need to output
> a * message* with "gain" and the gain value whenever the input matches
> your condition. Connect the output *message* port to the USRP sink's
> command port. Message should be a pmt that looks something like ("gain",
> value).
>
> More info on the command port: https://gnuradio.org/doc/
> doxygen/page_uhd.html#uhd_command_syntax
>
>
> 2) I went ahead and implemented something as an example. Increases gain
> upto a limit and then starts over again. See attached code, xml for block,
> rxed signal plot, and flowgraph pic.
>
> I'm new to this too, so hopefully other will correct my mistakes.
>
> Regards,
>
> AB
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
"""
Embedded Python Blocks:

Each this file is saved, GRC will instantiate the first class it finds to get
ports and parameters of your block. The arguments to __init__  will be the
parameters. All of them are required to have default values!
"""
import numpy as np
from gnuradio import gr
import pmt
from random import uniform
import pdb

class blk(gr.basic_block):
def __init__(self, initial_gain=5, stop_gain=15, step=0.5):# only default arguments here
gr.basic_block.__init__(
self,
name='Gain Sweeper',
in_sig=[np.complex64],
out_sig=[np.complex64]
)
   
self.message_port_register_out(pmt.intern('msg_out'))
self.gain = initial_gain
self.step = step
self.stop = stop_gain
self.count = 0
self.a = 


#def forecast(self, noutput_items, ninput_items_required):
 #   #setup size of input_items[i] for work call
  #  for i in range(len(ninput_items_required)):
   # ninput_items_required[i] = noutput_items + a


def general_work(self, input_items, output_items):
 #creating va

[Discuss-gnuradio] Using the forecast() function

[Tellrell White]

Hello GuysI have a block that I'm developing using python that will ultimately 
take in a certain amount of items and as a result, do two things: send a 
message to the sink block and also output a stream of 12 samples.

My question is how to exactly account for this within the forecast function?? 
For instance, if for every 10 items received, I only wanted to output 2 
samples. How exactly should my forecast function reflect this? 

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

[Discuss-gnuradio] OOT Block to Automatically adjust Transmit Gain

[Tellrell White]

Hello Guys 
I'm currently in the process of creating a block in python that does two 
things; takes in  a certain number of input items, and once it reaches a 
certain number of input items 2) it sends a command to the UHD USRP sink block 
to adjust its gain by a certain amount. 

I have a few questions. 1) Is it even possible to create a single block that 
can accomplish both these tasks? 2) How exactly do I make this block issue the 
command to adjust the gain after it receives a certain number of values??Below 
is some code that I currently have constructed for this purpose. I'm pretty new 
to python so I'm sure this code is probably not the most efficient way but any 
suggestions are welcome.
Tellrell 
import numpy as np
from gnuradio import gr
import pmt
from random import uniform

class blk(gr.sync_block):
    def __init__(self, initial_gain=5, stop_gain=15, step=0.5)# only default 
arguments here
    gr.sync_block.__init__(
    self,
    name='Gain Sweeper',
    in_sig=[np.complex32],
    out_sig=[np.complex32]
    )
    self.message_port_register_in(pmt.intern('msg_in'))
    self.set_msg_handler(pmt.intern('msg_in'),self.handle_msg)
    self.message_port_register_out(pmt.intern('msg_out'))
    self.gain = initial_gain
    self.step = step
    self.stop = stop_gain


    def handle_msg(self, pdu, a= 00):
    self.message_port_pub(pmt.intern('msg_out'),pmt.cons
    (pmt.intern("gain"),pmt.to_pmt(self.gain)))
    self.gain+=self.step
    
    return 1


    def work(self, input_items, output_items):
    in0 = input_items[0]
    out = output_items[0]
    
    while i <= 1:
 sample = in0[i]
 if i == 1:
    sample = 0

    return len(output_items[0])



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

[Discuss-gnuradio] Tracking Number of Input Items

[Tellrell White]

Hello
I want to know is there a way or even a block that already exists that will
allow you to send a message(pdu) after receiving a certain amount of input
items?? Any info would be great.

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

[Discuss-gnuradio] Automating Transmit Gain

[Tellrell White]

Hello GuysI want to have the uhd sink block in my flow graph automatically 
cycle through a number of transmit gain values. I'm thinking of developing two 
blocks, one which will take in  a certain number of items and once it reaches a 
certain value a message will be sent to another block which will send a command 
to the uhd sink block to adjust the gain by a certain amount. I'm wondering if 
I could accomplish this task by just creating a single block similar to the 
"tagged stream to pdu" which takes in a stream of data and outputs a message. 
Any feedback would be greatly appreciated.
ThanksTellrell 

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

Re: [Discuss-gnuradio] Changing transmit gain

[Tellrell White]

Well, from looking at doxygen I see the appropriate syntax and key needed to do 
this. I guess the question is would I have to modify the .py file or is there a 
block I could modify to accomplish this?
Tellrell White  

On Friday, June 23, 2017 8:13 AM, Tellrell White <t_whit...@yahoo.com> 
wrote:
 

 Thanks for the reply Marcus. Sorry for not attaching the flow graph. I've 
attached it now. Is there an example somewhere of the method you speaking of? 
I'm still pretty new to gnuradio so I'm a little unsure of how to proceed.
ThanksTellrell
 

On Thursday, June 22, 2017 5:28 AM, Marcus Müller 
<marcus.muel...@ettus.com> wrote:
 

   Hi Tellrell, um, that's kind of hard to tell without knowing your flow 
graph! However, if you've got a block (eg. the USRP Sink) that allows 
configuration through async message passing: Try my gr-msgblock OOT Module, and 
use/modify variable_to_msg to translate the variable to a message that you send 
to that block. Best regards, Marcus 
  
 On 06/21/2017 05:26 PM, Tellrell White wrote:
  
 Hello Guys
 I have a flowgraph attached where I'm trying to generate BER curves for 
different transmit gain values. Right now, I have gui slider that allows me to 
adjust the gain values, however, I would like to know if it's possible to have 
the gain values adjust automatically by changing the python script for the 
flowgraph. If so, I would appreciate any ideas or examples on how to do this.
 
 Thanks
 Tellrell White 
  
  
 ___
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] Changing transmit gain

[Tellrell White]

Thanks for the reply Marcus. Sorry for not attaching the flow graph. I've 
attached it now. Is there an example somewhere of the method you speaking of? 
I'm still pretty new to gnuradio so I'm a little unsure of how to proceed.
ThanksTellrell
 

On Thursday, June 22, 2017 5:28 AM, Marcus Müller 
<marcus.muel...@ettus.com> wrote:
 

   Hi Tellrell, um, that's kind of hard to tell without knowing your flow 
graph! However, if you've got a block (eg. the USRP Sink) that allows 
configuration through async message passing: Try my gr-msgblock OOT Module, and 
use/modify variable_to_msg to translate the variable to a message that you send 
to that block. Best regards, Marcus 
  
 On 06/21/2017 05:26 PM, Tellrell White wrote:
  
 Hello Guys
 I have a flowgraph attached where I'm trying to generate BER curves for 
different transmit gain values. Right now, I have gui slider that allows me to 
adjust the gain values, however, I would like to know if it's possible to have 
the gain values adjust automatically by changing the python script for the 
flowgraph. If so, I would appreciate any ideas or examples on how to do this.
 
 Thanks
 Tellrell White 
  
  
 ___
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] Changing transmit gain

[Tellrell White]

Hello Guys
I have a flowgraph attached where I'm trying to generate BER curves for
different transmit gain values. Right now, I have gui slider that allows me
to adjust the gain values, however, I would like to know if it's possible
to have the gain values adjust automatically by changing the python script
for the flowgraph. If so, I would appreciate any ideas or examples on how
to do this.

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

Re: [Discuss-gnuradio] Gr-Inspector Install error

[Tellrell White]

I'm running the live_signal_detection. I replaced the rtlsdr_source block with 
a signal source block. When I run the flowgraph I get 

    "attributerror: Module object has no attribute 'signal_detector_cvf"
I tried deleting and reinstalling all the dependencies before installing 
gr-inspector but I'm getting the same result.
RegardsTellrell White  

On Tuesday, February 7, 2017 7:53 AM, Christopher Richardson 
 wrote:
 

 Hi Tellrell,

Which flow graph are you running?

Cheers
Chris

___
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] Module has no 'attribute'---OOT Module

[Tellrell White]

I just recently installed the gr-inspector oot module. When I tried to run
a flow-graph using one of the blocks from the module I got the following
error.

AttributeError: 'module' object has no attribute 'signal_detector_cvf'


I also got the warnings below we I started grc.

Warning: Block key "signal_detector_cvf" not found when loading category
tree.
Warning: Block key "signal_separator_c" not found when loading category
tree.
Warning: Block key "signal_extractor_c" not found when loading category
tree.
Warning: Block key "ofdm_synchronizer_cc" not found when loading category
tree.
Warning: Block key "tfmodel_vcf" not found when loading category tree.
Warning: Block key "vis3d_vf" not found when loading category tree.
Warning: Block key "ofdm_zkf_c" not found when loading category tree.
Warning: Block key "qtgui_sink_vf" not found when loading category tree

Not sure what possibly went wrong. Any ideas??

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

[Discuss-gnuradio] Gr-Inspector Install error

[Tellrell White]

Hello all

I just recently installed Gr-Inspector and when I try to run a flow graph I
get the error below.

/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/ActionHandler.py:78:
Warning: Source ID 403 was not found when attempting to remove it
  gtk.main()
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/BlockTreeWindow.py:221:
Warning: Source ID 411 was not found when attempting to remove it
  self.treeview.set_model(self.treestore_search)
*** Error in `/usr/bin/python2': double free or corruption (!prev):
0x02320520 ***

Not quite sure but I think when installed tensorflow that it may have
changed my python install and possibly caused this error. Hopefully someone
can provide some feedback.

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

Re: [Discuss-gnuradio] gr-ieee 802.15.4

[Tellrell White]

That did it. Thanks. 
 I'm now able to see an output. Just out of curiosity, is the packet pad really 
needed??
I have it connected to the rx-in port of the IEEE 802.15.4 PHY. Without anyting 
connected to that port I'm getting a qpsk demod error. 

RegardsTellrell  

On Wednesday, January 25, 2017 7:33 AM, Bastian Bloessl 
<bloe...@ccs-labs.org> wrote:
 

 On 01/25/2017 11:19 AM, Tellrell White wrote:
> I'm looking at energy detection of an IEEE 802.15.4 signal. I was hoping
> to be able to utilize the development done minus the higher layer
> functionality and use the physical layer transceiver sending some data
> so that I could do the energy detection. However, I believe I have made
> some errors in the process. In the file attached, I'm not able to see to
> any frequency output.

you will have to put a "Stream to Tagged Stream" block between the
vector source and your tagged stream to PDU block.

Apart from that, you should add a throttle block. Otherwise the flow
graph will run as fast as possible (i.e., use 100% CPU).

Best,
Bastian


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