On Mon, Feb 25, 2013 at 08:40:31PM +, Warren, Kevin M wrote:
1) A minor difficulty is that gr_modtool.py does not appear to be placing the
class definitions and the instantiation of the class object(s) in the proper
order. This was easy enough to remedy by hand.
Hi Kevin,
I assume you
It might be that you have some version mismatch, or i don't know how to
call that. Check inside of your _swig.i and see whether this MAGIC thig is
above include statement. That was problem in my case.
Gr_modtool generated something like this:
%include test_pkdt.h
GR_SWIG_BLOCK_MAGIC(test,pkdt);
This seems to have been confusing everyone,
so here's the answer:
== = 3.7 ==
In the 3.7-style module structure (which uses the include/MODULENAME/
directory and omits the module prefix from the file names), the correct
order is:
%include ...
GR_SWIG_BLOCK_MAGIC2(...)
This format is
On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau t...@trondeau.com wrote:
GNU Radio: now allowing you to shoot yourself in the foot!
We've identified a few versions of Boost that don't work well with GNU
Radio, 1.46, 1.47, and 1.52. A little while ago, I updated our cmake build
files to look for
Hi GNURADIOers,
I wanted to tell you that test for my block runs twice.
Namely, I designed block based on tagged_file_sink, which is able to store
some
additional samples before true tag.
I designed also test, but when I run it, it simply executes twice.
at the bottom of my qa file you can find
On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete oz9...@gmail.com wrote:
On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau t...@trondeau.com wrote:
GNU Radio: now allowing you to shoot yourself in the foot!
We've identified a few versions of Boost that don't work well with GNU
Radio, 1.46, 1.47,
Hi,
You can see which Boost version Cmake is finding for you by looking at
CMakeCache.txt in the top of the build directory. Check out the
Boost_library_LIBRARY and Boost_INCLUDE_DIR to see which ones
were found and are being used. Hopefully, it's finding the 1.48 version
that's
installed.
I assume you mean in the SWIG files? Or are you talking about something else?
The SWIG order bug was fixed in both the standalone and the master branch
version of gr-modtool.
Martin,
It's howto_swig.py that is generated following the out of tree module
tutorial (link in original post)
On Tue, Feb 26, 2013 at 7:17 AM, Nemanja Savic vlasi...@gmail.com wrote:
Hi GNURADIOers,
I wanted to tell you that test for my block runs twice.
Namely, I designed block based on tagged_file_sink, which is able to store
some
additional samples before true tag.
I designed also test, but when
On Tue, Feb 26, 2013 at 9:38 AM, Ralph A. Schmid, dk5ras
ra...@schmid.xxx wrote:
Hi,
You can see which Boost version Cmake is finding for you by looking at
CMakeCache.txt in the top of the build directory. Check out the
Boost_library_LIBRARY and Boost_INCLUDE_DIR to see which ones
were found
On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete oz9...@gmail.com wrote:
On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau t...@trondeau.com wrote:
GNU Radio: now allowing you to shoot yourself in the foot!
We've identified a
On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete oz9...@gmail.com wrote:
On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete oz9...@gmail.com wrote:
On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau t...@trondeau.com wrote:
GNU
On Tue, Feb 26, 2013 at 02:45:52PM +, Warren, Kevin M wrote:
Martin,
It's howto_swig.py that is generated following the out of tree module
tutorial (link in original post) downloaded from github. I see there's been a
new version posted within the past few hours.
If the swig file was
HI,
I am using tunnel.py command to setup a TCP/IP link between two usrp1. When i
try to use the command , i get this error
./tunnel.py
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-29-g3cb515f7
Traceback (most recent call last):
File ./tunnel.py, line 295, in module
main()
On Tue, Feb 26, 2013 at 5:21 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete oz9...@gmail.com wrote:
On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete oz9...@gmail.com wrote:
On Wed,
On Tue, Feb 26, 2013 at 1:12 PM, Alexandru Csete oz9...@gmail.com wrote:
On Tue, Feb 26, 2013 at 5:21 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete oz9...@gmail.com wrote:
On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue,
Hi,
My RFID communication system uses the following blocks. I can monitor the
signal output by rx module using self.connect(rx, rx_out). rx_out is a log
file generated by rx_out = gr.file_sink(gr.sizeof_gr_complex, ./rx.out).
How could I monitor the output of tx module? Thanks.
self.connect(rx,
Dear GNU Radio aficionado's-
Whatever happened to resistance, capacitance, and inductance?
When I joined this thread I was hoping you would once in a while
talk about ways of using the software in the computer to modify
the resonant circuit in the hardware radio by making adjustments
to the
GNU Radio releases 3.6.3.1 and 3.6.4 are now available for download.
Release 3.6.3.1 is a bug-fix only update to 3.6.3, and has no new features.
Release 3.6.4 has both bug fixes and new features.
http://gnuradio.org/releases/gnuradio/gnuradio-3.6.3.1.tar.gz
http://staff.washington.edu/jon/gr-mrfm/
USRP and GNU Radio controlling micromechanical oscillators for Magnetic
Resonance Force Microscopy (MRFM). Does that count?
-John
On Tue, Feb 26, 2013 at 2:10 PM, Joel Mayer joelm_armill...@msn.com wrote:
**
Dear GNU Radio aficionado's-
Whatever
Hi,
I have read the fhss_engine.py file.It seems that they send timed
information via msg.And it's impossible to recevie any bit unless they
use external synchronization.Is it right?Any suggestion would be
appreciated.
Thanks./
///
___
In gnuradio/digital/packet_utils, the packets are padded to make it a
multiple of 512 bytes to be sent across the USB(As per the comment there).
USRP2 and N210 uses ethernet connection. Is it important to have padding
for USRP in for these devices? If so is it the same number? ( 512 bytes to
be
On 02/26/2013 08:03 PM, Manu T S wrote:
In gnuradio/digital/packet_utils, the packets are padded to make it a
multiple of 512 bytes to be sent across the USB(As per the comment there).
USRP2 and N210 uses ethernet connection. Is it important to have padding
for USRP in for these devices?
I've been reading through the code in gnuradio-core/runtime for a few days
to understand the internal workings of the gnuradio scheduler. It seems to
me that gnuradio was originally based on a synchronous dataflow (sdf) model
of computation and the single thread schedule is an SDF sequential
24 matches
Mail list logo
