Re: [Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc
On 10/05/2014 04:25 AM, Gisle Vanem wrote: Since my previous message seems to be ignored, here is something simpler for you to comment on. In gr-blocks/lib/stream_pdu_base.cc, the read() and write() functions are used on sockets. This doesn't work well on Windows as you're probably aware. A simple fix is to has something like this at the top of this file: #ifdef WIN32 #undef read #undef write #define read(sk,buf,len) ::recv (sk, (char*)(buf), len, 0) #define write(sk,buf,len) ::send (sk, (const char*)(buf), len, 0) #endif I'm sure Boost have some better fix for this, but I don't know Boost. The issue is that the stream_pdu_base file descriptor is both a network socket for socket_pdu and tuntap handle for tuntap_pdu. Calling ::recv() and ::send() would be a good cross platform solution for the socket case, but im not sure if that will work for the tuntap (which is linux specific anyway). Ideally we could switch the code to call send/recv, and the tuntap would continue working -- this needs testing. Your patch is pretty good too, because it doesnt interfere with existing functionality, and the tuntap is ifdefed out on windows. The best way to upstream patches seems to be through github. I recommend creating a github pull request for this change, and some of the other changes you mentioned in the previous email. -josh --gv ___ 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] change a block parameter using a python script
On 01/27/2014 11:19 PM, Marco Bosco wrote: Hi all! I have a simple flowgraph: a signal source, a throttle and a waterfall plot. I'd like to change the frequency of the signal source during runtime using the output of a python script. The output of the python script is time-varying, then I should see some variations in the plot during runtime. How can be this done? Is there a 'simple' way? Take a look at the XML RPC blocks in GRC. If you are not using GRC, its still pretty simple to create an xml rpc server in python, and register the signal source's .set_frequency() parameter into the server. Then your python script that is performing the control can talk to the xml rpc client (it was a separate file from the flow graph, right?). http://docs.python.org/2/library/simplexmlrpcserver.html Its a pretty small number of lines to get working, and xmlrpc generally comes packaged with python. Good luck! -josh Thanks Marco ___ 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] Enhancement request - gnuradion-companion only opens one properties dialog at a time
On 12/07/2013 12:30 AM, John Blommers wrote: In gnuradio-companion, from time to time, it becomes necessary to copy and paste the parameters from one block to another block’s In case this helps: you can copy and paste blocks in the flowgraph editor, and all parameters will be duplicated into the copy. -josh properties. Today this is tedious because the properties dialogs of two or more blocks cannot be concurrently open for editing. The matter has become onerous because of the need to update so many blocks in my GRC files with the new 3.7 update. We really could use a feature added to gnuradio-companion to allow multiple block properties to be open and editable at the same time. As an enhancement to gnuradio-companion, might this feature be added to the would-be-nice list please? Best regards … - John ___ 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] Stream selector and changing variable after N samples
On 12/05/2013 12:41 PM, Aylons Hazzud wrote: I have been experimenting with the stream selector in gnuradio companion, but am stuck in situation. First, how do I change a variable after N samples? I want the signal to switch from a filter to another at a fixed rate, but blks2.selector uses a variable to do the switching. So, how could I change the value of this variable after N samples? Am I missing any documentation on using variables to dynamically change block behaviour? Looks like gr-extras is full of these situations, but I can't find documentation on how to use it. That stream selector block probably has about 4 different incarnations :-) But in any case, it switches the stream based on a property which is set asynchronously to the data flow. In your case, you probably want to create a custom block that will direct a flow of samples from the input to one of several outputs -- the key here being that the decision of how to direct the sample stream is implemented in the work function so it can be synchronous with the stream. Hope that helps, -josh ___ 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] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration
On 10/29/2013 07:22 PM, Louis Brown wrote: Any ideas as to why cmake is not finding the CL libraries on my machine; Fedora 19 x64? Could NOT find OpenCL (missing: OPENCL_LIBRARIES) CMake Error at CMakeLists.txt:104 (message): OpenCL required to compile gr-fosphor I have added the following environment variables with no luck: export OPENCL_INCLUDE_DIR=/usr/include/CL export OPEN_CPP_INCLUDE_DIR=/usr/include/CL export OPENCL_LIBRARY=/usr/lib64/nvidia Try passing in the full path to libOpenCL.so to cmake: -DOPENCL_LIBRARY=/path/to/libOpenCL.so -josh It looks like everything is there: ls /usr/include/CL/ cl_d3d10.h cl_dx9_media_sharing.h cl_gl_ext.h cl.hcl_platform.h cl_d3d11.h cl_ext.hcl_gl.h cl.hpp opencl.h ls /usr/lib64/nvidia/ libcuda.so.1 libnvidia-ifr.so.325.15 libcuda.so.325.15 libnvidia-ml.so.1 libGL.so.1libnvidia-ml.so.325.15 libGL.so.325.15 libnvidia-opencl.so.1 libnvcuvid.so.1 libnvidia-opencl.so.325.15 libnvcuvid.so.325.15 libnvidia-tls.so.1 libnvidia-cfg.so.1libnvidia-tls.so.325.15 libnvidia-cfg.so.325.15 libnvidia-vgxcfg.so libnvidia-compiler.so.1 libnvidia-vgxcfg.so.1 libnvidia-compiler.so.325.15 libnvidia-vgxcfg.so.325.15 libnvidia-encode.so.1 libOpenCL.so.1 libnvidia-encode.so.325.15libOpenCL.so.1.0.0 libnvidia-glcore.so.1 tls libnvidia-glcore.so.325.15xorg libnvidia-ifr.so.1 ___ 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] GNU Radio Logo
On 10/13/2013 09:01 AM, Marcus Müller wrote: Hello folks, I remembered there was a discussion on the IRC channel during gr-con '13 about GR needing usable logos. I happened to just had reproduced an original version of the logo for sticker printing, and promised to share those files. Well, here they are: https://github.com/marcusmueller/GrLogo.git Little problem here: I didn't design the original logo. So I can't really claim or assign copyright, define a license etc.; I'm not quite sure what to do. Does anyone know how the logo is licensed (if at all) and who was the original creator? http://comments.gmane.org/gmane.comp.gnu.radio.general/15339 -josh Anyway: Enjoy! Marcus ___ 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] Can not get rx time tags
On 09/06/2013 08:08 PM, Gong Zhang wrote: Dear Josh, Thanks for your reply. I move the code get_tags_in_range in digital_correlate_access_code, so it will be executed when digital_correlate_access_code runs. I start the sender first and then the receiver. But I still get no tag. Does the beginning of stream mean the point just the receive program runs? Well, when the USRP source block begins streaming, the very first sample should have a time tag. What blocks are in between USRP source and digital correlate access code? The reason I ask, is that some block in the middle may not be propagating tags. Which would explain the missing tags :-) -josh 2013/9/5 Josh Blum j...@ettus.com: On 09/03/2013 12:41 AM, Harry Zhang wrote: Hi, I'm trying to get rx time tags in narrowband Benchmark_tx/rx with a modified digital_correlate_access_code.cc. But the get_tags_in_range(rx_time_tags,0,this-nitems_read(0)+i,this-nitems_read(0)+i+1,pmt::pmt_string_to_symbol(rx_time)) method gets no tag in rx_time_tags while the communication between two USRP N210s running benchmark_rx/tx is OK. I'm using GNU Radio 3.6.5.1, Ubuntu12.04, boost 1.48 and UHD 3.5.3. Thanks in advance. The time tag is sent once at the beginning of streaming and after overflows. Its not necessary to send more time tags because the absolute sample count and sample rate can be used to interpolate the time to any sample. So I think are you seeing a time tag, just only once at init time. When the block sees the time, try to save the timestamp and the count it was found at. I hope that helps! -josh ___ 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] Proper block inheritance
On 09/05/2013 02:12 AM, Nemanja Savic wrote: HI all guys, I have 3 different packet deframers, and now I would like them to be able to send a message to a certain block about correct packet reception. In order to do that I want to make some phantom block that will have message out port. Are you looking to have a sort of control block that can apply configuration settings to these packet deframers? Either once at init-time or at runtime based on some conditions? If so, this also might make sense for you: In GRAS, your deframers would register calls for configuring packet reception: https://github.com/guruofquality/gras/wiki/Codeguide#method-registration In the top block, when you connect flows, you can also register the blocks into a tree. The control block could then find the deframers at runtime and apply new settings dynamically: https://github.com/guruofquality/gras/wiki/Codeguide#wiki-zero-configuration Its all GRC friendly and thread safe. You could do this with messages too, it really depends what works best or makes the most sense. Anyway, I have just been thinking about this kind of stuff and I wanted to share. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] read GPSDO data with Gnuradio-Companion
On 08/29/2013 07:27 PM, Francois Quitin wrote: Had no response to my previous email, so I try to give it another shot: Hi all, I'd like to know if it's possible to read the GPSDO data (more specifically the GPS time) with GNURadio-companion. I understand there are simple commands to read this data in C++ or python, and I'd like to know if it's possible in GRC. Think of GRC as a topology editor. So what you want is probably a block that reads USRP sensors (like GPSDO) and outputs those messages onto a message port. Then you would want a second block to consume these messages. The consumer could be anything, perhaps its just a port on a larger more complicated control-plane kind of block, or maybe its just a block that prints to stdout. I'm familiar with programming GRC blocks and working with time-tags. Does the GPSDO attach some tag on a sample when sending it's pps signal that I could retrieve in GRC? There is a block like I described above in GREX: https://github.com/guruofquality/grex/wiki/Blocks#wiki-uhd-status-block -josh Thanks, Francois ___ 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] Can not get rx time tags
On 09/03/2013 12:41 AM, Harry Zhang wrote: Hi, I'm trying to get rx time tags in narrowband Benchmark_tx/rx with a modified digital_correlate_access_code.cc. But the get_tags_in_range(rx_time_tags,0,this-nitems_read(0)+i,this-nitems_read(0)+i+1,pmt::pmt_string_to_symbol(rx_time)) method gets no tag in rx_time_tags while the communication between two USRP N210s running benchmark_rx/tx is OK. I'm using GNU Radio 3.6.5.1, Ubuntu12.04, boost 1.48 and UHD 3.5.3. Thanks in advance. The time tag is sent once at the beginning of streaming and after overflows. Its not necessary to send more time tags because the absolute sample count and sample rate can be used to interpolate the time to any sample. So I think are you seeing a time tag, just only once at init time. When the block sees the time, try to save the timestamp and the count it was found at. I hope that helps! -josh ___ 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] SWIG CVSD error
On 08/07/2013 04:32 PM, jrobison wrote: I am trying to generate java interfaces for SWIG (2.0.10) under fedora 19 , but I'm getting an error. I've been using the command swig -java -c++ -I$SWIG_INCLUDE $SWIG_INCLUDE/vocoder_cvsd_decode_bs.i This returns the error: /usr/include/gnuradio/swig/vocoder_cvsd_decode_bs.i:38: Warning 401: Nothing known about base class 'gr_sync_interpolator'. Ignored. No module name specified using %module or -module. I've on and off tried options like -includeall, -importall, and some others, no difference. I would have thought SWIG would recursively go in and generate the gnuradio specific interfaces cvsd depends on from the imports, but it didn't seem to, so I started adding them manually with -l. I'd chip away at different errors, then get to std_types, which seems wrong. How are you guys building the bindings with SWIG such that it can figure out this hierarchy? I think what you are trying to do is a way deeper hole than you realize. You probably cant just run swig with -java on the installed .i files and just have java support like that. Many of the .i files rely heavily on the build system, or have python specific stuff, or could be quite fragile. Sorry to be discouraging, its just a very deep framework-architectural thing. PS I have some swig + csharp experience (which according to swig docs are almost identical to java swig). You can basically have the same .i files as python, which is nice. You can even #ifdef SWIGPYTHON or SWIGJAVA parts of it. One of the missing features for me was that there was no equivalent of %pythoncode for the other languages... Anyway what you do with the generated source from swig is pretty different (compile, link, installation, organization). So it would have to be all generalized out in the build system. I think it would be really cool one day to have all the blocks in the block factory. Then you just add support for languageX to the framework/factory; which isnt trivial, but you do it just once. But because all of the blocks are registered in the factory, you just get the new language support automatically. Maybe some rainy day or two... Just my 2cents -josh -- View this message in context: http://gnuradio.4.n7.nabble.com/SWIG-CVSD-error-tp43026.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ 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] Cannot import gnuradio.extras after reinstall the latest gnuradio
On 08/07/2013 06:59 AM, Ralph A. Schmid, dk5ras wrote: Aah, gras still is 3.6, no 3.7 support? Or does 3.7 need an additional option? The gnuradio submodule that the GRAS repo points to is gr3.6. I do have a 3.7 support branch but the submodule is not pointing to it (yet). https://github.com/guruofquality/gnuradio/tree/gnuradio_gras_37_support The nice thing about this branch is that GRAS support code is nicely separated so the scheduler can be selected at compile time. Also, you should be able to build it normally (no submodule stuff). I will get around to updating the submodule to do a 3.7 version, but I need to update my benchmarks for the 3.7 reorganization, and probably a little more testing. I keep putting it off because making the new features is way more fun. -josh Ralph. -Original Message- From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ralph A. Schmid, dk5ras Sent: Wednesday, August 07, 2013 11:23 AM To: j...@joshknows.com; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio Hi, Will it be possible to install gras into a system that already has an installed gnuradio version, latest 3.7 build, or is it recommended to remove the single gr 3.7 installation before building gras? If the latter is recommended, will I run into trouble with other tools that depend on gnuradio, or is this not an issue? gr-osmosdr, gqrx and similar stuff comes in my mind... Ralph. -Original Message- From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Josh Blum Sent: Wednesday, August 07, 2013 2:55 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio ImportError: libgnuradio-extras.so: cannot open shared object file: No such file or directory I run the sudo ldconfig after the whole installation, but the error still exists. Btw, do I need to install the GRAS manually? If you want grextras installed to support precog or perhaps an older existing design. You need to first install gnuradio 3.6, then install grextras from the grextras_v3.6 branch. Due to the reorg in gr 3.7, this grextras is no longer build-able with recent gnuradio: https://github.com/guruofquality/grextras/wiki/Old If you are looking to install the recent GrExtras for the cool blocks, its automatically built and installed with GRAS, so just follow: https://github.com/guruofquality/gras/wiki/Build -josh ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio
On 08/07/2013 05:23 AM, Ralph A. Schmid, dk5ras wrote:
Hi,
Will it be possible to install gras into a system that already has an
installed gnuradio version, latest 3.7 build, or is it recommended to remove
the single gr 3.7 installation before building gras? If the latter is
recommended, will I run into trouble with other tools that depend on
gnuradio, or is this not an issue? gr-osmosdr, gqrx and similar stuff comes
in my mind...
Its basically the same as having multiple versions of gnuradio
installed, especially considering that between major versions theres API
and ABI issues. So I would just recommend putting the installs in
different prefixes. I do this all the time for my benchmarking.
Here is one of the path scripts, I just run: source foo.sh
derp_prefix=/opt/usr/gr
export PKG_CONFIG_PATH=${derp_prefix}/lib/pkgconfig:${PKG_CONFIG_PATH}
export PATH=${derp_prefix}/bin:$PATH
export PYTHONPATH=${derp_prefix}/lib/python2.7/dist-packages:$PYTHONPATH
export GRC_BLOCKS_PATH=${derp_prefix}/share/gnuradio/grc/blocks
export LD_LIBRARY_PATH=${derp_prefix}/lib
-josh
Ralph.
-Original Message-
From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Josh Blum
Sent: Wednesday, August 07, 2013 2:55 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Cannot import gnuradio.extras after
reinstall
the latest gnuradio
ImportError: libgnuradio-extras.so: cannot open shared object file: No
such
file or directory
I run the sudo ldconfig after the whole installation, but the error
still
exists.
Btw, do I need to install the GRAS manually?
If you want grextras installed to support precog or perhaps an older
existing design. You need to first install gnuradio 3.6, then install
grextras from the grextras_v3.6 branch. Due to the reorg in gr 3.7, this
grextras is no longer build-able with recent gnuradio:
https://github.com/guruofquality/grextras/wiki/Old
If you are looking to install the recent GrExtras for the cool blocks,
its automatically built and installed with GRAS, so just follow:
https://github.com/guruofquality/gras/wiki/Build
-josh
___
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] Error in building GRAS
On 08/06/2013 11:59 AM, Alex Zhang wrote: Hello, When run the make, i got error today: /home/alexzh/gras/lib/jit_factory.cpp:88:8: error: ‘llvm’ does not name a type /home/alexzh/gras/lib/jit_factory.cpp:238:6: error: ‘Factory’ has not been declared make[2]: *** [lib/CMakeFiles/gras.dir/jit_factory.cpp.o] Error 1 make[1]: *** [lib/CMakeFiles/gras.dir/all] Error 2 make: *** [all] Error 2 Sorry, it was missing an ifdef for when llvm is not detected. Should be fixed now. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot import gnuradio.extras after reinstall the latest gnuradio
ImportError: libgnuradio-extras.so: cannot open shared object file: No such file or directory I run the sudo ldconfig after the whole installation, but the error still exists. Btw, do I need to install the GRAS manually? If you want grextras installed to support precog or perhaps an older existing design. You need to first install gnuradio 3.6, then install grextras from the grextras_v3.6 branch. Due to the reorg in gr 3.7, this grextras is no longer build-able with recent gnuradio: https://github.com/guruofquality/grextras/wiki/Old If you are looking to install the recent GrExtras for the cool blocks, its automatically built and installed with GRAS, so just follow: https://github.com/guruofquality/gras/wiki/Build -josh ___ 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] PMT blobs in Python
On 08/04/2013 06:08 AM, Marcus Müller wrote: I can't really test this right now, but you could insert %include cdata.i into your project's swig file[1]; this should generate a python method cdata(ptr, length) that you can feed your blob_data() to. I'm not quite sure that WILL work as is, maybe you will need a C(++) wrapper that simply returns an array of known type (that is, int* instead of void*) that you can yourself wrap into a SWIG array_class (like in the linked document). I dont know if this made it into PMT, buts its definitely in gr core for the block gateway. Basically the snippet gives you a numpy array given a ptr and length. Once its in numpy, you can shape it however, no copies involved, do math on it, etc... Here it is for the blob extensions in the old grextras: https://github.com/guruofquality/grextras/blob/grextras_v3.6/python/extras_pmt.py#L32 Using a similar one in PMC to handle various numeric arrays: https://github.com/guruofquality/PMC/blob/master/python/PMC/PMCNumericArray.i#L87 And again for the smart buffer type: https://github.com/guruofquality/gras/blob/master/include/gras/sbuffer.i#L26 go numpy! -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dynamic number of message ports using nports
On 07/29/2013 08:37 AM, macbany wrote: I'm using GnuRadio 3.6.5.1 and I wanted to create a block similar to stream-to-streams for messages. In the XML I used a variable and nports so I could specify the number of ports in the flowgraph. However, I've found that this does not work. Whenever I change the variable value to something greater than 1, the variable ID turns red and the number of ports displayed does not change. Simply changing the port type to something other than message works correctly. Does anyone have an idea how to fix this? So I think its sort of fundamental the the message ports cant be scaled like that because they are named and not linearly indexed. You could find a way do to it, but its a more invasive GRC change I guess. Perhaps Martin's GSoC student might consider doing this for the GRC improvements, if not already? -josh -- View this message in context: http://gnuradio.4.n7.nabble.com/Dynamic-number-of-message-ports-using-nports-tp42766.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ 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] Announcing new GRAS Feature - Block Factory
Hello list, As a follow-up to my last announcement Advanced scheduler pw0ns SWIG for you (which I was quite excited about), I have since tried to formalize the feature-set and document it: What I am collectively calling the block factory is really: * A CMake utility to build and install runtime loadable modules * A system to load runtime modules from the specified paths * An API to register block constructors into the factory * An API to create blocks from the factory * An API to register block methods into the framework * An API to call into registered methods That may sound complicated, but actually, all of the complexity is handled in the guts of the framework. So in contrast, this is probably the simplest it has even been for a user to create custom blocks. The CMake projects that build and install a user's blocks are brief and to the point -- no swig, a minimal number of files. Builds are quick and snappy and its easy to debug build errors. The registration APIs are very clean and non-invasive -- as are calling into the registered factories and class methods. Here is the run-down: The code guide has example snippets on how to painlessly register block constructors and methods, and how to call into them at runtime: https://github.com/guruofquality/gras/wiki/Codeguide#wiki-block-factory This wiki page lists the pros and the cons of using this feature: https://github.com/guruofquality/gras/wiki/Blockfactory The module guide hosts a usable example CMake build project, and explains in more detail how GRAS finds modules at runtime: https://github.com/guruofquality/gras/wiki/Moduleguide I switched every block in GrExtras over to this new system without exception. Every C++ and CMake file stands as a useful example: https://github.com/guruofquality/grextras/ Something neat you can do; Here is an example of a block where the same code takes on a different API depending upon which factory path is used: https://github.com/guruofquality/grextras/blob/master/math/add_const.cpp#L22 I moved the Clang part of the GrExtras Clang Block into GRAS. The new jit_factory() call provides the backend for the Clang Block. You can literally just dump C++ source into this call, from Python, at runtime, and find your blocks in the factory. https://github.com/guruofquality/gras/blob/master/include/gras/factory.hpp#L15 Using this set of features doesn't preclude the normal way of making libraries or python modules. Blocks from a SWIG'd library work just fine with blocks from a factory. And for that matter, block factories don't do everything. If a user needs to have a set of utilities to go along with the blocks, nothing is wrong with building your typical dlls along with the modules for the block factory. Etc, etc... I'm very proud of this work. And I think that this feature-set has the potential to improve a lot of user's experiences. I hope y'all like it too! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using UHD control block
On 08/02/2013 06:32 AM, Marcus Müller wrote: Hi Harry Zhang, UHD in general not related to GRAS. I don't know either a UHD control nor a status block. Are you referring to the UHD USRP source/sink blocks? However, if you're trying to use any UHD related functionality, you will need to compile GNURadio with UHD support, therefore have the UHD headers somewhere Cmake will find them (thus enabling gr-uhd). There is a control and status block in grextras. They should show up in the UHD category tree when installed. https://github.com/guruofquality/grextras/wiki/Blocks#wiki-misc-uhd-blocks So I guess you need to check if the the cmake configuration for GRAS found uhd support. The configuration verbose should tell us this. Just post the verbose if you have any questions. THanks! -josh -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio3.7 make error
I havent seen this before, but you might try explicitly linking the tags
demo against boost libraries, like so:
diff --git a/gr-uhd/examples/c++/CMakeLists.txt
b/gr-uhd/examples/c++/CMakeLists.txt
index 655ef0c..18f6839 100644
--- a/gr-uhd/examples/c++/CMakeLists.txt
+++ b/gr-uhd/examples/c++/CMakeLists.txt
@@ -35,7 +35,7 @@ link_directories(${Boost_LIBRARY_DIRS})
# Build executable
add_executable(tags_demo tags_demo.cc)
-target_link_libraries(tags_demo gnuradio-uhd)
+target_link_libraries(tags_demo gnuradio-uhd ${Boost_LIBRARIES})
INSTALL(TARGETS
tags_demo
Let us know if that helps. thanks
-josh
On 07/29/2013 10:44 PM, Harry Zhang wrote:
Hi,
I'm using Ubuntu 12.04 and libboost1.46. I got the following errors
when I make the project.
[ 85%] Building CXX object
gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/tags_demo.cc.o
Linking CXX executable tags_demo
/usr/bin/ld: warning: libboost_date_time.so.1.40.0, needed by
/usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libboost_filesystem.so.1.40.0, needed by
/usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libboost_program_options.so.1.40.0, needed by
/usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libboost_regex.so.1.40.0, needed by
/usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libboost_system.so.1.40.0, needed by
/usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libboost_thread.so.1.40.0, needed by
/usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libboost_unit_test_framework.so.1.40.0, needed by
/usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/local/lib/libuhd.so: undefined reference to
`boost::filesystem::detail::dir_itr_increment(void*, void*,
std::basic_stringchar, std::char_traitschar, std::allocatorchar ,
boost::filesystem::file_status, boost::filesystem::file_status)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::thread_resource_error::thread_resource_error()'
/usr/local/lib/libuhd.so: undefined reference to
`boost::filesystem::detail::dir_itr_close(void*, void*)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::lock_error::lock_error()'
/usr/local/lib/libuhd.so: undefined reference to
`boost::filesystem::detail::dir_itr_first(void*, void*,
std::basic_stringchar, std::char_traitschar, std::allocatorchar
const, std::basic_stringchar, std::char_traitschar,
std::allocatorchar , boost::filesystem::file_status,
boost::filesystem::file_status)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::filesystem::detail::get_current_path_api(std::basic_stringchar,
std::char_traitschar, std::allocatorchar )'
/usr/local/lib/libuhd.so: undefined reference to
`boost::re_detail::get_mem_block()'
/usr/local/lib/libuhd.so: undefined reference to
`boost::filesystem::detail::not_found_error()'
/usr/local/lib/libuhd.so: undefined reference to
`boost::re_detail::get_default_error_string(boost::regex_constants::error_type)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::system::get_generic_category()'
/usr/local/lib/libuhd.so: undefined reference to
`boost::system::get_system_category()'
/usr/local/lib/libuhd.so: undefined reference to
`boost::re_detail::put_mem_block(void*)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::re_detail::raise_runtime_error(std::runtime_error const)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::re_detail::cpp_regex_traits_implementationchar::transform_primary(char
const*, char const*) const'
/usr/local/lib/libuhd.so: undefined reference to
`boost::re_detail::perl_matcherchar const*,
std::allocatorboost::sub_matchchar const* ,
boost::regex_traitschar, boost::cpp_regex_traitschar
::construct_init(boost::basic_regexchar, boost::regex_traitschar,
boost::cpp_regex_traitschar const,
boost::regex_constants::_match_flags)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::filesystem::detail::status_api(std::basic_stringchar,
std::char_traitschar, std::allocatorchar const,
boost::system::error_code)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::re_detail::cpp_regex_traits_implementationchar::transform(char
const*, char const*) const'
/usr/local/lib/libuhd.so: undefined reference to
`boost::match_resultschar const*, std::allocatorboost::sub_matchchar
const* ::maybe_assign(boost::match_resultschar const*,
std::allocatorboost::sub_matchchar const* const)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::re_detail::verify_options(unsigned int,
boost::regex_constants::_match_flags)'
/usr/local/lib/libuhd.so: undefined reference to
`boost::basic_regexchar, boost::regex_traitschar,
boost::cpp_regex_traitschar
Re: [Discuss-gnuradio] GRAS build error on armv7
On 07/29/2013 07:31 AM, Manoj Gudi wrote: That sounds good. I second that. Just ifdef the pause for the fix. For a little extra information here. The thread pools in Theron can have different yield strategies. GRAS happens to use by default the condition variable strategy. So the code in question actually has zero impact at runtime unless a spin lock yield is requested. Beyond just compiling, in the near future, we will get to test questions like. Which strategy works better on arm? And that yield code in particular, what in particular would be most optimal for arm. Some relevant links. http://docs.theron-library.com/5.01/structTheron_1_1Framework_1_1Parameters.html https://github.com/guruofquality/gras/wiki/Threading -josh From: manojgudi manoj.p.g...@gmail.com Date: Mon, 29 Jul 2013 17:00:35 +0530 Subject: [PATCH] fixed ASM --- Include/Theron/Detail/Threading/Utils.h |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Include/Theron/Detail/Threading/Utils.h b/Include/Theron/Detail/Threading/Utils.h index 8c6baf2..e2811f1 100644 --- a/Include/Theron/Detail/Threading/Utils.h +++ b/Include/Theron/Detail/Threading/Utils.h @@ -168,8 +168,11 @@ THERON_FORCEINLINE void Utils::YieldToHyperthread() YieldProcessor(); #elif THERON_GCC - -__asm__ __volatile__ (pause); +#ifdef __arm__ +__asm__ __volatile__ (NOP); +#elif __X86_64__ + __asm__ __volatile__(pause); +#endif #endif ___ 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] GRAS build error on armv7
On 07/26/2013 07:57 AM, Manoj Gudi wrote: We've been successful in building dependencies for gnuradio on armv7 platform, however while building GRAS, we got this error: This line is probably the culprit. https://github.com/captaintrash/theron/blob/master/Include/Theron/Detail/Threading/Utils.h#L163 The thread pools can operate on condition variables or spin locks. For the spin lock implementation, there is a pause instruction -- obviously not applicable on arm. I think you can simply comment this out to get things rolling. Supposing this is the issue. What is the recommended fix... just a simple #ifdef __X86_64__ around this line? -josh *Scanning dependencies of target gras [ 13%] Building CXX object lib/CMakeFiles/gras.dir/__/Theron/Theron/Receiver.cpp.o [ 13%] Generating GrExtras_Ops.pyc [ 13%] Generating GrExtras_Ops.pyo make[2]: warning: Clock skew detected. Your build may be incomplete. [ 13%] Built target pygen_python_grextras_da046 [ 13%] Swig source /tmp/ccONtg2w.s: Assembler messages: /tmp/ccONtg2w.s:3234: Error: bad instruction `pause' /tmp/ccONtg2w.s:3243: Error: bad instruction `pause' /tmp/ccONtg2w.s:3266: Error: bad instruction `pause' /tmp/ccONtg2w.s:3275: Error: bad instruction `pause' /tmp/ccONtg2w.s:3406: Error: bad instruction `pause' /tmp/ccONtg2w.s:3415: Error: bad instruction `pause' /tmp/ccONtg2w.s:4479: Error: bad instruction `pause' /tmp/ccONtg2w.s:4488: Error: bad instruction `pause' /tmp/ccONtg2w.s:4511: Error: bad instruction `pause' /tmp/ccONtg2w.s:4520: Error: bad instruction `pause' /tmp/ccONtg2w.s:4540: Error: bad instruction `pause' /tmp/ccONtg2w.s:4549: Error: bad instruction `pause' /tmp/ccONtg2w.s:4677: Error: bad instruction `pause' /tmp/ccONtg2w.s:4686: Error: bad instruction `pause' /tmp/ccONtg2w.s:4735: Error: bad instruction `pause' /tmp/ccONtg2w.s:4744: Error: bad instruction `pause' /tmp/ccONtg2w.s:4816: Error: bad instruction `pause' /tmp/ccONtg2w.s:4825: Error: bad instruction `pause' make[2]: Warning: File `/usr/include/python2.7/Python.h' has modification time 4.1e+08 s in the future [ 13%] Building CXX object PMC/python/PMC/CMakeFiles/_PMCBool.dir/PMCBoolPYTHON_wrap.cxx.o /home/aakash/gras/build/PMC/python/PMC/PMCBoolPYTHON_wrap.cxx: In function 'void SWIG_InitializeModule(void*)': /home/aakash/gras/build/PMC/python/PMC/PMCBoolPYTHON_wrap.cxx:3433:21: warning: statement has no effect [-Wunused-value] * In my opinion this is an assembler issue for armV7, but I've got no leads on how to solve this. Will mapping this instruction with an equivalent assembly instruction for armV7 work? Here's /proc/cpuinfo *$ cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS: 1001.88 Features: swp half thumb fastmult vfp edsp neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part: 0xc08 CPU revision: 2 Hardware: sun5i Revision: Serial : * OS version: Linaro image 13.06 Kernel: linux-sunxi 3.0.62+ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] toggling LFRX gpio pins
On 07/24/2013 12:46 PM, Nemanja Savic wrote: After some time I maybe realized how this thing works, but I don't know jow to call correctly methods from dboard_iface: def get_pin_ctrl(self, *args, **kwargs): get_pin_ctrl(self, unit_t unit) - boost::uint16_t return _uhd_swig.dboard_iface_get_pin_ctrl(self, *args, **kwargs) ef get_gpio_ddr(self, *args, **kwargs): get_gpio_ddr(self, unit_t unit) - boost::uint16_t return _uhd_swig.dboard_iface_get_gpio_ddr(self, *args, **kwargs) or any of these methods that have *arg and **kwargs. When I call like this: iface = usrp1_src.get_dboard_iface() print iface.get_pin_ctrl(uhd.dboard_iface.UNIT_RX, 0) I get following error: Traceback (most recent call last): File lftx_io.py, line 31, in module print iface.get_pin_ctrl(uhd.dboard_iface.UNIT_RX, 0) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 1691, in get_pin_ctrl return _uhd_swig.dboard_iface_sptr_get_pin_ctrl(self, *args, **kwargs) TypeError: dboard_iface_sptr_get_pin_ctrl() takes at most 2 arguments (3 given) You have the right idea, but that particular function only takes one argument. So thats the error. Take a look at include/uhd/usrp/dboard_iface.hpp for documentation. The python interface may be a little different syntax wise, but the function names are all the same. -josh On Wed, Jul 24, 2013 at 4:58 PM, Nemanja Savic vlasi...@gmail.com wrote: Hi guys again, I have designed small RF frontend using TI's cc1000 transciever. Since the transciever need to be configured using external pins, I need to be able to toggle gpio pins on my LFRX. I have found that I should use dboard_iface which is available in python via swig. However I have several questions: How should I address my board, since there are 4 possible slots, and onlt 2 values of type unit, UNIT_RX and UNIT_TX. As far as i can see, every uhd source has method get_iface, does this anyhow concerns me? Thanks again, Nemanja -- Nemanja Savić ___ 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] Questions about synchronize usrp2 via mimo cable
On 07/24/2013 08:25 PM, yeran wrote: Hi all, I am trying to study STBC using USRP2 and have some questions about how to use mimo cable. I followed the instruction on ettus but i dont understand 'Configuring the slave' part http://files.ettus.com/uhd_docs/manual/html/usrp2.html#using-the-mimo-cable Configuring the slave In order for the slave to synchronize to the master over MIMO cable, the following clock configuration must be set on the slave device: uhd::clock_config_t clock_config; clock_config.ref_source = uhd::clock_config_t::REF_MIMO; clock_config.pps_source = uhd::clock_config_t::PPS_MIMO; usrp-set_clock_config(clock_config, slave_index); === I wonder where should I add these lines? The code you have below is correct. The code snippet in the docs using clock_config reflects an older API. I will correct this. Thanks -josh What I am trying is: self.usrp_sink = uhd.usrp_sink(device_addr=self.addr, stream_args = uhd.stream_args(cpu_format=32fc,channels=range(2),),) self.usrp_sink.set_clock_source(internal, 0) self.usrp_sink.set_time_source(mimo, 0) self.usrp_sink.set_clock_source(mimo, 1) self.usrp_sink.set_time_source(mimo, 1) Am I right about that? Thanks for any help~ Robee ___ 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] gras make error
On 07/25/2013 04:51 AM, Gong Zhang wrote: Hi, I got the source code of gras using git,and I followed the instruction to install gras.But I got errors while making. /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp: In function ‘void boost::atomic_thread_fence(boost::memory_order)’: /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp:51: warning: case label value exceeds maximum value for type /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp: In function ‘void boost::detail::atomic::platform_fence_before(boost::memory_order)’: /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp:76: warning: case label value exceeds maximum value for type /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp: In function ‘void boost::detail::atomic::platform_fence_after(boost::memory_order)’: /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp:102: warning: case label value exceeds maximum value for type /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp: In function ‘void boost::detail::atomic::platform_fence_after_load(boost::memory_order)’: /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp:124: warning: case label value exceeds maximum value for type The warning tells me that you have a pretty old version of boost, but this should be ok. The error below is telling me that the ptree is not being included properly (at least on this system). Can you tell me the following: Version of boost? OS name and version? -josh In file included from /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:4: /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp: At global scope: /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:14: error: expected unqualified-id before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:14: error: expected ‘)’ before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:14: error: expected initializer before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:15: error: ‘boost::property_tree’ has not been declared /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:15: error: expected constructor, destructor, or type conversion before ‘pmc_to_ptree’ /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:17: error: ‘boost::property_tree’ has not been declared /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:17: error: expected constructor, destructor, or type conversion before ‘json_to_ptree’ /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:18: error: expected unqualified-id before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:18: error: expected ‘)’ before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:18: error: expected initializer before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:14: error: ‘property_tree’ is not a namespace-name /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:14: error: expected namespace-name before ‘;’ token /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:31: error: ‘ptree’ does not name a type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:50: error: ‘ptree’ does not name a type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:160: error: ‘ptree’ does not name a type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:186: error: ISO C++ forbids declaration of ‘ptree’ with no type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:186: error: expected ‘,’ or ‘...’ before ‘’ token /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp: In member function ‘virtual std::string gras::TopBlock::query(const std::string)’: /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:243: error: ‘ptree’ does not name a type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:246: error: ‘((gras::TopBlock*)this)-gras::TopBlock::query’ does not have class type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:246: error: expected primary-expression before ‘’ token /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:247: error: ‘ptree’ was not declared in this scope /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:247: error: expected ‘;’ before ‘result’ /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:248: error: argument of type ‘std::string (gras::TopBlock::)(const std::string)’ does not match ‘int’ /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:249: error: ‘result’ was not declared in this scope /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:249: error: ‘query_blocks’ was not declared
Re: [Discuss-gnuradio] gras make error
On 07/25/2013 10:03 PM, Gong Zhang wrote: Sorry for the incomplete information. I'm using Ubuntu 10.04 and the boost version is 1.40 So heres the deal. Boost 1.40 does not support the property tree. Property tree was introduced in 1.41: http://www.boost.org/doc/libs/1_41_0/ Anyway, what I have done is make the property tree stuff optional. If old boost is detected, its compiled out. Try to update your repository and see if it compiles now: https://github.com/guruofquality/gras/commit/b877d078b11cb848b344f4f7534398f70157aa15 The property tree is used for the query interface. This drives the web-based status monitor. So that wont work w/ with boost 1.40, but everything else should be OK. Honestly, I only test build on ubuntus as old as 11.04. I have not tested on 10.04 in a while. But if you find more bugs, I will try to fix them. And I also recommend to upgrade to a newer ubuntu like 12.04 -- which is the most recent long term support version. -josh 2013/7/25 Josh Blum j...@joshknows.com: On 07/25/2013 04:51 AM, Gong Zhang wrote: Hi, I got the source code of gras using git,and I followed the instruction to install gras.But I got errors while making. /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp: In function ‘void boost::atomic_thread_fence(boost::memory_order)’: /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp:51: warning: case label value exceeds maximum value for type /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp: In function ‘void boost::detail::atomic::platform_fence_before(boost::memory_order)’: /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp:76: warning: case label value exceeds maximum value for type /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp: In function ‘void boost::detail::atomic::platform_fence_after(boost::memory_order)’: /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp:102: warning: case label value exceeds maximum value for type /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp: In function ‘void boost::detail::atomic::platform_fence_after_load(boost::memory_order)’: /home/zg/Desktop/Codes/gras/gras/Theron/Include/External/boost/atomic/detail/gcc-x86.hpp:124: warning: case label value exceeds maximum value for type The warning tells me that you have a pretty old version of boost, but this should be ok. The error below is telling me that the ptree is not being included properly (at least on this system). Can you tell me the following: Version of boost? OS name and version? -josh In file included from /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:4: /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp: At global scope: /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:14: error: expected unqualified-id before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:14: error: expected ‘)’ before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:14: error: expected initializer before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:15: error: ‘boost::property_tree’ has not been declared /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:15: error: expected constructor, destructor, or type conversion before ‘pmc_to_ptree’ /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:17: error: ‘boost::property_tree’ has not been declared /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:17: error: expected constructor, destructor, or type conversion before ‘json_to_ptree’ /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:18: error: expected unqualified-id before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:18: error: expected ‘)’ before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/gras_impl/query_common.hpp:18: error: expected initializer before ‘::’ token /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:14: error: ‘property_tree’ is not a namespace-name /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:14: error: expected namespace-name before ‘;’ token /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:31: error: ‘ptree’ does not name a type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:50: error: ‘ptree’ does not name a type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:160: error: ‘ptree’ does not name a type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:186: error: ISO C++ forbids declaration of ‘ptree’ with no type /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp:186: error: expected ‘,’ or ‘...’ before ‘’ token /home/zg/Desktop/Codes/gras/gras/lib/top_block_query.cpp
Re: [Discuss-gnuradio] GRAS flow control from work function
On 07/15/2013 05:43 PM, devin.butterfi...@gmail.com wrote: Hi, I'm using gras for my application and my custom block needs to be able to do a blocking read to get data from an external source. With the standard scheduler I used a non blocking read in a polling loop with an interruptable sleep and this worked Ok. Do I need to do it this way with gras or can I get away with with blocking? Basically, you want to avoid stealing away the work() thread for too long. So I recommend polling with a small timeout and return if there is nothing. Work will get called again. Relevant discussion: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-05/msg00124.html Another thing my block must do is stop the flow graph if its external source has signaled that it is done. I did this with the standard scheduler by returning WORK_DONE. How should this be done with gras? Use this-mark_done() https://github.com/guruofquality/gras/blob/master/include/gras/block.hpp#L213 -josh Thanks. -- Regards, Devin ___ 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] Does GRAS support setting max noutput_items?
On 07/14/2013 02:43 PM, Devin Butterfield wrote: Hi folks, I just started experimenting with GRAS and ran into this: GRAS: The debug asserts are enabled. Created default thread pool with 4 threads. Traceback (most recent call last): File top_block.py, line 80, in module tb.Run(True, 10) File /opt/gnuradio/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py, line 76, in Run self.start(max_nouts) TypeError: start() takes exactly 1 argument (2 given) Is this feature broken? Yea, Its in the block config that can be set at the global config level or the block level, or the port level. https://github.com/guruofquality/gras/blob/master/include/gras/block_config.hpp https://github.com/guruofquality/gras/blob/master/include/gras/top_block.hpp#L24 https://github.com/guruofquality/gras/blob/master/include/gras/block.hpp#L42 Its also available in the wrapper set set_max_noutput_items on the blocks, it just didnt get into the second parameter for the run/start API calls. I can add it... Just curious... What are you trying to do at a high level? Constrain the available buffer that a block can produce (without upstream consuming)? Constrain the maximum number of items in a single call to work? etc.. -josh Thanks. -- Regards, Devin ___ 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] help QAM
On 07/11/2013 02:10 PM, tom sutherland wrote: I have a simple 16QAM project. I want to do audio but for right now I have a signal source constant input to the QAM module. I am trying to display the constellation diagram but it's not displaying what I think it should. I have a few questions 1) I would think that inputing a constant value into the QAM module would produce a single point, it doesn't, it puts up a grouping of 8 points of the 16 possible locations. I am trying to verify the input verses output. 2) The QAM module expects a char type which I assume is 4 bits. If I have 8-bit (byte) data from a audio source, how do I feed the QAM module? I think this will help. Many of the modulators in gnuradio take byte inputs where each byte is fully packed with data. In other words, each byte != one symbol. The modulator chain actually unpacks the byte into symbols. Perhaps this explains 1 and 2. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Linker error
On 07/10/2013 11:30 AM, Weigel, Sebastian wrote: Hi GNURadio-Community, I tried to install GNU-Radio 3.7 on Ubuntu 13.04. After getting all the dependencies with the instructions from http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall cmake worked, but when I tried make I got an error message: You cant be the only one who has compiled 3.7 w/ 13.04. Anyone else have success w/ 13.04. Unfortunately I have not upgraded my system yet :-) If 13.04 gcc is really going to complain like this: recompile with -fPIC , then FWIW, the CMakeLists.txt could look like this to fix the issue: https://github.com/guruofquality/Theron/blob/master/TheronSetup.cmake#L40 -josh Scanning dependencies of target _pmt_swig [ 12%] Building CXX object gnuradio-runtime/swig/CMakeFiles/_pmt_swig.dir/pmt_swigPYTHON_wrap.cxx.o /home/gs/code/gnuradio-3.7.0/gnuradio-runtime/swig/pmt_swigPYTHON_wrap.cxx: In function 'void SWIG_InitializeModule(void*)': /home/gs/code/gnuradio-3.7.0/gnuradio-runtime/swig/pmt_swigPYTHON_wrap.cxx:41174:21: warning: statement has no effect [-Wunused-value] Linking CXX shared module _pmt_swig.so /usr/bin/ld: /usr/local/lib/libpython2.7.a(abstract.o): relocation R_X86_64_32S against `_Py_NotImplementedStruct' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libpython2.7.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status make[2]: *** [gnuradio-runtime/swig/_pmt_swig.so] Error 1 make[1]: *** [gnuradio-runtime/swig/CMakeFiles/_pmt_swig.dir/all] Error 2 make: *** [all] Error 2 I attached the cmake-messages as a .txt-file. Do you know what is the reason for the error and how it can be solved? Thank you very much for your help! Cheers, Sebastian ___ 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] Question about Cycle Detection in GNU Radio
The thing is, you don't want your streaming ports to have cycles. It's not a fundamental limitation of GNU Radio; it's just not the right thing to do. The streaming ports are for streams of data, which tend to have strong temporal relationships with each other. I think Tommy needs to figure out what interface is more applicable for his purposes: streaming or messaging. Since TCP is involved, its sounds like blocks will be passing around chunks of memory with length boundaries. Something message based would be preferable here. But if the TCP packets are just transporting boundless samples, then a streaming interface is more applicable. Whatever makes the processing logic most natural to code in is probably the right answer. But suppose that a streaming interface is most applicable. Then I believe that this new router block will cause the stock scheduler to detect a cycle or loop and *fail*, even though there technically is not a cycle, since the inputs are unrelated to the outputs. Right? One way to fix this might be to separate the input ports and the output ports into two different blocks. This is the trick to keep the stock scheduler from discovering a loop. However, now with two blocks, you might face some thread synchronization issues between the two workers, this can probably be addressed with simple mutexes. Anywhoo point being, if the framework is flexible to all these options, the user can choose what is best to implement their design. Cycles in data streams are (generally; I'm sure there are a few exceptions) usually very time-specific. Think of a PLL: if you have more than 1 sample delay in your loop, it falls apart as an algorithm (I have a paper on this somewhere that shows the math behind how delay effects the locking performance). We don't do cycles because we transfer large (ideally) chunks of data between blocks. If you're processing 8191 items in one work function and try to feed that back, you're now that many samples delayed in time. Then next call could be a different number. So not only do you have this delay, you have a varying time delay. Doesn't make sense for these kinds of streams. And if we set N=1 for all calls to work, you're going to maximize the scheduler overhead, which is also bad. Yea, when most people are talking about cycles, they want to implement something from a DSP text book with feedback to an adder or multiplier. This is a totally inefficient way to implement the design. The ratio of scheduler overhead to work overhead is too-damn-high! But feedback loops are nice to have for academic satisfaction and simulation purposes. Its really awesome to be able to bring concepts from basic communications courses to life in GNURadio Companion, with test signals, sliders, and live FFTs. It was for me anyway :-) This morning, a few people trying out the advanced scheduler asked me about using feedback in GRC. You see, getting a feedback loop working is a matter of preloading the loop with something to set the initial delay, but there isnt a GRC-friendly way to set the preload on arbitrary blocks. To keep it simple, I just added an option to the math blocks in GrExtras, which I think covers most cases: https://github.com/guruofquality/grextras/issues/36 Cheers, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio
On 07/09/2013 09:20 PM, Tommy Tracy II wrote: Another alternative would be to pass around shared pointers to a queue. Does that seem like a reasonable, albeit hack-ee, approach? Of course that could work, but then you arent really letting the framework work for you. The scheduler handles all the thread spawning, thread safety, delivery of information through the topology... At its core, the scheduler is just a collection of threads and shared queues. So you dont have to re-implement that :-) -josh Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Jul 9, 2013, at 5:46 PM, Josh Blum j...@joshknows.com wrote: On 07/09/2013 08:25 PM, Johnathan Corgan wrote: On 07/09/2013 05:06 PM, Tommy Tracy II wrote: I am working on a GNU Radio Router block that will serve as a communication block between multiple flow graphs. My router will receive information via TCP, and then send it to several other blocks to be processed. After those blocks have completed their processing, my original idea was to take that data and return it to the router to be sent back to a different node. This would introduce a cycle in the flow graph. Is there any way to disable cycle prevention? There is no way to disable cycle prevention; the GNU Radio scheduler algorithm requires streaming ports to be a directed acyclic graph. However, this applies to streaming ports only. It's possible (though probably lower in performance) for you to encapsulate data into async messages and use message ports connected in an arbitrary topology. Checkout the advanced scheduler. There is no problem with feedback loops, and there is no penalty for passing buffers as messages instead of streams: https://github.com/guruofquality/gras/wiki -josh ___ 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] Question about Cycle Detection in GNU Radio
On 07/09/2013 08:25 PM, Johnathan Corgan wrote: On 07/09/2013 05:06 PM, Tommy Tracy II wrote: I am working on a GNU Radio Router block that will serve as a communication block between multiple flow graphs. My router will receive information via TCP, and then send it to several other blocks to be processed. After those blocks have completed their processing, my original idea was to take that data and return it to the router to be sent back to a different node. This would introduce a cycle in the flow graph. Is there any way to disable cycle prevention? There is no way to disable cycle prevention; the GNU Radio scheduler algorithm requires streaming ports to be a directed acyclic graph. However, this applies to streaming ports only. It's possible (though probably lower in performance) for you to encapsulate data into async messages and use message ports connected in an arbitrary topology. Checkout the advanced scheduler. There is no problem with feedback loops, and there is no penalty for passing buffers as messages instead of streams: https://github.com/guruofquality/gras/wiki -josh ___ 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] Advanced scheduler pw0ns SWIG for you
Well, I was attempting to rewrite the property interface to make it a little more generic... and I accidentally obviated the need for SWIG. -- Interesting... go on... OK, say you are a user, you are making a nice fast c++ block, and you intend to use it in python. This is like the most common GR use case. Scratch the following things off your TODO list, because you no longer need to do them: public headers, symbol exports, SWIG wrappers, Python files, install rules for all these files... -- How simple can it be? Write your cpp source, compile it to a loadable module. Install module to prefix/lib/gras/modules, install grc xml wrapper to prefix/share/gnuradio/grc. Boom your done, your block is now usable in C++, python, and GRC frameworks. -- Give me an example! This example c++ source file registers the block and its methods, and it can be created and accessed in python. Its all in the unit tests folder. Also, check the CMakeLists for module compilation calls: https://github.com/guruofquality/gras/blob/master/tests/example_module.cpp https://github.com/guruofquality/gras/blob/master/tests/module_loader_test.py Sorry for the crummy unit test example. Soon I will switch GrExtras over to the new interface. So there will be a complete project making use of this new feature. Now I just have to figure out where to put the documentation without public headers! -- gory details below - So, the property interface gave us setter and getter registration. My goal was to extend the concept so blocks could register arbitrary methods, with arbitrary arguments into the system. For lack of a better term, its called the callable interface. And here are the docs: https://github.com/guruofquality/gras/wiki/Codeguide#wiki-callable-interface -- Why register methods? 1) Calling methods through this interface is inherently thread-safe. The underlying methods are guaranteed to not be called during an execution of the work() method. This means users do not have to sprinkle boost::mutex calls around their code to get thread safety for things like settings. 2) SWIG'ing class methods, and dealing with the complications of SWIG is unnecessary. Basically, the framework was SWIG'd *once* to export the ability to call registered methods. Once a user registers a class method, its simply just available when the block is instantiated in python. 3) Registering methods gives them programmatic access. Blocks can find each other in the topology and make function calls on each other for configuration purposes. Blocks dont have to know anything about each other's types and class declarations to do this. 4) Every argument and return value can be serialized. This opens the door for deploying and configuring a block on a remote network location and eventually network distributing the topology. Also, there is currently JSON access for the block's registered methods for future web client access. -- Block factory: The callable interface eliminates the need for SWIG'ing the individual methods into python, but we still would need to swig the factory function. So the companion feature is the block factory. Users can register factory functions for their block in C++ and then instantiate the block in python. Just like the callable interface, the factory interface has python bindings provided by the framework, so the user need not lift a finger. https://github.com/guruofquality/gras/wiki/Codeguide#wiki-block-factory -- When to use SWIG? Python bindings are hard, and SWIG makes this part easy. Using SWIG to bind the framework is great. But most users don't have to worry about that, since framework bindings are a one time development effort. The only time I can think of that a user might want to use SWIG is to bind a new type into python. PMC gives us translation between native python and C++ types, but any new types have to be bound and registered. PMC is highly extensible though: https://github.com/guruofquality/PMC/wiki -- Too lazy to compile? Why bother compiling at all? Lets have the framework compile my c++ code: There is already a Clang JIT block if GrExtras. Perhaps soon users can install the cpp files and let the framework manage a compilation cache for object files. I just need another long weekend :-) https://github.com/guruofquality/grextras/wiki/Blocks#wiki-awesome-jit-blocks Thoughts, feedback, questions? Goodnight! -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Problem in uhd_fft
On 07/04/2013 01:41 AM, Karan Talasila wrote: Hi Josh, we tried using the same grc flowgraph and tried transmitting at frequencies 33Mhz and 35 Mhz. Though we could see a constant source output on the fft, the frequency at which that was occuring was at -31Mhz and -29Mhz. The output log is shown below for frequency of 33 Mhz. I have attached a screenshot of my grc too. That sounds correct. The receive chain performs frequency translation with a CORDIC running at 64MHz. So -31MHz is an alias of 33MHz and -29Mhz is an alias of 35MHz -josh enerating: /home/anrc/Downloads/top_block.py Generating: /home/anrc/Downloads/top_block.py Executing: /home/anrc/Downloads/top_block.py linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.004.005-0-unknown Using Volk machine: sse4_1_64 -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... UHD Warning: The hardware does not support the requested RX frequency: Target frequency: 33.00 MHz Actual frequency: -31.00 MHz -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... U Done On Thu, Jul 4, 2013 at 6:36 AM, Josh Blum j...@joshknows.com wrote: On 06/29/2013 09:14 AM, Karan Talasila wrote: -- Forwarded message -- From: Karan Talasila karan@gmail.com Date: Sat, Jun 29, 2013 at 6:44 PM Subject: Re: [Discuss-gnuradio] Problem in uhd_fft To: j...@joshknows.com j...@joshknows.com Hi Josh, I am using USRP 1. I am using a sma-bulkhead cable from Tx_A of basic tx daughter board and similarly a sma-bulkhead cable from Rx_A terminal of the Basic Rx daughter board. and then i am connecting a sma-sma cable from usrp transmitter to a coupler on powerline cable. Similarly I am connecting a sma-sma cable from usrp receiver to another coupler on the powerline cable. so in all I am using 2 usrp 1, 2 sma-sma cables, 2 sma-bulkhead cable and two couplers. Please let me know if i am not clear with the description. Thank you. Seems to work OK for me. I used a single USRP1, BasicRX, BasicTX. RXA is connected to TXA and RXB is connected to TXB. Attached is a GRC flow graph. Hope that helps. -josh On Sat, Jun 29, 2013 at 11:24 AM, Josh Blum j...@joshknows.com wrote: On 06/27/2013 09:44 AM, Karan Talasila wrote: Hi, I am using a basic tx and basic rx daughterboard for transmission and reception. The spec says basic tx and basic rx run from 0 to 250 MHz. But when i run transmitter and check the uhd_fft at receiver, after 32 Mhz, there is no signal. If i set the transmitter frequency in my flowgraph as 33 MHz, I don't get a signal at 33 Mhz, But when i enter frequency as -31Mhz in the uhd_fft i get a received signal on my fft. why does this happen? If it's in the range of daughter board it should be receiving it at that particular frequency right. Can you tell me more about the cabling setup? Which ports of the Basic TX and RX are you using, and how are they connected via SMA cable? -josh ___ 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] Fwd: Problem in uhd_fft
On 06/29/2013 09:14 AM, Karan Talasila wrote: -- Forwarded message -- From: Karan Talasila karan@gmail.com Date: Sat, Jun 29, 2013 at 6:44 PM Subject: Re: [Discuss-gnuradio] Problem in uhd_fft To: j...@joshknows.com j...@joshknows.com Hi Josh, I am using USRP 1. I am using a sma-bulkhead cable from Tx_A of basic tx daughter board and similarly a sma-bulkhead cable from Rx_A terminal of the Basic Rx daughter board. and then i am connecting a sma-sma cable from usrp transmitter to a coupler on powerline cable. Similarly I am connecting a sma-sma cable from usrp receiver to another coupler on the powerline cable. so in all I am using 2 usrp 1, 2 sma-sma cables, 2 sma-bulkhead cable and two couplers. Please let me know if i am not clear with the description. Thank you. Seems to work OK for me. I used a single USRP1, BasicRX, BasicTX. RXA is connected to TXA and RXB is connected to TXB. Attached is a GRC flow graph. Hope that helps. -josh On Sat, Jun 29, 2013 at 11:24 AM, Josh Blum j...@joshknows.com wrote: On 06/27/2013 09:44 AM, Karan Talasila wrote: Hi, I am using a basic tx and basic rx daughterboard for transmission and reception. The spec says basic tx and basic rx run from 0 to 250 MHz. But when i run transmitter and check the uhd_fft at receiver, after 32 Mhz, there is no signal. If i set the transmitter frequency in my flowgraph as 33 MHz, I don't get a signal at 33 Mhz, But when i enter frequency as -31Mhz in the uhd_fft i get a received signal on my fft. why does this happen? If it's in the range of daughter board it should be receiving it at that particular frequency right. Can you tell me more about the cabling setup? Which ports of the Basic TX and RX are you using, and how are they connected via SMA cable? -josh ___ 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 usrp_loop_basics.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization using USRPs
On 06/30/2013 10:45 AM, Mohammed Karmoose wrote: Dear All, I intend on implementing cooperative beamforming techniques using USRPs (two USRPs send precoded versions of the same symbols to null out transmission at certain directions). I need the two USRPs to be almost perfectly synchronized in time and carrier frequency. What are the available time synchronization and local oscillator synchronization techniques using Gnuradio? You may find this helpful: http://files.ettus.com/uhd_docs/manual/html/sync.html -josh ___ 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] delete_head_blocking()
Longer term, the plan is to add scheduler provided functions to call so block work() functions can ask the scheduler to call me again when this happens and the scheduler can handle the blocking/response in a way the gets along with everything else. TL;DR We're working on it :) This feature is already available in the advanced scheduler. Not happy with your input, just mark the port fail, your work wont get called again until the state of the port changes: https://github.com/guruofquality/gras/wiki/Codeguide#wiki-dynamic-feedback Cheers! -josh ___ 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] UHD error
On 06/28/2013 12:29 PM, Jay Prakash wrote: I have 4 N210 USRP accessible via switch. Though it use to come sometime but today even uhd_find_devices gives the same error! Same error different packets. What is your network configuration like? Is this part of the main office network/or dedicated ethernet port w/ the switch and the USRP? Do the devices eventually get found despite the error? What happens if you do uhd_find_devices --args=addr=192.168.1.myaddr -josh UHD Error: Control packet attempt 0, sequence number 6: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 11: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 18: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 22: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 25: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 29: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 33: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 0, sequence number 36: RuntimeError: no control response, possible packet loss * * *How to handle this?* I checked prior comments in mailing list but did get concrete solution. ___ 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] Problem in uhd_fft
On 06/27/2013 09:44 AM, Karan Talasila wrote: Hi, I am using a basic tx and basic rx daughterboard for transmission and reception. The spec says basic tx and basic rx run from 0 to 250 MHz. But when i run transmitter and check the uhd_fft at receiver, after 32 Mhz, there is no signal. If i set the transmitter frequency in my flowgraph as 33 MHz, I don't get a signal at 33 Mhz, But when i enter frequency as -31Mhz in the uhd_fft i get a received signal on my fft. why does this happen? If it's in the range of daughter board it should be receiving it at that particular frequency right. Can you tell me more about the cabling setup? Which ports of the Basic TX and RX are you using, and how are they connected via SMA cable? -josh ___ 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] Hopping Frequency Synchronization algorithm used in PRE-COG
On 06/24/2013 03:58 AM, Gong Zhang wrote:
Josh,
I'm curious about how it tune the LO in USRP. Does it control the LO
via
'post_msg(CTRL_PORT,pmt.pmt_string_to_symbol('usrp_sink.set_center_freq')'?
Thanks.
Well, current pre-cog uses the v3.6 gr-extras out of tree message
passing to execute functions on the USRP python object. Basically the
control block would pass some sort of PMT to an output message port,
this would go to the input port of the PMT RPC block, which would then
execute a function on the usrp object in the python flowgraph.
Here is pre-cog making the call: This line:
https://github.com/jmalsbury/pre-cog/blob/master/python/fhss_engine_rx.py#L185
And the old PMT RPC block:
https://github.com/guruofquality/grextras/blob/grextras_v3.6/python/pmt_rpc.py#L78
That works, but no one is really endorsing that particular method. Think
of it as a one-off to set things working. What I think we really want is
a good API friendly framework supported way to set properties on blocks.
Given that I have learned a lot from the pre-cog development struggles,
GRAS now has a programmatic way for blocks to register properties and
access the properties of other blocks.
Properties interface:
https://github.com/guruofquality/gras/wiki/Codeguide#wiki-property-interface
USRP control block to set properties on:
https://github.com/guruofquality/grextras/wiki/Blocks#wiki-misc-uhd-blocks
Now the code in fhss_engine, might look more like this (thanks Yogesh):
self.uhd_control_sink.set(command_time,uhd.time_spec_t(self.interval_start))
self.uhd_control_sink.set(rx_freq,uhd.tune_request_t(self.freq_list[self.hop_index]))
self.uhd_control_sink.set(command_time,uhd.time_spec_t(0.0))
sort of relevant discussion
http://www.ruby-forum.com/topic/4414817#1112615
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to specify vector input signature for gr_sync_block.
On 06/22/2013 08:46 AM, Manu T S wrote: I am trying to write code for a block which accepts a vector input and spits out a vector output. The block is derived from gr_sync_block. From the tutorial on OOThttp://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#Adding-the-block-codeI have the following information. For a block with single input and single output the __init__ method is as given below. def __init__(self):gr.sync_block.__init__(self, name = square3_ff,** in_sig = [numpy.float32], out_sig = [numpy.float32]) How do I take in a vector input? That parameter numpy.float32 is passed into the dtype for the numpy array. Anything you can pass to numpy as a dtype can be used. this unit test outputs a stream of float vectors: class fc32_to_f32_2(gr.sync_block): def __init__(self): gr.sync_block.__init__( self, name = fc32_to_f32_2, in_sig = [numpy.complex64], out_sig = [(numpy.float32, 2)], ) def work(self, input_items, output_items): output_items[0][::,0] = numpy.real(input_items[0]) output_items[0][::,1] = numpy.imag(input_items[0]) return len(output_items[0]) -josh ___ 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] Getting gnuradio 3.6.5 working on Linux Mint 14
On 06/22/2013 06:31 PM, Chris Adie wrote:
I can install gnuradio fine from the Mint repository - it works, but it is
version 3.6.1. I want to use the rtlsdr stuff, so I need at least version
3.6.4.
So, I de-installed 3.6.1 and used the build-gradio script to install
version 3.6.5. The script completes successfully. However, when I try and
make the multimode.py example, I get this:
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-core-3.6.5.so.0.0.0: undefined
symbol: volk_64u_byteswap_u
Someone else had a similar problem a few months ago - there was no clear
resolution, though.
Any clues?
We have had issues with builds compling against installed headers. Try
removing installed volk hdrs in /usr/include and /usr/local/include first.
(PS - another data point - gnuradio-companion does not work either - it
complains that I've got PYTHONPATH or LD_LIBRARY_PATH wrong - not guilty?)
___
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] WX GUI Widgets missing
On 06/21/2013 04:35 AM, Les Barker wrote: Hi All I have built gnuradio from the s.b.r.a.c link without any errors. When using GR Companion there are only 2 items under WX GUI Widgets i.e. Plot Sink and WX DOA Compass. The waterfall sink and FFT sink, together with many others, are not available. I have checked under the blocks list and these are listed. How do I get GRC to make these blocks available? Either you didnt have wx python installed when gnuradio was configured or the category has moved. Try looking in categoryGUI Widgets/WX/category or use the search feature. -josh Your help will be appreciated. Regards Les ___ 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] Run time FIFO error
On 06/21/2013 09:41 AM, Tim Newman wrote: Yes, bringing this back up. Back to the original topic. When I get this FIFO ctrl error, the host is sending back an icmp port unreachable msg to the usrp, I grab this using wireshark. Well if the app shutdown from the error. That could be the host's response to a stray packet coming from the USRP after the socket was closed. For example a UDP packet w/ a GPSDO NMEA message. So this ICMP error may not be indicative of anything. All I'm doing is running uhd_usrp_probe. I've tried with and without adding the --args addr=ip parameter, same thing using both. I've debugged a bit, and increased the ACK_TIMEOUT in usrp/usrp2/usrp2_fifo_ctrl.cpp from 0.5 to 10.0 and it literally just sits at: Creating the usrp device with: ... -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes sits here for 10 seconds Then spits out RuntimeError: RuntimeError: fifo ctrl timed out looking for acks Again, there is a switch in between the USRP and the host. Yup, definitely a lost packet. Its gone and more time isnt going to help. Question is, where is the packet lost? We have a control packet from host to switch, then switch to USRP. Then a response packet from USRP to switch, then switch to host. -josh Tim On Thu, Jun 13, 2013 at 12:27 AM, Sean Nowlan sean.now...@gtri.gatech.eduwrote: I think 512 is the max value for N on N200/N210 hence 195kSps is minimum sample rate. Karan Talasila karan@gmail.com wrote: @sean can you please tell me how you got minimum sampling rate for usrp N210 as 100*e6/512. I know that the sampling rate should be 100*e6/N where N is an integer. So N can be any integer even greater than 512 right. In that way, what is the minimum that the USRP accepts. what is maximum N that can be used. On Thu, Jun 13, 2013 at 6:20 AM, Sean Nowlan sean.now...@gtri.gatech.eduwrote: On 06/12/2013 08:49 PM, Marcus D. Leech wrote: On 06/12/2013 08:29 PM, Sean Nowlan wrote: The minimum reasonable sample rate I've used is 2e5 (100e6/2e5 = 500). I think 100e6/512 = 195312.5 is the smallest supported rate. Yup, sorry, you're right. I tend to pick values that are valid for both 64Msps and 100Msps master clock rates, since I write apps that need to be reasonably agnostic with respect to hardware. Ah, makes sense. __**_ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Regards Karan Talasila ___ 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] HIer block---Generate error
On 06/21/2013 07:02 AM, stefosee wrote: Hi, i'm trying to create my first hier block following these rules: http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Hierarchical-Blocks but when i'm going to generate the flow graph, i get the error message: Generate Error: All strings must be XML compatible: Unicode or ASCII, no NULL bytes or control characters Is there more verbose to go with that error? Can you attach a minimal example that causes the problem? -josh I also tried a very simple graph like pad source(float)-throttle(float)-pad sink(float) but i face the same problem. throttle rate's value is the value of a parameter i set as sample_rate. Any advice? thx -- View this message in context: http://gnuradio.4.n7.nabble.com/HIer-block-Generate-error-tp42161.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ 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] HIer block---Generate error
On 06/21/2013 01:59 PM, stefosee wrote: http://gnuradio.4.n7.nabble.com/file/n42181/screenshot.png Can you try using an all ASCII path for the grc file? I think the XML parser may be having trouble w/ the characters in the file path. -josh -- View this message in context: http://gnuradio.4.n7.nabble.com/HIer-block-Generate-error-tp42161p42181.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ 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] Build Script issue
On 06/21/2013 04:10 PM, Jay Prakash wrote: I am using Ubuntu 11.10. Though I installed Gnu Radio on two systems using same script, it's not working on new system! wget http://www.sbrac.org/files/build-gnuradio chmod a+x ./build-gnuradio ./build-gnuradio .. . . checking for library libboost ...Found library libboost Checking for library libcppunit ...Found library libcppunit Checking for library libfftw ...Found library libfftw Checking for library libgsl ...Found library libgsl Done Skipping git fetch, since 'uhd' and 'gnuradio' are new enough *Starting function uhd_build at: Sat Jun 22 01:37:16 IST 2013 Building UHD... = THIS WILL TAKE SOME TIME = ./build-gnuradio: line 780: cd: uhd/host: No such file or directory UHD build apparently failed Exiting UHD build* Chances are that this is the same firewall issue that you mentioned last week. There are a lot of https links in the script. Why dont you find out why your network is blocking https or if its a PC setup issue? -josh ___ 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] Flow graph issue with usrp1+RFX2400 daughter board and TX/RX antenna
On 06/21/2013 07:25 PM, Arturo Rinaldi wrote: Hi folks, I've recently bumped into an issue with two GRC flow graphs while running a rx/tx loop path interfacing with an external sensor : *T**X path - UHD Usrp1 Sink (sending data to the sensor)* http://img713.imageshack.us/img713/4540/gyz.png *RX path - UHD Usrp1 Source (receiving data from the sensor)* http://img822.imageshack.us/img822/521/dq8.png I'm using a USRP1 mainboard and a RFX2400 daughter board using the TX/RX section. I can run the TX flow graph, but when i launch the other one, the shell warns me about an UHD error. The uhd driver can't find the usrp1 card (specifically, the *uhd source object* can't be built because the uhd driver is not able find the usrp device), it's like the tx path had an exclusive possession of the A:0 subdevice (the *TX/RX* one on which I put my antenna). Do I have to pass some command line switches to the uhd driver to solve this issue ? Thanks in advance. The device can only be opened once per process. Either run both flow graphs in the same process, or combine both flowgraphs into one flowgraph. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Adding extra errors while transmission
If it helps, the packet framer actually inputs bytes, not bits. So thats 8 bits of information per byte. So rather than 1/0, you have 0-255 as possibilities. -- not sure if that effects your experiment, just FYI -josh On 06/19/2013 12:28 PM, Jay Prakash wrote: Most of the times I get:- 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 for transmission of :- 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 0101010101010101010101010101010101010101010101010101010101010101010101 *My channel model Parameters:- * *self.channel_model_0 = filter.channel_model(* * noise_voltage=0.00,* * frequency_offset=0.00,* * epsilon=1.0,* * taps=([1.0, 0.25-0.25j, 0.50 + 0.10j, -0.3 + 0.2j, 0.1 - 0.01j, -0.2 + 0.2j] ),* * noise_seed=3,* * )* * * *Jay Prakash * ___ 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] Cannot import gnuradio
On 06/19/2013 08:57 AM, Marcus D. Leech wrote: On 06/19/2013 02:22 AM, Favati wrote: Il 15/06/2013 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'm thinking this message could also hint at that magic incantation of sudo ldconfig. But seriously, run sudo ldconfig, the OS pretends not to know about installed libraries until the cache is updated. -josh 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 Same here...fresh and updated ubuntu 13.04 64bit :( ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio If you open up a terminal window and type: echo $PYTHONPATH What do you get? Do you have Python2.7 installed?What is actually in directory /usr/local/lib/python2.7/dist-packages? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRCC No GUI?
Following up on a comment Josh made in the earlier discussion about GRCC, I
tried to pull out all of the GUI references that the GRCC tool depends on,
but I still ended up with an enigmatic error in the end. Unfortunately,
this was done two weeks ago and I don't have any good info on where I left
it.
I think I had mentioned that GRCC could import the non-gui stuff, from
the grc/python directory, and that would avoid the import gtk statement,
which is messing up the ability to do non gui stuff.
So looking into grc/python
~/src/gnuradio/grc/python$ grep gtk *
flow_graph.tmpl:#import gtk
flow_graph.tmpl:#set $icon =
gtk.IconTheme().lookup_icon('gnuradio-grc', 32, 0)
Param.py:import pygtk
Param.py:pygtk.require('2.0')
Param.py:import gtk
Param.py: input = gtk.Button('...')
Param.py: file_dialog = gtk.FileChooserDialog('Open a
Data File...', None,
Param.py: gtk.FILE_CHOOSER_ACTION_OPEN,
('gtk-cancel',gtk.RESPONSE_CANCEL,'gtk-open',gtk.RESPONSE_OK))
Param.py: file_dialog = gtk.FileChooserDialog('Save a
Data File...', None,
Param.py: gtk.FILE_CHOOSER_ACTION_SAVE,
('gtk-cancel',gtk.RESPONSE_CANCEL, 'gtk-save',gtk.RESPONSE_OK))
Param.py: if gtk.RESPONSE_OK == file_dialog.run(): #run the
dialog
It looks like only the Param.py would cause a runtime import issue with
gtk/pygtk. In this case, that imprt statement could be moved to the
indentation level where it is used (file dialog).
Did you notice other modules pulling gtk imports that should not have?
Or were you unable to rewrite the GRCC to completely avoid importing
modules from grc/gui?
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] full duplex operation gnuradio
On 06/17/2013 05:13 PM, Ankan Roybardhan wrote: How do I test full duplex capability on gnuradio usrp N200 sbx daughterboard?? Open gnuradio-companion and instantiate a USRP source and a USRP sink block in the same flowgraph. -josh -Regads, Ankan Roybardhan. ___ 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] clock synchronization by message passing
On 06/16/2013 02:13 PM, Adeel Anwar wrote: so i checked the new grextras wiki it has uhd_control block i guess that can be used for this job. uhd_control block supports only a subset of usrp-functions (exposed through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT currently it doesn't support set_time_now() https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp I didnt add every possible setting. But I am happy to add more on request! I'm gathering that someone would like to make a configuration and control block that could perform the synchronization tasks w/ a GPSDO or some external clock and time source. The intention of the UHDControlPort block was to help clean up much of the messy control logic in pre-cog. We were passing messages into a python block that was executing python functions onto the flowgraph. Sure it worked though :-) But now there is an API to do configuration and control nicely. My intention with the UHDControlPort was to allow for frequency hopping control in a programatic way (and other stuff too). The UHDControlPort block uses the property interface to expose device properties that can be set by another entity -- like some sort of configuration block. https://github.com/guruofquality/gras/wiki/Properties So lets say the control block intended to frequency hop and perform a new transmission: 1) This control block would find the UHDControlPort in the element tree (you would probably do this once in the notify_active() callback). 2) The control block calls uhd_control_block-set(command_time, t0); uhd_control_block-set(tx_freq, new_freq); 3) The control block now causes a time-tagged message to be sent to the transmit chain. control_block - packet_framer - modulator - usrp_sink The time of the transmission would be t0 + some delta to allow the command of tuning the frontend to have settle time. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] clock synchronization by message passing
On 06/16/2013 10:44 PM, Josh Blum wrote: On 06/16/2013 02:13 PM, Adeel Anwar wrote: so i checked the new grextras wiki it has uhd_control block i guess that can be used for this job. uhd_control block supports only a subset of usrp-functions (exposed through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT currently it doesn't support set_time_now() https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp I didnt add every possible setting. But I am happy to add more on request! I'm gathering that someone would like to make a configuration and control block that could perform the synchronization tasks w/ a GPSDO or some external clock and time source. OK, exposed access to time source, clock source, and time registers. Use it in good health! https://github.com/guruofquality/grextras/commit/341f351159961acc0bb6e46402e9ed28d618cd64 -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] scheduler doubt
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
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 (vectorvector ins,vectorvector 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
Re: [Discuss-gnuradio] Gras make error
I am especially interested in gr-extras, what seems to be a part of gras now. Will this be available for gnuradio 3.7 standalone, or just as part of gras? I do not like the idea of gras hovering over gnuradio, but like much more an independent gnuradio installation in its standard folder, and the additional stuff a bit more separated from this :) Well actually its a really granular architecture where every little piece is simple, has its own purposes, and has its own value individually. To give you an idea of the components, here is the little dependency map from the build guide: http://i.imgur.com/U4QvBgd.png I happen to be bringing in each component as a submodule into GRAS so its easy to version and easy to install as one project. But the reality is that the projects could be installed individually, or even used for unrelated purposes. I hope that some of this submodule business changes in the long run because I ultimately dont want to track gnuradio changes in a submodule. I would rather that mainline gnuradio master have an option to use the advanced scheduler. Thats why for my 3.7 support work, I am producing a mergable branch so the underlying scheduler is just another compile time selection. Thats basically working, but the remaining challenge is to get all the different APIs and features working together, so you can have a superset of APIs, features, and blocks. And so back to GrExtras: this is actually a standalone/out-of-tree project, which contains just blocks. GrExtras was intended to make use of, and to demonstrate the new scheduler features and API found in GRAS, so naturally it depends on GRAS. But it doesnt make sense to depend on gnuradio 3.7 or rewrite for 3.7 since in this case, the motivation for extras was to demonstrate these cool new capabilities. I hope that clarifies things. Everything feels like quite a jumble of APIs and git repos. Hopefully things get nailed down, stabilized, and versioned later this summer. -josh PS As I write this email, I am using dot to visualize a deadlock condition in one of the QA tests on my 3.7 support branch. Thought I would share the png: http://i.imgur.com/QfLz4aL.png :-) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Decoding UDP socket output
On 06/13/2013 01:23 PM, Adriana Arteaga wrote:
Hi!
I'm using an udp_sink block to send the power values (float) to an common udp
socket writing with python
data, addr = sock.recvfrom(2048)
but the outup was:
����ٶ��e�¹�¢���\d�5�S���8�®Z��xS�� ���A����T�
I found data = sock.recv(1).decode('utf-8') function, but the output was:
received message:
Traceback (most recent call last):
File udp_connection.py, line 12, in module
data = sock.recv(1).decode('utf-8')
File /usr/lib/python2.7/encodings/utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xf9 in position 0:
invalid start byte
I'm try changing utf-8 for utf8 and the result is the same. Anyone knows
how can I decode the output?
If the bytestream is encoded as floats (if I have understood correctly),
why would you decode it as utf8?
Try numpy.fromstring(your_data, numpy.float32) to get a nice array
object in python from such a string.
-josh
Thanks.
Adriana
___
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] As if pounding my head against the wall of C++ weren't enough, this apparently innocent bit of XML fails block validation
Well, in the dtd, value should be before type !ELEMENT param (name, key, value?, type, hide?, option*) On 06/13/2013 08:15 PM, Marcus D. Leech wrote: Here's the XML: ?xml version=1.0? block nameOblivious Slicer/name keyra_blocks_slicer/key categoryRA Blocks/category importimport ra_blocks/import makera_blocks.slicer($decim, $thresh)/make param nameSamples/name keydecim/key typeint/type value100/value /param param nameThreshold/name keythresh/key typefloat/type value1.5/value /param sink namein/name typefloat/type /sink source nameout/name typefloat/type /source /block GO ahead, try it. Explosions. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gras make error
On 06/13/2013 09:20 PM, Jay Prakash wrote: While doing cmake for installing Gras it gives: - *Using install prefix: /usr/local* *CMake Error at gnuradio/CMakeLists.txt:245 (GR_LOGGING):* * Unknown CMake command GR_LOGGING.* I got gnuradio in gras directory from git clone http://github.com/gnuradio/gnuradio Jay Prakash There is a special version of gnuradio that is submoduled into GRAS that is known to work, this is what you get when you run git submodule init and update from the build guide. But the build is not going to work against any arbitrary version of gnuradio. https://github.com/guruofquality/gras/wiki/Build#get-the-source-code What is your intention? Is it because you are looking to use gnuradio 3.7? If so, the gnuradio 3.7 GRAS support branch is almost finished and will be merged in soon. But I dont think its ready yet, this branch contains the work: https://github.com/guruofquality/gnuradio/tree/runtime_pimpl -josh ___ 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] simple_arq (single packet loss)
On 06/13/2013 09:34 PM, Yogesh Dahiya wrote: I have written this simple_arq block which sends a packet wait for ack before sending other. I have created a hier block for physical layer (I have tested the physical layer its working) but the mac block is not receiving. Why is it so that when we send a single packet it gets lost but when we send multiple packet every packet is received? When it works, are the multiple packets directly one after another? AKA back-to-back? If so, a few quick thoughts: Perhaps there is an issue with ramp up or ramp down transition period, which causes packet header or trailer corruption. If you pad extra samples onto the front and back of a transmit burst, does that help the single packet case? -josh Here is the github repo for the same : https://github.com/yogeshd2612/cog_mac aloha_mac - implementation of arq block phy - implementation of phy hier block test_phy - test for phy test_alhoa - test for arq block ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gras make error
On 06/13/2013 09:46 PM, Jay Prakash wrote: I followed same as given on the gras wiki you suggested. only problem now is gnuradio cloning. Which git repo of gnuradio should I clone for successfully making gras? You dont have to do anything special, this operation is automatic when the following commands from the build guide are run: git clone https://github.com/guruofquality/gras.git cd gras git submodule init git submodule update This is a pastebin of the complete checkout: http://pastebin.com/nKCx7b2i And here is configuration w/ cmake: http://pastebin.com/MTRzjpX3 -josh Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/ http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top On Fri, Jun 14, 2013 at 7:00 AM, Josh Blum j...@joshknows.com wrote: On 06/13/2013 09:20 PM, Jay Prakash wrote: While doing cmake for installing Gras it gives: - *Using install prefix: /usr/local* *CMake Error at gnuradio/CMakeLists.txt:245 (GR_LOGGING):* * Unknown CMake command GR_LOGGING.* I got gnuradio in gras directory from git clone http://github.com/gnuradio/gnuradio Jay Prakash There is a special version of gnuradio that is submoduled into GRAS that is known to work, this is what you get when you run git submodule init and update from the build guide. But the build is not going to work against any arbitrary version of gnuradio. https://github.com/guruofquality/gras/wiki/Build#get-the-source-code What is your intention? Is it because you are looking to use gnuradio 3.7? If so, the gnuradio 3.7 GRAS support branch is almost finished and will be merged in soon. But I dont think its ready yet, this branch contains the work: https://github.com/guruofquality/gnuradio/tree/runtime_pimpl -josh ___ 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] Gras make error
On 06/13/2013 10:00 PM, Jay Prakash wrote: I did so. But at last step ie git submodule update I got:- *git submodule update* *fatal: reference is not a tree: 53223d7e7c60974bd56ec3287fdc184ea910087b* *Unable to checkout '53223d7e7c60974bd56ec3287fdc184ea910087b' in submodule path 'gnuradio'* I manually cloned each then and ran cmake. Delete whatever directories you cloned. Run exactly these commands git clone https://github.com/guruofquality/gras.git cd gras git submodule init git submodule update I swear it will work. If there is an error, please send me the verbose from the terminal. All of the verbose, including commands entered. -josh Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/ http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top On Fri, Jun 14, 2013 at 7:24 AM, Josh Blum j...@joshknows.com wrote: On 06/13/2013 09:46 PM, Jay Prakash wrote: I followed same as given on the gras wiki you suggested. only problem now is gnuradio cloning. Which git repo of gnuradio should I clone for successfully making gras? You dont have to do anything special, this operation is automatic when the following commands from the build guide are run: git clone https://github.com/guruofquality/gras.git cd gras git submodule init git submodule update This is a pastebin of the complete checkout: http://pastebin.com/nKCx7b2i And here is configuration w/ cmake: http://pastebin.com/MTRzjpX3 -josh Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/ http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top On Fri, Jun 14, 2013 at 7:00 AM, Josh Blum j...@joshknows.com wrote: On 06/13/2013 09:20 PM, Jay Prakash wrote: While doing cmake for installing Gras it gives: - *Using install prefix: /usr/local* *CMake Error at gnuradio/CMakeLists.txt:245 (GR_LOGGING):* * Unknown CMake command GR_LOGGING.* I got gnuradio in gras directory from git clone http://github.com/gnuradio/gnuradio Jay Prakash There is a special version of gnuradio that is submoduled into GRAS that is known to work, this is what you get when you run git submodule init and update from the build guide. But the build is not going to work against any arbitrary version of gnuradio. https://github.com/guruofquality/gras/wiki/Build#get-the-source-code What is your intention? Is it because you are looking to use gnuradio 3.7? If so, the gnuradio 3.7 GRAS support branch is almost finished and will be merged in soon. But I dont think its ready yet, this branch contains the work: https://github.com/guruofquality/gnuradio/tree/runtime_pimpl -josh ___ 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] Gras make error
On 06/13/2013 10:20 PM, Jay Prakash wrote: Here it is:- spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test$ git clone http://github.com/guruofquality/gras.git fatal: destination path 'gras' already exists and is not an empty directory. spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test$ rm -r gras/ spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test$ git clone http://github.com/guruofquality/gras.git Perhaps this is a clue, why not https like in the build instructions, does git clone https://github.com/guruofquality/gras.git not work? The submodules are all https. Is that for some reason not working or blocked for your campus internet? Cloning into gras... remote: Counting objects: 5015, done. remote: Compressing objects: 100% (2104/2104), done. remote: Total 5015 (delta 2631), reused 4979 (delta 2597) Receiving objects: 100% (5015/5015), 1.64 MiB | 456 KiB/s, done. Resolving deltas: 100% (2631/2631), done. spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test$ cd gras spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test/gras$ git submodule init Submodule 'Apology' (https://github.com/guruofquality/Apology.git) registered for path 'Apology' Submodule 'PMC' (https://github.com/guruofquality/PMC.git) registered for path 'PMC' Submodule 'Theron' (https://github.com/guruofquality/Theron.git) registered for path 'Theron' Submodule 'gnuradio' (https://github.com/guruofquality/gnuradio.git) registered for path 'gnuradio' Submodule 'grextras' (https://github.com/guruofquality/grextras.git) registered for path 'grextras' spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test/gras$ git submodule update Cloning into Apology... Can you: git clone https://github.com/guruofquality/Apology.git cd Apology git log ab6fc7615056dd5b6c737e1f4005250fe0281039 should be the topmost commit. -josh fatal: reference is not a tree: ab6fc7615056dd5b6c737e1f4005250fe0281039 Unable to checkout 'ab6fc7615056dd5b6c737e1f4005250fe0281039' in submodule path 'Apology' Link of pastebin http://pastebin.com/2gXAmayz On Fri, Jun 14, 2013 at 7:42 AM, Josh Blum j...@joshknows.com wrote: git submodule update Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/ http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gras make error
On 06/13/2013 10:35 PM, Jay Prakash wrote: Ya git clone with https is not working. Well, I cant work around every firewall issue. But in this case, i changed the submodules to http and the build instructions. Future checkouts should work if https is blocked. function ‘void AddImpltype::work(const InputItems, const OutputItems) [with type = float, gras::Block::InputItems = gras::WorkBufferArrayconst void*, gras::Block::OutputItems = gras::WorkBufferArrayvoid*]’: /home/spclab/Desktop/summer_/examples/gras/grextras/lib/add.cpp:80:57: error: ‘volk_32f_x2_add_32f’ was not declared in this scope make[2]: *** [grextras/lib/CMakeFiles/grextras.dir/add.cpp.o] Error 1 make[1]: *** [grextras/lib/CMakeFiles/grextras.dir/all] Error 2 make: *** [all] Error 2 Im pretty sure that an installed version of those volk headers is getting included when you build. This is probably due to somewhere in the code, a public include directory is preferenced over a local include directory. I can suggest a few fixes: 0) I just pushed a possible fix, update and try this first. 1) If not, try: make VERBOSE=1, send me the output, it will tell me if this include issue is the problem or not, and which include directories are the problem 2) Remove installed headers in /usr/local/include/volk and /usr/include/volk .Are these directories present? I am curious if this is the case -josh Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/ http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top On Fri, Jun 14, 2013 at 7:58 AM, Josh Blum j...@joshknows.com wrote: On 06/13/2013 10:20 PM, Jay Prakash wrote: Here it is:- spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test$ git clone http://github.com/guruofquality/gras.git fatal: destination path 'gras' already exists and is not an empty directory. spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test$ rm -r gras/ spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test$ git clone http://github.com/guruofquality/gras.git Perhaps this is a clue, why not https like in the build instructions, does git clone https://github.com/guruofquality/gras.git not work? The submodules are all https. Is that for some reason not working or blocked for your campus internet? Cloning into gras... remote: Counting objects: 5015, done. remote: Compressing objects: 100% (2104/2104), done. remote: Total 5015 (delta 2631), reused 4979 (delta 2597) Receiving objects: 100% (5015/5015), 1.64 MiB | 456 KiB/s, done. Resolving deltas: 100% (2631/2631), done. spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test$ cd gras spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test/gras$ git submodule init Submodule 'Apology' (https://github.com/guruofquality/Apology.git) registered for path 'Apology' Submodule 'PMC' (https://github.com/guruofquality/PMC.git) registered for path 'PMC' Submodule 'Theron' (https://github.com/guruofquality/Theron.git) registered for path 'Theron' Submodule 'gnuradio' (https://github.com/guruofquality/gnuradio.git) registered for path 'gnuradio' Submodule 'grextras' (https://github.com/guruofquality/grextras.git) registered for path 'grextras' spclab@spclab-GT701AA-ACJ-SR5250IL:~/Desktop/summer_/test/gras$ git submodule update Cloning into Apology... Can you: git clone https://github.com/guruofquality/Apology.git cd Apology git log ab6fc7615056dd5b6c737e1f4005250fe0281039 should be the topmost commit. -josh fatal: reference is not a tree: ab6fc7615056dd5b6c737e1f4005250fe0281039 Unable to checkout 'ab6fc7615056dd5b6c737e1f4005250fe0281039' in submodule path 'Apology' Link of pastebin http://pastebin.com/2gXAmayz On Fri, Jun 14, 2013 at 7:42 AM, Josh Blum j...@joshknows.com wrote: git submodule update Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/ http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] message buffers
On 06/14/2013 01:02 AM, Yogesh Dahiya wrote: when taking the len of input buffer (len[0]) it shows 0 but when i am calling pop_input_msg(0) it return the msg object ? So an input port can have 3 types of input buffers, messages, and tags. Think of buffers as bulk data, tags are inline messages associated with the bulk data, and messages are just messages that are asynchronous to the bulk data. len(ins[0]) would be non zero if an upstream block produced a buffer pop_input_msg(0) would return a non-null PMC if an upstream block produced a message. In this case, I think your block is only expecting the asynchronous messages, so len(ins[0]) would always == 0. -josh ___ 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] Precog Import Error
On 06/11/2013 10:02 PM, Jay Prakash wrote: I have installed the extras and precog as per wiki. The gnuradio-comapnion extras blocks are working fine. But when I try to run precog modules given there is error:- Precog requires an older version of grextras on this branch: https://github.com/guruofquality/grextras/tree/grextras_v3.6 You should be able to install it along side the newer grextras without interfering. Also relevant: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-05/msg00492.html -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] issue with precog with new grextras
On 06/12/2013 12:38 PM, Yogesh Dahiya wrote: i guess some of the older features of grextras are missing in the new one like the gr.block . gruel files pmt_blob, pmt_mgr, pmt_extras are also missing. The newer grextras is just blocks. The features mentioned went into the advanced scheduler. https://github.com/guruofquality/gras/wiki In particular, all the blob stuff has been replaced a smart buffer which can be used to pass blobs of data with messages, or represent buffers in the stream domain. And can go in between message and stream domains w/o incurring a copy. Heavily used in the new grextras blocks. Because of all this precog is in broken state. older grextras ( https://github.com/ncorgan/grextras) new one (https://github.com/guruofquality/grextras ) Is there any fix to this? Precog requires an older version of grextras on this branch: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-05/msg00492.html Sorry for the confusion. At this particular period in time the software seems to be all over the place and nothing is versioned or released yet. -josh ___ 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] make test errors
On 06/12/2013 08:47 AM, Botany Dave wrote: Is there a way to check before I do make install? I'm still at the point of trying to resolve issues found while running make test. when you configure, cmake ~/src/gnuradio-checkout... The last thing printed should be the git hash The best thing you can do is collect all the error verbose, and then OS version, gr version, and get it on a bug tracker issue so the devs can replicate and fix it. -josh From: Karan Talasila [via GnuRadio] ml-node+s4n41959...@n7.nabble.com To: Botany Dave sd_wirel...@yahoo.com Sent: Wednesday, June 12, 2013 2:29 AM Subject: Re: make test errors Hi Dave, To know the gnuradio version being used type gnuradio-config-info -v in the terminal. On Wed, Jun 12, 2013 at 6:45 AM, Dave L [hidden email] wrote: The OS is Ubuntu 12.10 (32 bit). Frankly, I'm not sure which version of gnuradio this is, but I installed it from http://gnuradio.org/git/gnuradio.git/ last week. From: Josh Blum [hidden email] To: [hidden email] Sent: Tuesday, June 11, 2013 6:02 PM Subject: Re: [Discuss-gnuradio] make test errors On 06/11/2013 07:34 PM, Botany Dave wrote: ./volk/lib/test-all completes with no errors found. Any other suggestions would be very much appreciated. :-( Well, having the volk qa fail would have nicely narrowed it down. I guess that now its potentially ambiguous to blame volk. The good news, I think those tests are related. Can you report the OS name version, 32/64 bit? The version of gnuradio where the tests failed? -josh From: Josh Blum-2 [via GnuRadio] ml-node+[hidden email] To: Botany Dave [hidden email] Sent: Monday, June 10, 2013 7:13 PM Subject: Re: make test errors Run volk/lib/test_all from the build dir If a kernel fails, it will tell you which one, start commenting out its implementations in the source dir volk/kernels/volk/volk_*.h until the test works. We narrow down suspect implementation and fix. -josh On 06/10/2013 09:57 PM, Dave L wrote: The CPU on the laptop is an Intel i3-2350M (64 bit). What steps should I take (or where can I learn how) to resolve the problem with Volk? Dave From: Tom Rondeau [hidden email] To: Botany Dave [hidden email] Sent: Monday, June 10, 2013 6:41 AM Subject: Re: [Discuss-gnuradio] make test errors On Thu, Jun 6, 2013 at 11:52 PM, Botany Dave [hidden email] wrote: I'm new to this, and I'm sure it will show... I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I followed the instructions at http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview and am getting errors on four modules when I run make test. They are: 86 - qa_fir_filter 91 - qa_freq__xlating_fir_filter 150 - qa_constellation_receiver 169 - qa_codec2_vocoder Here is the output of ctest -V -R qa for each of those modules. I'd really appreciate any guidance on how to resolve these failures. 86: Test command: /bin/sh /home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh 86: Test timeout computed to be: 9.99988e+06 86: .FF 86: == 86: FAIL: test_fir_filter_scc_001 (__main__.test_filter) 86: -- 86: Traceback (most recent call last): 86: File /home/dave/gnuradio/gr-filter/python/qa_fir_filter.py, line 262, in test_fir_filter_scc_001 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 74, in assertComplexTuplesAlmostEqual 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 47, in assertComplexAlmostEqual 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places 86: 86: == 86: FAIL: test_fir_filter_scc_002 (__main__.test_filter) 86: -- 86: Traceback (most recent call last): 86: Using Volk machine: avx_32_mmx 86: File /home/dave/gnuradio/gr-filter/python/qa_fir_filter.py, line 281, in test_fir_filter_scc_002 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 74, in assertComplexTuplesAlmostEqual 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 86: File /home/dave/gnuradio/gnuradio-runtime/python
Re: [Discuss-gnuradio] Run time FIFO error
On 06/12/2013 06:54 PM, Marcus D. Leech wrote: On 06/12/2013 06:52 PM, Jay Prakash wrote: USRP N210 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio This error is usually caused by the network connection dropping packets. Are you directly connected to your PC? What kind of network card do you have? Jay mentioned in a previous email ubluntu 11.10, which is quite old by now (13.04 is out). Perhaps there could be a network driver issue that was resolved in a newer release. -josh ___ 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] Run time FIFO error
On 06/12/2013 07:14 PM, Jay Prakash wrote: I am connecting it on LAN using D-Link router. Is the dlink router have gigabit ethernet on all ports between USRP and PC? Sorry to say I have never had good experiences with dlink products, and that includes outside of the USRP realm. :-( A lot of applications can get away with lossy traffic because they are intended to go over the internet, like TCP, or stuff that builds reliability on top of UDP, like file sharing applications. But N210 expects reliability over a local ethernet link. There was this discussion on usrp users (relevant): http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-November/005729.html -josh ___ 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] USRP_N200 unable to connect via vmplayer
On 06/11/2013 02:19 AM, Ankan Roybardhan wrote: 1. I tried using vm bridged connection over NAT.. i assigned 192.168.10.1 and subnet 255.255.255.0 in the ubuntu network setting running on vmplayer.. I am pretty much sure about the other USRP IP since.. i used some other machine to do uhd_find_devices .. so check for their IPs.. 2. My ethernet port is working fine on windows.. I though did not check it on my vm.. bt hopefully it is working since it is recognizing the LAN.. 3. The sw is perfectly fine tested OK. 4. I changed it from dhcp to manual ipv4 settings as 1. the problem persists.. the device is on 192.168.10.3.. i did uhd_usrp_probe with --args=ip of the usrp... it says the same. could not find devices.. I feel there is a big issue with the vmplayer network settings with uhd... Well, can you ping the USRP from the VM? That would eliminate the question of uhd and UDP sockets. Can you ping another device with a static IP though the VM, like a router that is connected to the same network interface as the USRP? -josh -Ankan Roybardhan. On Tue, Jun 11, 2013 at 1:29 AM, Karan Talasila karan@gmail.com wrote: Hi, Check if your usrp is surely on 192.168.10.3. Run uhd_usrp_probe and check if it is giving any output. Do you have gigabit ethernet card on your laptop. If not, you will have to use a switch in between and some times switch might be an issue. one more thing, are you connected on static ip? If you are on dhcp, change it to static ip and see. On Tue, Jun 11, 2013 at 6:18 AM, Clark Pope cepop...@hotmail.com wrote: Date: Mon, 10 Jun 2013 18:00:21 -0400 From: ankan...@gmail.com To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer I have vmplayer virtual machine running on my computer as my system is GPT partition style and which is not taking dual boot of any release of ubuntu. I connect to an ethernet port to a USRP rx... and do a uhd_find_devices .. it says no device found.. although I have a valid gnuradio distro +uhd on my computer and it works fine when I am not using the USRP though.. Could it be because of the vm that I am using? Please suggest what do I need to do!! this is my eth0 config- eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39419 errors:0 dropped:0 overruns:0 frame:0 TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB) Interrupt:19 Base address:0x2000 This shows up when I am doing my firmware update- ankan@ubuntu :~/Downloads/uhd-images_003.005.001-release/share/uhd/images$ usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin --fpga usrp_n200_r3_fpga.bin --auto_reboot linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b Searching for USRP N2XX with IP address 192.168.10.3. Error: No USRP N2XX found. my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same ethernet sw -Regards, Ankan Roybardhan University of Florida. You're sure its not at the default address 192.168.10.2? Don't know if you have the same problem but I use a USB to GigE adapter from vmware player and I found that it ONLY works if I boot the VM with the interface that is connected to the USRP as the only active network connection. I can enable the network interface to the host OS after I boot and it still works but for some reason if the VMnetX interfaces are active at boot it messes up the ability to find the USRP. -Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Regards Karan Talasila ___ 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] Problem with all the functionalities (uhd_fft, gnuradio-companion etc) after installing gr-gras
On 06/11/2013 11:42 AM, Jay Prakash wrote: Hi! Today I reinstalled using gr-gras and gr-extra. But now there is some volk problem. UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam * Using Volk machine: sse4_2_32_orc ASSERT FAIL /home/electron/Downloads/gras/lib/gras_impl/output_buffer_queues.hpp:140 total_idle_times[i] = (time_now() - _init_time) terminate called after throwing an instance of 'std::runtime_error' what(): ASSERT FAIL total_idle_times[i] = (time_now() - _init_time) Aborted* Help me out. Volk is fine, I think its an indication that the getclocktime monotonic is not working correctly, or I have some bad math involving the time. Thats just an assertion to check the the total time port i was idle was less than the total time the object has been in existence. Seems like a sane thing to assert on. For the quick fix, its totally fine to comment out that line. I wonder if clock_gettime(CLOCK_MONOTONIC, ts); is working for your system? And can you tell me what OS and version are you using? -josh Jay Prakash ___ 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] Volk error
On 06/11/2013 11:50 AM, Jay Prakash wrote: Running GRC files give following error after re-installation and update with gr-extras. Using Volk machine: sse4_2_32_orc The program 'python2.7' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 958 error_code 9 request_code 137 minor_code 8) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line This is definitely not a volk error. Can you say what application you tried to run that caused the error? -josh Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/ http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top ___ 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] Fwd: GRExtras with gnuradio 3.6.5
On 06/11/2013 12:29 PM, Marcus D. Leech wrote: On 06/11/2013 12:26 PM, Gonzalo Flores De La Parra wrote: I just installed gnuradio 3.6.5 and every works perfect, i observe a lot of new and useful blocks. Among that i can see grextras install on my gnuradio source directory, but i can't see the blocks Extras:.. on GRC. Do i need to install them apart or is it ok if a remove the directory and install grextras on my own? Thanks I don't think gr-extras currently builds properly, because it's missing gras, which is also now required for a proper build. To be clear, if you are looking to install grextras for use w/ precog for example, you need a gnuradio 3.6.4 and then to install gr-extras from this branch https://github.com/guruofquality/grextras/tree/grextras_v3.6 If you want to use the awesome blocks on this page: https://github.com/guruofquality/grextras/wiki/Blocks Just follow the directions here, and you get those gr-extras blocks and gnuradio, its all submoduled into this top level package: https://github.com/guruofquality/gras/wiki/Build -josh ___ 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] Volk error
On 06/11/2013 12:48 PM, Marcus D. Leech wrote: On 06/11/2013 12:41 PM, Josh Blum wrote: On 06/11/2013 11:50 AM, Jay Prakash wrote: Running GRC files give following error after re-installation and update with gr-extras. Using Volk machine: sse4_2_32_orc The program 'python2.7' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 958 error_code 9 request_code 137 minor_code 8) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line This is definitely not a volk error. Can you say what application you tried to run that caused the error? -josh I've seen this on an older Ubuntu with newish GR code. *ANY* flow-graph using wxGUI falls over with this error. Is it perhaps gl canvas related (I heard murmurs that there was a initialization issue from a previous OSX fix)? If you turn off the gl stuff does it start working? ~/.gnuradio/config.conf [wxgui] style=nongl ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRAS time assert error - was Volk error
On 06/11/2013 03:55 PM, Yogesh Dahiya wrote: Thanks that kind of worked for me it showed the gui for a while but then it stopped with following error : GRAS: The debug asserts are enabled. Created default thread pool with 4 threads. Using Volk machine: sse4_2_32_orc ASSERT FAIL /home/electron/Downloads/gras/lib/gras_impl/input_buffer_queues.hpp:156 total_idle_times[i] = (time_now() - _init_time) terminate called after throwing an instance of 'std::runtime_error' what(): ASSERT FAIL total_idle_times[i] = (time_now() - _init_time) So I dont completely understand the nature of the problem. If you give me some feedback, I think that its something pretty simple. Possibly an issuing with using the getclocktime CLOCK_MONOTONIC. Can you tell me your OS name and version, 32 or 64 bit? If you pull and rebuild, there is a unit test for the timer stuff, I wonder what the output verbose is. Can you run this in the build directory: tests/chrono_time_test_cpp_test.sh If you apply this diff and rebuild, I think that the additional prints will be very revealing: http://pastebin.com/xeBHFN5j -josh ___ 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] GRAS time assert error - was Volk error
On 06/11/2013 05:51 PM, Yogesh Dahiya wrote: the example i was trying on is : gnuradio/grc/examples/simple/variable_config.grc I commented the assert and rebuild the gras and its working fine with this example. But my uhd_fft is showing another error now : Traceback (most recent call last): File /usr/local/bin/uhd_fft, line 341, in module main () File /usr/local/bin/uhd_fft, line 337, in main app = stdgui2.stdapp(app_top_block, UHD FFT, nstatus=1) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 38, in __init__ wx.App.__init__ (self, redirect=False) File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 7978, in __init__ self._BootstrapApp() File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 7552, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 42, in OnInit self._max_noutput_items) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 64, in __init__ self.panel = stdpanel (self, self, top_block_maker, max_nouts) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 86, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File /usr/local/bin/uhd_fft, line 125, in __init__ self.scope.set_callback(fftsink_callback) AttributeError: 'fft_sink_c' object has no attribute 'set_callback' I was tracking 3.6.4git but it looks like it was missing some commits to add the callback to the nongl gui sinks. So I pulled in 3.6.4.2 which had these commits. Should be good if you update git pull origin master git submodule update -josh On Wed, Jun 12, 2013 at 2:55 AM, Yogesh Dahiya yogeshd2...@gmail.comwrote: After applying the diff : name = throttle i = 0 total_idle_times[i] = 20344984 time_now() = 122002822 _init_time = 1984664495 ASSERT FAIL /home/electron/Downloads/gras/lib/gras_impl/input_buffer_queues.hpp:164 total_idle_times[i] = (time_now() - _init_time) terminate called after throwing an instance of 'std::runtime_error' what(): ASSERT FAIL total_idle_times[i] = (time_now() - _init_time) So it seems there is problem with time function On Wed, Jun 12, 2013 at 2:00 AM, Yogesh Dahiya yogeshd2...@gmail.comwrote: I have ubuntu 11.10 32 bit system output of the unit test is Running 1 test case... t0 1804958425 t1 2805093589 delta_time 1.00014 *** No errors detected On Wed, Jun 12, 2013 at 1:38 AM, Josh Blum j...@joshknows.com wrote: On 06/11/2013 03:55 PM, Yogesh Dahiya wrote: Thanks that kind of worked for me it showed the gui for a while but then it stopped with following error : GRAS: The debug asserts are enabled. Created default thread pool with 4 threads. Using Volk machine: sse4_2_32_orc ASSERT FAIL /home/electron/Downloads/gras/lib/gras_impl/input_buffer_queues.hpp:156 total_idle_times[i] = (time_now() - _init_time) terminate called after throwing an instance of 'std::runtime_error' what(): ASSERT FAIL total_idle_times[i] = (time_now() - _init_time) So I dont completely understand the nature of the problem. If you give me some feedback, I think that its something pretty simple. Possibly an issuing with using the getclocktime CLOCK_MONOTONIC. Can you tell me your OS name and version, 32 or 64 bit? If you pull and rebuild, there is a unit test for the timer stuff, I wonder what the output verbose is. Can you run this in the build directory: tests/chrono_time_test_cpp_test.sh If you apply this diff and rebuild, I think that the additional prints will be very revealing: http://pastebin.com/xeBHFN5j -josh ___ 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] GRAS time assert error - was Volk error
time_now() = 122002822 _init_time = 1984664495 Well thats special, _init_time time_now... One possible explanation is that on this version, CLOCK MONOTONIC has a different monotonic count per thread. given that the tick count is also pretty small, I suspect this is the case. But not on the more recent versions of ubuntu. :-) I will have to do a little more research. But its safe to comment out the asserts. The times are just used for the status monitor to determine the downtime of a particular port. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test errors
On 06/11/2013 07:34 PM, Botany Dave wrote: ./volk/lib/test-all completes with no errors found. Any other suggestions would be very much appreciated. :-( Well, having the volk qa fail would have nicely narrowed it down. I guess that now its potentially ambiguous to blame volk. The good news, I think those tests are related. Can you report the OS name version, 32/64 bit? The version of gnuradio where the tests failed? -josh From: Josh Blum-2 [via GnuRadio] ml-node+s4n41904...@n7.nabble.com To: Botany Dave sd_wirel...@yahoo.com Sent: Monday, June 10, 2013 7:13 PM Subject: Re: make test errors Run volk/lib/test_all from the build dir If a kernel fails, it will tell you which one, start commenting out its implementations in the source dir volk/kernels/volk/volk_*.h until the test works. We narrow down suspect implementation and fix. -josh On 06/10/2013 09:57 PM, Dave L wrote: The CPU on the laptop is an Intel i3-2350M (64 bit). What steps should I take (or where can I learn how) to resolve the problem with Volk? Dave From: Tom Rondeau [hidden email] To: Botany Dave [hidden email] Sent: Monday, June 10, 2013 6:41 AM Subject: Re: [Discuss-gnuradio] make test errors On Thu, Jun 6, 2013 at 11:52 PM, Botany Dave [hidden email] wrote: I'm new to this, and I'm sure it will show... I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I followed the instructions at http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview and am getting errors on four modules when I run make test. They are: 86 - qa_fir_filter 91 - qa_freq__xlating_fir_filter 150 - qa_constellation_receiver 169 - qa_codec2_vocoder Here is the output of ctest -V -R qa for each of those modules. I'd really appreciate any guidance on how to resolve these failures. 86: Test command: /bin/sh /home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh 86: Test timeout computed to be: 9.99988e+06 86: .FF 86: == 86: FAIL: test_fir_filter_scc_001 (__main__.test_filter) 86: -- 86: Traceback (most recent call last): 86: File /home/dave/gnuradio/gr-filter/python/qa_fir_filter.py, line 262, in test_fir_filter_scc_001 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 74, in assertComplexTuplesAlmostEqual 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 47, in assertComplexAlmostEqual 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places 86: 86: == 86: FAIL: test_fir_filter_scc_002 (__main__.test_filter) 86: -- 86: Traceback (most recent call last): 86: Using Volk machine: avx_32_mmx 86: File /home/dave/gnuradio/gr-filter/python/qa_fir_filter.py, line 281, in test_fir_filter_scc_002 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 74, in assertComplexTuplesAlmostEqual 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 47, in assertComplexAlmostEqual 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places 86: 86: -- 86: Ran 11 tests in 0.035s 86: 86: FAILED (failures=2) 1/1 Test #86: qa_fir_filter ***Failed0.30 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.31 sec The following tests FAILED: 86 - qa_fir_filter (Failed) Errors while running CTest 91: Test command: /bin/sh /home/dave/gnuradio/build/gr-filter/python/qa_freq_xlating_fir_filter_test.sh 91: Test timeout computed to be: 9.99988e+06 91: 91: == 91: FAIL: test_fir_filter_scc_001 (__main__.test_freq_xlating_filter) 91: -- 91: Traceback (most recent call last): 91: File /home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py, line 412, in test_fir_filter_scc_001 91: self.assertComplexTuplesAlmostEqual(expected_data
Re: [Discuss-gnuradio] GRAS time assert error - was Volk error
On 06/11/2013 07:03 PM, Yogesh Dahiya wrote: Thanks Its working fine now after the update and commenting assert statement. I think I found the problem. The ticks calculation was using 32 bit math on a 32-bit platform because the type was unsigned long, so there was numeric overflow. The right casting seems to fix the issue. -josh On Wed, Jun 12, 2013 at 4:08 AM, Josh Blum j...@joshknows.com wrote: time_now() = 122002822 _init_time = 1984664495 Well thats special, _init_time time_now... One possible explanation is that on this version, CLOCK MONOTONIC has a different monotonic count per thread. given that the tick count is also pretty small, I suspect this is the case. But not on the more recent versions of ubuntu. :-) I will have to do a little more research. But its safe to comment out the asserts. The times are just used for the status monitor to determine the downtime of a particular port. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink
On 06/10/2013 09:43 AM, Sean Nowlan wrote: Do late packets always get dropped by the USRP? What happens if its buffers get filled up with samples, all of which are late? The stream args have a policy parameter. Also, these args can be set from a parameter in the USRP GRC blocks, as well as the constructor for the gr-uhd blocks themselves. This should be helpful: http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef -josh Marcus D. Leech mle...@ripnet.com wrote: L = late packet, there was a time on the packet which was time on device when There are two different cases for late packets happening. The first is that you haven't sent your packet far enough in advance to account for latency variations on the host. Unfortunately, on a general-purpose OS like Windows or Linux, latency variability can be extreme, and for long-running flow-graphs you might need to develop a good model to determine what the worst-case is and account for that. The second is that the clock on the USRP and the clock on the host will tend to drift apart over time, particularly if both of them are free running. So when you schedule timed bursts far enough in advance during the start of a session, it's entirely possible that after quite some time, the two clocks have drifted apart unfavourably in terms of allowing you to schedule things far enough in advance, relative to the USRP clock. PC clocks are *terrible* by themselves. They'll drift significant fractions of a second on a daily basis without any outside steering. The USRP clock, even free-running, is typically much, much better. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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] Detecting underflows with uhd_usrp_sink
Ok, makes sense. So lets say I scheduled 20 minutes of bursts (1 second period with 50/50 duty cycle) and I started the flowgraph 10 minutes late. With the next_burst policy, could I rely on the USRP to dutifully drop all late bursts? Are the packets dropped in the Ethernet buffer or does the TX sample buffer fill up first? If it's the latter The bursts will be dropped as they are consumed by the VITA deframer. This deframer sits between the TX buffering and the transmit DSP. So yes, there will be some amount of buffered samples in the device, which will need to be dropped. Anything that is due for transmission that is several orders of magnitude ethernet latency should probably stay in the host application. :-) case, my scenario implies that the TX buffer will have to be filled and emptied multiple times until there are no more late packets, and normal transmissions begin. This would happen at the sample rate times the number of samples sent. Because the DSP is upstream of the framer. The framer can drain samples out of the buffering at the rate of the FPGA clock, this is ~100Msps for the N210. -josh I suppose I'd also want to implement a message handler to drop the flood of L symbols before they get piped to STDERR/STDOUT. Do I have the right understanding of this process? Thanks! --sean P.S. -- Copying to USRP list since this could be relevant to people there. -josh Marcus D. Leech mle...@ripnet.com wrote: L = late packet, there was a time on the packet which was time on device when There are two different cases for late packets happening. The first is that you haven't sent your packet far enough in advance to account for latency variations on the host. Unfortunately, on a general-purpose OS like Windows or Linux, latency variability can be extreme, and for long-running flow-graphs you might need to develop a good model to determine what the worst-case is and account for that. The second is that the clock on the USRP and the clock on the host will tend to drift apart over time, particularly if both of them are free running. So when you schedule timed bursts far enough in advance during the start of a session, it's entirely possible that after quite some time, the two clocks have drifted apart unfavourably in terms of allowing you to schedule things far enough in advance, relative to the USRP clock. PC clocks are *terrible* by themselves. They'll drift significant fractions of a second on a daily basis without any outside steering. The USRP clock, even free-running, is typically much, much better. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test errors
Run volk/lib/test_all from the build dir If a kernel fails, it will tell you which one, start commenting out its implementations in the source dir volk/kernels/volk/volk_*.h until the test works. We narrow down suspect implementation and fix. -josh On 06/10/2013 09:57 PM, Dave L wrote: The CPU on the laptop is an Intel i3-2350M (64 bit). What steps should I take (or where can I learn how) to resolve the problem with Volk? Dave From: Tom Rondeau t...@trondeau.com To: Botany Dave sd_wirel...@yahoo.com Sent: Monday, June 10, 2013 6:41 AM Subject: Re: [Discuss-gnuradio] make test errors On Thu, Jun 6, 2013 at 11:52 PM, Botany Dave sd_wirel...@yahoo.com wrote: I'm new to this, and I'm sure it will show... I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I followed the instructions at http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview and am getting errors on four modules when I run make test. They are: 86 - qa_fir_filter 91 - qa_freq__xlating_fir_filter 150 - qa_constellation_receiver 169 - qa_codec2_vocoder Here is the output of ctest -V -R qa for each of those modules. I'd really appreciate any guidance on how to resolve these failures. 86: Test command: /bin/sh /home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh 86: Test timeout computed to be: 9.99988e+06 86: .FF 86: == 86: FAIL: test_fir_filter_scc_001 (__main__.test_filter) 86: -- 86: Traceback (most recent call last): 86: File /home/dave/gnuradio/gr-filter/python/qa_fir_filter.py, line 262, in test_fir_filter_scc_001 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 74, in assertComplexTuplesAlmostEqual 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 47, in assertComplexAlmostEqual 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places 86: 86: == 86: FAIL: test_fir_filter_scc_002 (__main__.test_filter) 86: -- 86: Traceback (most recent call last): 86: Using Volk machine: avx_32_mmx 86: File /home/dave/gnuradio/gr-filter/python/qa_fir_filter.py, line 281, in test_fir_filter_scc_002 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 74, in assertComplexTuplesAlmostEqual 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 86: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 47, in assertComplexAlmostEqual 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places 86: 86: -- 86: Ran 11 tests in 0.035s 86: 86: FAILED (failures=2) 1/1 Test #86: qa_fir_filter ***Failed0.30 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.31 sec The following tests FAILED: 86 - qa_fir_filter (Failed) Errors while running CTest 91: Test command: /bin/sh /home/dave/gnuradio/build/gr-filter/python/qa_freq_xlating_fir_filter_test.sh 91: Test timeout computed to be: 9.99988e+06 91: 91: == 91: FAIL: test_fir_filter_scc_001 (__main__.test_freq_xlating_filter) 91: -- 91: Traceback (most recent call last): 91: File /home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py, line 412, in test_fir_filter_scc_001 91: self.assertComplexTuplesAlmostEqual(expected_data, result_data[-20:], 5) 91: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 74, in assertComplexTuplesAlmostEqual 91: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 91: File /home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py, line 47, in assertComplexAlmostEqual 91: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 91: AssertionError: (-0.00775564694777+0.0437113791704j) != (nan+nanj) within 5 places 91: 91: == 91: Using Volk machine: avx_32_mmx 91: FAIL: test_fir_filter_scc_002 (__main__.test_freq_xlating_filter) 91:
Re: [Discuss-gnuradio] Detecting underflows with uhd_usrp_sink
On 06/08/2013 02:26 PM, Juha Vierinen wrote: Hi, I've recently been working with a coded CW radar system that just loops over a fairly long IQ vector. It works all fine for a while, but after a few days, the transmission timing has drifted away from where it should be. I'm comparing the leading edge of the transmit waveform with the PPS provided to the USRP to detect drifting of the waveform. I'm wondering what could cause this. While the drifting occurs both when I see the letters U and L, and sometimes when I don't see them at all (this is correlated with the GPSDO losing lock). U = underflow (not fed enough samples to device which causes a gap in transmit) L = late packet, there was a time on the packet which was time on device when First of all, is there any way to ask the uhd_usrp_sink if there have been overflows or underflows that cause a need for resyncronizing? There is actually an async usrp block in gr-uhd that can post these indications to a gr msg queue. Second, what would be the optimal method to implement a continuously repeating IQ vector fed to a uhd_usrp_sink block that needs to stay in sync? On receive, sample counting works, so I would assume this to be the case also on receive. Perhaps you could react to the async indications and reset some upstream logic. -josh juha ___ 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] Error installing Gras
On 06/08/2013 10:27 PM, Yogesh Dahiya wrote:
I am trying to build gras but stuck with following error:
-- Found SWIG: /usr/bin/swig (found version 1.3.40)
-- Found PythonLibs: /usr/lib/libpython2.7.so
CMake Error at python/gras/CMakeLists.txt:9 (include):
include could not find load file:
GrSwig
CMake Error at python/gras/CMakeLists.txt:10 (include):
include could not find load file:
GrPython
did'nt find any solution
Those files should be in ${GRAS_SOURCE_DIR}/PMC/cmake/Modules
Does that directory exist for you? Did you follow the build
instructions, the submodule commands are very important for fetching all
the code. Thats my guess:
https://github.com/guruofquality/gras/wiki/Build#get-the-source-code
-josh
___
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] Error installing Gras
Those files should be in ${GRAS_SOURCE_DIR}/PMC/cmake/Modules
Does that directory exist for you? Did you follow the build
instructions, the submodule commands are very important for fetching all
the code. Thats my guess:
https://github.com/guruofquality/gras/wiki/Build#get-the-source-code
-josh
So I have a helpful error message macro for this reason, but it looks
like it wouldnt have been triggered since the submodules default to
empty directories in a fresh checkout. This fixes the error message:
https://github.com/guruofquality/gras/commit/953acfde47963f5ef3da2940d0d02c114127d701
-josh
___
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] How to save/read sc8 format to/from file and convert it to complex float 32?
On 06/06/2013 06:38 AM, Rickard wrote: Hi gurus, - Which is the simplest way, preferably directly in grc, to compactly save 8bit I/Q data (sc8) from an UHD source to a file instead the of the standard format complex float 32 (which is 4 times larger) ? - Then also, how to convert received and saved sc8 data to the normal complex float 32 in grc? A block that implements this conversion w/ a configurable scalar would be ideal. But there may not be such a direct block: there are float to char, char to float converters. And you can use this with complex to/from float and vector to/from streams block to get the two lanes of data into one. -josh The reason is that I want to take advantage of the sc8 reduced precision by reducing the file size when storing received data to file. That is, not only halve the bandwidth over the wire (compared to sc16) but also reduce the file size when storing. Or is there alternative and better ways to accomplish this when receiving and saving raw 8 bit I/Q data? In GRC I see its possible to select the output format complex int 16, instead of the standard complex float 32, but I don't find how to process or interpret this format further (e.g. saving, reading, converting to complex float 32, etc). Thanks, Rickard ___ 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] GNU Radio Companion isn't aware of custom pythonpath(s)
On 06/06/2013 02:54 PM, Arturo Rinaldi wrote: I bumped into a strange issue in the past few days. When i launch GRC by the desktop link generated, the program itself isn't aware of my custom pythonpath set in the .bashrc settings file. I tried to modify the desktop link also by checking the option to *launch the program in a terminal* and putting into the blank space : /export PYTHONPATH=$PYTHONPATH:my-custom-path \ gnuradio-companion/ but without any results. I have never experienced this issue with the past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio 3.6.4.1. The only way it works is by making a script and launch it from my desktop. No issues if i launch GRC from shell, after all the pythonpath is embedded in the launched shell. thanks in advance for helping me. I can confirm that this is an issue. There may need to be a helper gnuradio-companion script that sets the env vars and then calls the actual python script. The gnuradio-grc.desktop would call this script instead. Not sure of a better way to do that. -josh Kind Regards, Arturo ___ 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] About sample lost
On 06/04/2013 03:25 AM, Zan Li wrote: Dear list, Now I meet a problem about counting all the input samples. I hope I can get some assistant from here. The problems are as follows, In one of my blocks, I want to count all the consumed input samples to get the timestamp of the received packet. I have used GPS to synchronize two usrps and therefore for the same packet the two usrp should consume the same amount of samples in this block from the beginning of the stream. At the very beginning, it works fine but after it works for a while the timestamp in one usrp will lost 8192 samples (8192 samples less than the other one). I have checked it is the same as the maximum output buffer of one block. I want to ask if it is possible that because the block can not process the sample as fast as the output from the previous block, one buffer of samples are lost. BTW I did not find any indicator of overflow from uhd when I run the code. Any suggestions would be appreciated. Any thoughts on my previous reply? http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg42356.html Also, there is an API to get the number of samples consumed. In your work function, you can all this-items_consumed(input_port_index). Just in case you didnt know, so you do not have to do a manual count, the scheduler will do this for you. Also, what do you mean by timestamp in one usrp will lost 8192 samples? The timestamps are typically tagged on the first sample and only resent when there is device overflow. So I am curious how you are determining lost samples. Are you correlating on a shared pulse transmitted into both USRPs? -josh Best regards Zan ___ 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] Test Results on gnuradio-3.6.5 exe extensions
200: import scipy 200: ImportError: No module named scipy 1/1 Test #200: qa_ofdm_txrx .***Failed0.42 sec Wouldnt worry about it. I wonder if scipy is an intentional dependency for the QA test though? 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.49 sec The following tests FAILED: 200 - qa_ofdm_txrx (Failed) Errors while running CTest UNQUOTE Regarding exe extensions, i am seeing them only with python examples in gr_xxx folders(such as graudio, gr-digital etc.) and not with other binary executables in other folders. Window showing the files even display colour icons. They are marked program and when i try open them with click, it tires to open with archive manager and fails to open. Here is the line that makes that extension. At least on some windows installs, the default behaviour is to open with the python interpreter: http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrPython.cmake#n207 -josh ___ 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] About sample lost
On 06/03/2013 01:10 PM, ÀîÔÞ wrote: Dear list, Now I meet a problem about counting all the input samples. I hope I can get some assistant from here. The problems are as follows, In one of my blocks, I want to count all the consumed input samples to get the timestamp of the received packet. I have used GPS to synchronize two usrps and therefore for the same packet the two usrp should consume the same amount of samples in this block from the beginning of the stream. At the very beginning, it works fine but after it works for a while the timestamp in one usrp will lost 8192 samples (8192 samples less than the other one). I have checked it is the same as the maximum output buffer of one block. I want to ask if it is possible that because the block can not process the sample as fast as the output from the previous block, one buffer of samples are lost. BTW I did not find any indicator of overflow from uhd when I run the code. You shouldnt see any overflow within the scheduler, which is full backpressured, but perhaps from the USRP... However, 8192 (fc32 samps) corresponds to a default memory chunk size for buffers in the gnuradio scheduler, and not an MTU size packet from the USRP. Can you think of a reason in your code that this might happen? Because 8192 sounds like an entire work function call worth of samples unaccounted for, not an overflow. -josh Any suggestions would be appreciated. Best regards Zan ___ 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] Mechanism to build in command line help into the flowgraph?
On 06/03/2013 12:26 PM, Monahan-Mitchell, Tim wrote: I have testers that might not see the graphical version of the flowgraph they are testing. To them, they run the flowgraph on the command line, passing in various parameter values using the Short IDs set up in the original flowgraph and built by GRC for the target. Is there a way, for example, to pass in -h or similar and the flowgraph spits out help text documentation and exits? I would want this to be created without manually changing the files that GRC produces when it builds the flowgraph. See the parameter block in GRC -josh Thanks in advance, Tim Monahan-Mitchell ___ 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] Mechanism to build in command line help into the flowgraph?
The above text would be entered someplace on the flowgraph in GRC, like maybe the description field in the Options block. Then output of that text to stdout is triggered by a selectable Short ID from a parameter block on the flowgraph, or maybe is always hard coded to an option like --help? So you should get the --help for free when the flow graph is generated. I think whats missing for your case is that the parameter block doesnt have a entry field for a custom help message per parameter. I would add a help entry field for the parameter.xml block and the support in the flowgraph.tmpl for the help message. Right now the help message is autogenerated I think to just say something generic/ -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Here's an interesting bug
On 05/30/2013 11:31 PM, Marcus D. Leech wrote: That I suspect will be hard to fix. Its kind of random between releases of pygtk, but its basically known behaviour. You need X to import gtk. Perhaps, the grcc could be modified to import only the non gui python builder classes. I think the two (gui and non gui) are not too badly interwoven. -josh If you run grcc in something that doesn't have access to the X display, it barfs: Traceback (most recent call last): File /usr/local/bin/grcc, line 27, in module from gnuradio.grc.python.Platform import Platform File /usr/local/lib64/python2.7/site-packages/gnuradio/grc/python/Platform.py, line 23, in module from .. gui.Platform import Platform as _GUIPlatform File /usr/local/lib64/python2.7/site-packages/gnuradio/grc/gui/Platform.py, line 20, in module from Element import Element File /usr/local/lib64/python2.7/site-packages/gnuradio/grc/gui/Element.py, line 20, in module from Constants import LINE_SELECT_SENSITIVITY File /usr/local/lib64/python2.7/site-packages/gnuradio/grc/gui/Constants.py, line 22, in module import gtk File /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py, line 64, in module _init() File /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py, line 52, in _init _gtk.init_check() RuntimeError: could not open display ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] stream_to_vector and numpy vectors
On 05/29/2013 02:31 PM, vegihat vegihat wrote: hello, i want to write a simple energy detector without using c++, only existence blocks and the numpy lib So far, i have the following graph usrp_source - head - stream_to_vector could i read the values from stream_to_vector and write them to a numpy-vector? is it possible? Yes. Rather than use the stream to vector, create a python block. This block's work function will get called with the sample data from head as a numpy array. -josh ___ 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] bug with gain setting in usrp1?
On 05/29/2013 11:53 PM, Wolfgang Buesser wrote: Hmm, I don't think so: What I apply to board A ADC0 shows up on scope0, and what I apply to board A ADC1 shows up on scope1, so there are definitely two different ADCs involved. Looking at the scope traces they are connected as set by the line self.uhd_usrp_source_0.set_subdev_spec(A:A A:B, 0) i.e: DDC-channel0, input I from board A, ADC0 DDC-channel0, input I from board A, ADC1 Both Q-inputs to GND It appears, that the gain settings are somehow skewed up. I am sure that the gain for both ADCs attached to same LFRX-board got be set individually. Do I need a special FPGA code? The good news is that there is already software control for this. The bad news is, there isnt an API to expose this edge case of ADC as two unrelated streams with individual gain. See: https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/usrp1/usrp1_impl.cpp#L464 -josh Wolfgang Those are two DDC channels, derived from the same physical, analog, hardware and ADC. The LFRX itself has no gain-setting device, but the ADC does, so when you set the gain on the ADC, you're setting the gain for both DDC-derived channels. on May 29, 2013, Wolfgang Buesser wolfgang.bues...@web.de wrote: Hi, I am having problems with the gain-settings on the RX-channels of usrp1 My USRP1 is populated with 2 LFRX and 2 LFTX. I want to use 2 DDC-channels each connect to one 2 ADC of LF-RX-Board A. I have generated the following code with grc. When apply a signal of roughly 11MHz I see the mixed signals on each scope. The relation to the inputs is o.k. The gain-settings are however not as I expect: self.uhd_usrp_source_0.set_gain(6, 1) affects both channels while self.uhd_usrp_source_0.set_gain(6, 0 has no effect. From what I rememeber that was different in the pre-uhd-times. Any hint, on how I can set the gains for both channels independently? Thanks Wolfgang ___ 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] Announcing GrExtras family of JIT blocks - clang + llvm, orc, opencl
Hey all, The JIT Blocks in GrExtras just keep growing (now its a family): https://github.com/guruofquality/grextras/wiki/Blocks#wiki-awesome-jit-blocks * I mentioned the OpenCl block in a previous email: https://github.com/guruofquality/grextras/wiki/Opencl * There is now and ORC block as well. One can specify SIMD kernels in the ORC high level assembly language. The block will compile at runtime a routine optimized for the SIMD units within your CPU: https://github.com/guruofquality/grextras/wiki/Blocks#wiki-orc-block * And my new favorite (this one took me all weekend). The clang block! With this block you can write full C++ blocks without bothering with compilers, swig, cmake, modtool... Simply feed the block with C++ source and options; and the block is compiled and constructed at runtime. There is even a GRC wrapper for this block which exposes simple options and access to properties. One could make an entire flow graph with nice fast C++ JIT blocks and not touch any compilers :-) For dependencies, build instructions, and basic usage, see: https://github.com/guruofquality/grextras/wiki/Clang Enjoy the blocks! -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Performing callback function in GRC
On 05/28/2013 04:32 AM, Florian Schlembach wrote: Perhaps it would work better to treat the input as one variable. Use a tuple of numbers instead. You can make a text entry widget w/ converter type Evaluate. The callback would probably look more like this: callbackset_user_register(*\$user_reg_args)/callback -josh Thanks, thats already a good solution. However, I would like to select the user_reg_addr from another Checkbox Widget (e.g. to select a specific function). Assuming an evaluated $user_reg_args by [user_reg_addr,1], it always executes the callback on an update of user_reg_addr, which is kinda obvious. Thus, I always need to type in the value *and* the address into the text field by hand. Although this would be acceptable, it is not so handy. I am wondering if there is some sort of a conditional execution of the callback in the python-xml framework? I guess at some point, the builtin GRC functionality isnt smart enough. I think you could obtain this with some custom python code. For example, howabout a custom xml for grc that calls self.my_usrp_source_block_id.set_user_reg, but all caches the address so it doesnt give extra calls when the user makes gui changes. You can put pretty much anything inside those make/make tags, so I am imagining a class with a callback that does the right logic. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
