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 automati
On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau 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 these specifi
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 t
On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote:
> On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau 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 a
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" 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 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 I run it, i
On Tue, Feb 26, 2013 at 9:38 AM, Ralph A. Schmid, dk5ras
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" and "Boost_INCLUDE_DIR" to see which ones
>> were found and are b
On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau wrote:
> On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote:
>> On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote:
>>> GNU Radio: now allowing you to shoot yourself in the foot!
>>>
>>> We've identified a few versions of Boost that don't work wel
On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete wrote:
> On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau wrote:
>> On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote:
>>> On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote:
GNU Radio: now allowing you to shoot yourself in the foot!
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 w
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
main()
Fil
On Tue, Feb 26, 2013 at 5:21 PM, Tom Rondeau wrote:
> On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete wrote:
>> On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau wrote:
>>> On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote:
On Wed, Feb 13, 2013 at 8:12 PM, Tom Rondeau wrote:
> GNU R
On Tue, Feb 26, 2013 at 1:12 PM, Alexandru Csete wrote:
> On Tue, Feb 26, 2013 at 5:21 PM, Tom Rondeau wrote:
>> On Tue, Feb 26, 2013 at 11:10 AM, Alexandru Csete wrote:
>>> On Tue, Feb 26, 2013 at 3:15 PM, Tom Rondeau wrote:
On Tue, Feb 26, 2013 at 7:01 AM, Alexandru Csete wrote:
> O
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 resist
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://gnuradio.org/releases/gnuradio/
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 wrote:
> **
> Dear GNU Radio aficionado's-
>
> Whatever happened to resistanc
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./
///
___
Discuss
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 se
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 device
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 runti
24 matches
Mail list logo
