Re: [Discuss-gnuradio] Change Hierarchical Blocks Import Method?

2013-06-15 Thread Adeel Anwar
Dan,
You can define custom path in */.gnuradio/config.conf *OR export path
to* **GRC_BLOCKS_PATH
*environment variable. See
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition

-Adeel


On Fri, Jun 14, 2013 at 8:22 PM, Dan CaJacob  wrote:

> Would it be possible to change the way hierarchical blocks get imported?
>
> Currently, they get called by execfile with their absolute file path,
> which makes sharing them brittle.  Since hierarchical blocks are expected
> to be in the .grc_gnuradio folder, would it be possible to add that to the
> PYTHONPATH (if it is not already) and treat the Hier blocks as modules in a
> Python Package like HierBlocks?  That way, importing a Hier block could be
> done like:
>
> from HierBlocks import myHierBlock
>
> GRC could generate import statements like the above instead of the current
> execfile, which is system/user specific.
>
> ___
> 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] Cannot import gnuradio

2013-06-15 Thread Tanaga Biru
Dear Helper,

I had installed GNU Radio, but  when I run gnuradio-companion in Ubuntu
Terminal, I received the following message:

*Cannot import gnuradio.*

*Is the python path environment variable set correctly?
*
* All OS: PYTHONPATH*
*
*
*Is the library path environment variable set correctly?*
* Linux: LD_LIBRARY_PATH*
* Windows: PATH*
* MacOSX: DYLD_LIBRARY_PATH*


I had set the path in .bashrc and .profile

export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

Thank you.

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


Re: [Discuss-gnuradio] Cannot import gnuradio

2013-06-15 Thread Arturo Rinaldi

Il 15/06/13 13:02, Tanaga Biru ha scritto:

Dear Helper,

I had installed GNU Radio, but  when I run gnuradio-companion in 
Ubuntu Terminal, I received the following message:


*Cannot import gnuradio.*

*Is the python path environment variable set correctly?
*
*All OS: PYTHONPATH*
*
*
*Is the library path environment variable set correctly?*
*Linux: LD_LIBRARY_PATH*
*Windows: PATH*
*MacOSX: DYLD_LIBRARY_PATH*


I had set the path in .bashrc and .profile

export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

Thank you.

Regards,
Tanaga Biru


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

Hi Tanaga, follow these steps :

*1.* Uninstall gnuradio with "sudo make uninstall"

*2.* Remove all the "export"(s) in the .profile and .bashrc files or 
better leave only :


/export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages/

in the .bashrc file

*3.* go back in the root folder of the gnuradio source and remove the 
"build" folder you used to compile gnuradio.


/rm -rf build//

*4.* Edit the *CMakeLists.txt* file in the gnuradio root folder in the 
following way as described here :


   https://bbs.archlinux.org/viewtopic.php?id=147452

replace :

// /find_package(PythonLibs)/

with :

/find_package(PythonLibs )/

you'll get the python version from your shell

*5.* rebuiild and install gnuradio in the usual way. All the issues 
should be fixed nowLet me know


Kind Regards,

 Arturo

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


[Discuss-gnuradio] Error in tcp.py and patch

2013-06-15 Thread Volker Schroer

Hi,

I just tried to use tcp source/ sink in gnuradio 3.7.0git-126-g72776a40 
and I get the following errors:


The sink side

  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/grc_gnuradio/blks2/tcp.py", 
line 70, in __init__

self.connect(self, gr.file_descriptor_sink(itemsize, fd))
AttributeError: 'module' object has no attribute 'file_descriptor_sink'

and the source side:

  File 
"/usr/local/gnuradio/lib64/python2.7/site-packages/grc_gnuradio/blks2/tcp.py", 
line 59, in __init__

self.connect(gr.file_descriptor_source(itemsize, fd), self)

After applying the attached patch  tcp.py works for me

--Volker
diff --git a/grc/grc_gnuradio/blks2/tcp.py b/grc/grc_gnuradio/blks2/tcp.py
index dfebfcc..c873904 100644
--- a/grc/grc_gnuradio/blks2/tcp.py
+++ b/grc/grc_gnuradio/blks2/tcp.py
@@ -20,6 +20,7 @@
 #
 
 from gnuradio import gr
+from gnuradio import blocks
 import socket
 import os
 
@@ -56,7 +57,7 @@ class tcp_source(gr.hier_block2):
 			gr.io_signature(1, 1, itemsize),
 		)
 		fd = _get_sock_fd(addr, port, server)
-		self.connect(gr.file_descriptor_source(itemsize, fd), self)
+		self.connect(blocks.file_descriptor_source(itemsize, fd,False), self)
 
 class tcp_sink(gr.hier_block2):
 	def __init__(self, itemsize, addr, port, server=False):
@@ -67,4 +68,4 @@ class tcp_sink(gr.hier_block2):
 			gr.io_signature(0, 0, 0),
 		)
 		fd = _get_sock_fd(addr, port, server)
-		self.connect(self, gr.file_descriptor_sink(itemsize, fd))
+		self.connect(self, blocks.file_descriptor_sink(itemsize, fd))
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Cannot import gnuradio

2013-06-15 Thread swrangsar basumatary
hi,

this can happen if you forget to do:

sudo ldconfig





On Sat, Jun 15, 2013 at 4:32 PM, Tanaga Biru  wrote:

> Dear Helper,
>
> I had installed GNU Radio, but  when I run gnuradio-companion in Ubuntu
> Terminal, I received the following message:
>
> *Cannot import gnuradio.*
>
> *Is the python path environment variable set correctly?
> *
> * All OS: PYTHONPATH*
> *
> *
> *Is the library path environment variable set correctly?*
> * Linux: LD_LIBRARY_PATH*
> * Windows: PATH*
> * MacOSX: DYLD_LIBRARY_PATH*
>
>
> I had set the path in .bashrc and .profile
>
> export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
>
> Thank you.
>
> Regards,
> Tanaga Biru
>
> ___
> 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] z = sa ^ random_mask_vec8[o:len(sa)+o]

2013-06-15 Thread yeran
Hi everyone,

I'm using benchmark to do experiment in gun-radio. But at the receiver side, I 
met this problem sometimes, the terminal says " z = sa ^ 
random_mask_vec8[o:len(sa)+o]. ValueError: operands could not be broadcast 
together with shapes (4087) (4081)."  

I tried to print the whiten parameter s and o. In the first packets, s is 
always 8 and o is 0. But then suddently, s change to 4087 and o is 15, so this 
ValueError shows up. 

Actually, I'm not aware that I am changing any settings, but this problem come 
up now and then. Sometimes it is fine, sometimes not. Has anyone come across 
this problem before?

Thanks!

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


Re: [Discuss-gnuradio] Cannot import gnuradio

2013-06-15 Thread Arturo Rinaldi
Nella citazione in data sab 15 giu 2013 17:36:52 CEST, swrangsar 
basumatary ha scritto:

hi,

this can happen if you forget to do:

sudo ldconfig





On Sat, Jun 15, 2013 at 4:32 PM, Tanaga Biru mailto:tanagab...@gmail.com>> wrote:

Dear Helper,

I had installed GNU Radio, but  when I run gnuradio-companion in
Ubuntu Terminal, I received the following message:

*Cannot import gnuradio.*

*Is the python path environment variable set correctly?
*
*All OS: PYTHONPATH*
*
*
*Is the library path environment variable set correctly?*
*Linux: LD_LIBRARY_PATH*
*Windows: PATH*
*MacOSX: DYLD_LIBRARY_PATH*


I had set the path in .bashrc and .profile

export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

Thank you.

Regards,
Tanaga Biru

___
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


I took for granted that Tanaka did "sudo ldconfig" as last step of the 
building process. The Ubuntu derivatives (such as Kubuntu) suffer from 
this issue.


Regards, Arturo

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


Re: [Discuss-gnuradio] scheduler doubt

2013-06-15 Thread Josh Blum


On 06/14/2013 10:21 PM, Yogesh Dahiya wrote:
> sorry for last post it accidentally got posted
> 
> so i have work function which has infinite loop
> while(1):
> #some work
> if condition
> do some more work
> now when this block get turn every thing is stuck on this block, other
> blocks are not given time. Shouldn't it be that after some time it is put
> on hold other blocks are given   cpu time and after some time it get its
> turn back and start from where it left
> 

In general, never block in a work function. If there is no input
available to process, no output to product, just call return.

The only exception is a source block. A source block has no inputs.
Therefore, a source block work is called whenever output buffers are
available.

Users often create source blocks to provide data from a source that is
external to the scheduling environment, like a file, usb, a network
socket...

I recommend that source blocks should only keep the work context for a
limited amount of time (usually a blocking call with a small timeout).
This is because a block's context may have other valuable tasks to perform.

Relevant:
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-05/msg00124.html

> 2. prob
> I want my block to be called  even when there is no input to ports
> (depending on some internal condition which is changing with time i want to
> do some work). So for that i have set
> 
> self.input_config(0).reserve_items = 0
> self.input_config(1).reserve_items = 0
> 
> (I have two input ports) but its not working
> 

Yup thats intentional. No input data is available, therefore, work will
never get called. -- not until input becomes available.

You mentioned an "internal condition". Perhaps when this condition
changes, you can pass a notification message to one of the input ports
of that block. Would that methodology for you?

It would be nice if this internal condition was monitored by another
block which could post a notification message. But also, I should also
mention, there is an API way to post stuff to an input port of a block
from an external entity. See the post_input tag,msg,buffer api calls.
https://github.com/guruofquality/gras/blob/master/include/gras/block.hpp

-josh

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


Re: [Discuss-gnuradio] message buffers

2013-06-15 Thread Josh Blum


On 06/14/2013 07:41 AM, Yogesh Dahiya wrote:
> Am i getting this right
>  With gr.block, each block has bunch of stream ports (vector
> ins,vector outs) and some message port(which we use to specify
> earlier in signature and there numbering use to start after stream ports )
> 
> With gras.block, each block has bunch of ports with bulk_data buffer and
> message queue(which will be posted msg from upstream). So when I am taking
> len(ins[0]) its the length of bulk_data buffer(which buffering stream data
> i guess) so its returning 0.
> 

Yes thats correct. You see, in the old grextras architecture, the
messages support was sort of hacked in. It worked, but it always felt
like it was separate.

With GRAS, a port is more generalized, it can have any type of data.
What type data is available from a port is a question of how the port is
used. I have been calling this "port duck-typing", like the duck-typing
used in some programming languages.

This notion is particularly powerful because you can make blocks which
are totally agnostic about the port's type. For example these
serialization blocks dont care what type a port is, messages, buffers,
tags, you just give them ports and they can serialize/deserialize:

https://github.com/guruofquality/grextras/wiki/Blocks#wiki-de-serialization-io-blocks

> Some more doubts
> 1.when we take length of output buffer m i asking length of output buffer
> available for use (so i don't overwrite previous produced data).

Yes, all of the length is available for you use

> 2. tags are messages(associated with particular bulk_data) so are they
> posted in message queue.(which must be different from actual message queue)

Thats correct. There is actually a separate queue for tags, buffers, and
async messages.

> 3.when we are calling  produce we are basically posting buffer data
> downstream and when we consume we free up the input buffer
> 

Thats correct.

-josh

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