Re: [Discuss-gnuradio] GRC control over flowgraph programs
Hmm, seems like there is no available CPU for the GUI to respond, maybe try lowering your frame rate for fft sink. I have no idea what version of gnuradio or grc you are running. GRC is bundled with gnuradio development trunk and gnuradio 3.2 release branch. Install one of those gnuradio versions if you have not already done so. If you still have the trouble, send the generated python code so we can all take a look. -Josh davek wrote: this has been discussed before, but i cant find the solution... im wondering if there is options i need to pass to grc to make it more resposive while running. A simple grc flowgraph connecting a USRP source to a FFT sink works fine, but is unresponsive to any input, eventually ubuntu will pop up a NOT RESPONDING windows and let me kill the process. when i run usrp_fft.py It works fine, letting me change options, gain and able to close. What do i need to add to my simple GRC program to allow user input? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Passing file descriptors via SWIG
Hi,
following
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-02/msg00400.html,
I tried connecting two processes with a FIFO using gr.file_descriptor_*.
However, I can't seem to pass the file descriptor from the Python to the
C++ domain. This is the error message I get:
gr_file_descriptor_sink: Bad file descriptor
This is the code (pipe1 was created by using 'mkfifo pipe1'):
Source-File:
SNIP
from gnuradio import gr
class sig_source(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
src = gr.sig_source_f(8000, gr.GR_SIN_WAVE, 2000, 1.0)
head = gr.head(gr.sizeof_float, 8000)
print Opening pipe...
fid = open('pipe1', 'wb')
print Done. fileno: , fid.fileno()
sink = gr.file_descriptor_sink(gr.sizeof_float, fid.fileno())
self.connect(src, head, sink)
if __name__ == '__main__':
try:
sig_source().run()
except KeyboardInterrupt:
pass
SNIP
Sink:
SNIP
from gnuradio import gr
class sig_sink(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
print Opening pipe...
fid = open('pipe1', 'rb')
print Done. fileno: , fid.fileno()
src = gr.file_descriptor_source(gr.sizeof_float, fid.fileno())
self.sink = gr.vector_sink_f()
self.connect(src, self.sink)
if __name__ == '__main__':
try:
sigsnk = sig_sink()
sigsnk.run()
print sigsnk.sink.data()[0:4]
except KeyboardInterrupt:
pass
SNIP
When I start both scripts, this is what I get:
Opening pipe...
Done. fileno: 3
file_descriptor_source[read]: Bad file descriptor
on both the write and read ends of the pipe. This does work when I open
the pipe with gr_file_sink, but then I have to think about the
buffering.
Has anyone ever done this and could drop me some example code that
works? I'd really appreciate it...
Cheers
MB
--
Dipl.-Ing. Martin Braun Phone: +49-(0)721-608 3790
Institut fuer Nachrichtentechnik Fax: +49-(0)721-608 6071
Universitaet Karlsruhe (TH) http://www.int.uni-karlsruhe.de/
pgpc7gGYy1rU4.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: cannot import name packbits
On Fri, Mar 13, 2009 at 07:39:07AM +0100, Jay Kumar wrote: Hello , I have completely installed Gnuradio-3.1.3 on RHEL4.Even I have uploaded the firmware on the usrp.But when i was trying to run usrp_fft.py i got the attribute key error.After searhing through all forum i gor to know that Python 2.3 could not update the numpy's directories.So i downgraded Numpy to 1.0.4 and now i m getting the following errors:- File ./usrp_fft.py, line 23, in ? from gnuradio import gr, gru File /usr/lib/python2.3/site-packages/gnuradio/gru/__init__.py, line 37, in ? exec from gnuradio.gruimpl.%s import * % (f,) File string, line 1, in ? File /usr/lib/python2.3/site-packages/gnuradio/gruimpl/gnuplot_freqz.py, line 28, in ? import numpy File /usr/lib/python2.3/site-packages/numpy/__init__.py, line 93, in ? import add_newdocs File /usr/lib/python2.3/site-packages/numpy/add_newdocs.py, line 9, in ? from lib import add_newdoc File /usr/lib/python2.3/site-packages/numpy/lib/__init__.py, line 18, in ? from io import * File /usr/lib/python2.3/site-packages/numpy/lib/io.py, line 16, in ? from _compiled_base import packbits, unpackbits ImportError: cannot import name packbits I am badly stucked.Plz help me out. Thanks It appears that something is wrong with your numpy installation. Try this: $ python import numpy If you see the error when doing this, there is something wrong with your numpy installation. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can a host control an USRP1 and an USRP2 with the same clock?
However, if you buy some more hardware, you can drive both USRP2 and USRP1 from the same clock. The USRP2 takes a 10 MHz standard, but the USRP2 needs a 64 MHz clock. You can actually use a common reference between the USRP1 and USRP2 by modifying some of the USRP2 firmware code so that it can take a reference other than 10MHz. See http://gnuradio.org/trac/wiki/USRP2GenFAQ#Doestheexternalfrequencyreferencehavetobe10MHzCanIuse100MHz This code is located in usrp2/firmware/lib/clocks.c -Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Passing file descriptors via SWIG
On Fri, Mar 13, 2009 at 07:09:26AM -0700, Eric Blossom wrote: On Fri, Mar 13, 2009 at 01:49:31PM +0100, Martin Braun wrote: Hi, following http://lists.gnu.org/archive/html/discuss-gnuradio/2009-02/msg00400.html, I tried connecting two processes with a FIFO using gr.file_descriptor_*. However, I can't seem to pass the file descriptor from the Python to the C++ domain. This is the error message I get: gr_file_descriptor_sink: Bad file descriptor This is the code (pipe1 was created by using 'mkfifo pipe1'): The python file object, fid, is going out of scope, and thus the underlying file is being closed. Try self.fid = open(...) Thanks, Eric, that helped. If anyone ever tries doing this: Both Python and gr_file_descriptor_sink will try to close the file, resulting in a warning. If you ask me, gr_file_descriptor_* should not close the file in the destructors - if anyone's using these blocks, they should usually know what they're doing. Plus, to use a gr_file_descriptor, you need to open the file yourself beforehand, the closing should thus happen in the same scope. I suggest kicking the close() lines from gr_file_descriptor*::~gr_file_descriptor*. Just my two Euro-cents... MB -- Dipl.-Ing. Martin Braun Phone: +49-(0)721-608 3790 Institut fuer Nachrichtentechnik Fax: +49-(0)721-608 6071 Universitaet Karlsruhe (TH) http://www.int.uni-karlsruhe.de/ pgp406vD22RYh.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ASK Modulation Examples
I need to obtain, or write a block for ASK modulation. I am a little lost as to how to begin this. I understand ASK modulation, and have implemented a simulation of it in LabVIEW. Does anybody have an ASK mod/demod block and/or some examples that I could look at that might be similar or helpful? Thanks, Bill H. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] extract timestamp data / The Plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The details on all of this still need to be flushed out, but this is the basic idea. To all: * Do you think that this would allow you to easily build MACs or other packet based things in GNU Radio? Assume the USRP and USRP2 blocks are doing something sensible about the new attributes. * Do you think you could build what you desire on top of these extensions? * Any other comments, questions, yeah-but's... Eric I'm not working on MAC's at the moment (or more accurately, my work right is only concerned with receiving packets, not sending), but certainly being able to pass along the metadata would be a nice feature. For the moment, I'm able to do what I want with my afore-mentioned custom source block (where only the source block has access to the timestamps), but I can see situations (in the future) in which I'd like to have that info passed along through the flowgraph. I recall some discussion with the m-block's being concerned with the performance of the PMT data types - can you address that? Has that been resolved/can resolved via some technique/won't be an issue with next year's CPU's/etc.? Thanks, Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJuojtgfOzzR5bXIgRAsyrAKCpFukM05kNMqwY2w178RVpeV45vgCfdRS7 H7cTgsWGJQbTN55LeQkiR6Y= =B+CK -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] extract timestamp data / The Plan
Eric, Yes I believe this would tremendously facilitate MAC development within GNU Radio. I have recently begun working on integrating a configurable MAC layer to be used with GNU Radio and a USRP board. I am using this for underwater acoustics where the propagation delay is very high and speed is not much of an issue. So my MAC layer is outside of GNU Radio. However with these enhancements that would no longer be necessary, and I imagine it would be much easier to do within GNU Radio. Thanks for all the great work! Dustin Torres --- On Fri, 3/13/09, Eric Blossom e...@comsec.com wrote: From: Eric Blossom e...@comsec.com Subject: Re: [Discuss-gnuradio] extract timestamp data / The Plan To: Pham, Thanh thanh.p...@lmco.com Cc: Discuss-gnuradio@gnu.org Date: Friday, March 13, 2009, 7:53 AM On Tue, Mar 10, 2009 at 01:51:15PM -0600, Pham, Thanh wrote: Hello, I got complex samples from the usrp2 from usrp2.source32fc. Is there a gnu radio class to extract the time stamp from the data coming in from the usrp2? I read on archive that the timestamp is included in the Ethernet frame but I don't see any help on how to extract it. Has anyone attempted to extract timestamp from the usrp2 data frame ? I would appreciate if someone has an example or something I can look at. Thanks! Thanh There currently isn't a way to get at the timestamp (which is contained in the usrp::rx_metadata structure), using the gr-usrp2 interface. Right now we're in the midst of squashing bugs and sorting through the backlog of patches in order to get the 3.2 release out the door. As soon as that is done, we're going to start on some enhancements to GNU Radio that I think will give you what you're looking for. There are two distinct but related features: The first is designed to uniformly allow blocks to have a packet based or message passing interface, similar to what we attempted with the message block (m-block) code. We have found that although the m-block code makes certain classes of problems easy to solve, it was hard to interface to the existing data flow blocks. The new plan is to provide all blocks (including hier_blocks) with the ability to send and receive messages containing packetized data. The messages will use the PMT data types, similar to how it was done with m-blocks. All blocks will have a message receiver (aka port) (and there may be message receivers that are not associated with blocks), that by default discards anything sent to it. The organization will be much less rigidly structured than m-blocks are. It'll be closer to Erlang's model of the universe: if you've got access to a message receiver (aka port), you can send to it. We will come up with some conventions on representing payloads and metadata, but all will be built from PMT types. We will most likely extend the PMT types to add a non-mutable tuple type, similar to Python and Erlang. Thus we will have a common base class for all blocks, and blocks may have input and output streams (like they do now) or the ability to send and receive messages, or both. The second feature will allow us to attach (key, value) attributes to a position (sample offset) in a stream. Schematically one could imagine something like (Key=Timestamp, Value=, Offset=) being used to indicate the position and FPGA timestamp associated with the sample that corresponds to the start of the underlying frame. By default, existing blocks would transparently propagate any attributes contained on their input streams to their output streams. Blocks that cared about the attributes could query their input streams to locate all (key, value, offset) tuples in the region of the stream that they are currently working on in their work method. Likewise, blocks could copy, add or delete attributes on their output streams. The details on all of this still need to be flushed out, but this is the basic idea. To all: * Do you think that this would allow you to easily build MACs or other packet based things in GNU Radio? Assume the USRP and USRP2 blocks are doing something sensible about the new attributes. * Do you think you could build what you desire on top of these extensions? * Any other comments, questions, yeah-but's... Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: do not able to find blks2.ofdm_mod in svn
thanks Josh. sorry for keep asking, but I was wander that how do I update my GRC block only? or do I have to download gnuradio whole package and do the same process to update my GRC block ./bootstrap ./configure make make check make install thanks and regards tushar On Thu, Mar 12, 2009 at 2:53 PM, Josh Blum j...@joshknows.com wrote: hi tusear, I added the OFDM mod and demod to the Modulators category in the GRC gui. However, there are no OFDM examples for GRC. A quick loopback test to let you know that the blocks work: signal source - ofdm mod - ofdm demod - throttle - scope sink or fft sink Tushar Patel wrote: Hi jose I try to find out ofdm block but it want appear there. May by I am looking at wrong place. here the path where i looked http://gnuradio.org/svn/gnuradio/trunk/grc/examples/ thanks for guidance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: do not able to find blks2.ofdm_mod in svn
Go into your build directory and run the command svn up. That command ensures that you have the most recent code. The run make sudo make install. If you only want to update GRC, then cd into the grc directory first, then run the commands above. Tushar Patel wrote: thanks Josh. sorry for keep asking, but I was wander that how do I update my GRC block only? or do I have to download gnuradio whole package and do the same process to update my GRC block ./bootstrap ./configure make make check make install thanks and regards tushar On Thu, Mar 12, 2009 at 2:53 PM, Josh Blum j...@joshknows.com wrote: hi tusear, I added the OFDM mod and demod to the Modulators category in the GRC gui. However, there are no OFDM examples for GRC. A quick loopback test to let you know that the blocks work: signal source - ofdm mod - ofdm demod - throttle - scope sink or fft sink Tushar Patel wrote: Hi jose I try to find out ofdm block but it want appear there. May by I am looking at wrong place. here the path where i looked http://gnuradio.org/svn/gnuradio/trunk/grc/examples/ thanks for guidance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py buffer crash
Hi Eric,
Sorry I was busy yesterday and today so I got to debug just now.
I did what you told me to then use (gdb) attach $pid. then (gdb)
continue. the process seems slowed down quite a lot and almost halt (but it
shouldn't be). in this case I can't make the process crash and backtrace in
gdb. maybe I did something wrong that made the process doesn't crash... I'm
a newbie of gnu radio and gdb
Yanyan
Eric Blossom wrote:
On Thu, Mar 12, 2009 at 10:01:28AM -0700, yyzhuang wrote:
Hi Eric,
The command line: sudo ./tunnel.py --freq 2.44G --bitrate 500k -v (is
bitrate has something to do with buffer?)
I installed GNU Radio from here: svn co
http://gnuradio.org/svn/gnuradio/branches/releases/3.1 gnuradio
Thanks.
I never had that buffer problem before I moved the 2 boxes to another lab
(from computer science lab to ee lab). Will it because of the higher
interference in the busier channel that caused too many packets being
queued
in the buffer, and caused the buffer over flow?
No, the error message most likely indicates an internal error in one
of the blocks. If you can reproduce the problem and can grab a gdb
backtrace when it happens, that would be very helpful in figuring out
which block has the problem.
Here's how to use gdb with python. Add the code below to the top of
tunnel.py, after all the imports.
Debugging with gdb
If your block isn't working, and you can't sort it out through python
test cases or a few printfs in the code, you may want to use gdb to
debug it. The trick of course is that all of GNU Radio, including your
new block, is dynamically loaded into python for execution.
Try this: In your python test code, after the relevant imports, print
out the process id and wait for a keystroke. In another window run gdb
and tell it to attach to the python process with the given process
id. At this point you can set breakpoints or whatever in your code. Go
back to the python window and hit Enter so it'll continue.
#!/usr/bin/env python
from gnuradio import gr
# insert this in your test code...
import os
print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
raw_input ('Press Enter to continue: ')
# remainder of your test code follows...
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp22470731p22507897.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] extract timestamp data / The Plan
On Fri, Mar 13, 2009 at 11:25:17AM -0500, Douglas Geiger wrote: The details on all of this still need to be flushed out, but this is the basic idea. To all: * Do you think that this would allow you to easily build MACs or other packet based things in GNU Radio? Assume the USRP and USRP2 blocks are doing something sensible about the new attributes. * Do you think you could build what you desire on top of these extensions? * Any other comments, questions, yeah-but's... Eric I'm not working on MAC's at the moment (or more accurately, my work right is only concerned with receiving packets, not sending), but certainly being able to pass along the metadata would be a nice feature. For the moment, I'm able to do what I want with my afore-mentioned custom source block (where only the source block has access to the timestamps), but I can see situations (in the future) in which I'd like to have that info passed along through the flowgraph. Thanks for the data point. I recall some discussion with the m-block's being concerned with the performance of the PMT data types - can you address that? Has that been resolved/can resolved via some technique/won't be an issue with next year's CPU's/etc.? We've got some performance patches to apply and beyond that will do what it takes to ensure good performance for the PMT types. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] extract timestamp data / The Plan
On Fri, Mar 13, 2009 at 11:41:22AM -0700, Dustin Torres wrote: Eric, Yes I believe this would tremendously facilitate MAC development within GNU Radio. I have recently begun working on integrating a configurable MAC layer to be used with GNU Radio and a USRP board. Thanks. I am using this for underwater acoustics where the propagation delay is very high and speed is not much of an issue. So my MAC layer is outside of GNU Radio. However with these enhancements that would no longer be necessary, and I imagine it would be much easier to do within GNU Radio. Thanks for all the great work! You're welcome! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: not able to run grc
Josh Blum wrote: Tushar Patel wrote: Thanks Josh after typing all export I able to run GRC. Now my question is , in previous GRC, we got help like color- for float, complex, number, query for usrp board But Here I do not able to find such help, Usrp probe exists: http://gnuradio.org/trac/wiki/GNURadioCompanion#Execution And there are menu items for grc and usrp probe if your OS supports it: http://gnuradio.org/trac/wiki/GNURadioCompanion#InstallingIconsMimeTypeandMenuItems The keyboard short cuts are listed in the menus. Other short cuts are listed here: http://gnuradio.org/trac/wiki/GNURadioCompanion#UsageTips The color help menu, sorry, that got lost along the way. Most blocks have an output/input type that will tell you. I will add the color table back in somehow. In the meantime, blue=complex, red=float, green=int, yellow=short, purple=byte/char -josh Also how can i remove my previous version of gnuradio3.1.3, or no need to remove it. if you have the old build directory from 3.1.3, run sudo make uninstall this will also remove files that you want, so... then in your current gnuradio build directory, run sudo make install -Josh Hi Josh, I am facing the same problem as Tushar did. I am getting an error as follows: Traceback (most recent call last): File /usr/local/bin/grc, line 25, in module from gnuradio.grc.platforms.base.Constants import VERSION ImportError: No module named grc.platforms.base.Constants [r...@somya /]# I also tried the path solution which you mentioned in the earlier post, but it didn't worked for me. I had installed the latest version of GNU radio (gnuradio-3.2) and was trying to run GRC. Can you please help me for this. Also I was wondering that is it possible to see the source code associated with the flow graph that we make in GRC? or the source code of the specific block such as BPSK modulator? Thanks Regards, Somya Ajmera -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: not able to run grc
Hi Josh, I am facing the same problem as Tushar did. I am getting an error as follows: Traceback (most recent call last): File /usr/local/bin/grc, line 25, in module from gnuradio.grc.platforms.base.Constants import VERSION ImportError: No module named grc.platforms.base.Constants [r...@somya /]# I also tried the path solution which you mentioned in the earlier post, but it didn't worked for me. I had installed the latest version of GNU radio (gnuradio-3.2) and was trying to run GRC. Can you please help me for this. You have to set the PYTHONPATH. This is not a GRC problem, this is a gnuradio installation problem. I bet that if you try to run other gnuradio apps, you will see a similar problem. Read the part about the PYTHONPATH http://gnuradio.org/trac/wiki/FedoraInstall Also I was wondering that is it possible to see the source code associated with the flow graph that we make in GRC? or the source code of the specific block such as BPSK modulator? The generated code is in the same folder as your saved flow graph. By default, its called top_block.py Source code for modulators are here: http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/blks2impl Thanks Regards, Somya Ajmera ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
