[Discuss-gnuradio] usrp2_rx_cfile change of daughter board
Hello all, I was using usrp2_rx_cfile.py module to sense 2.4G channel by using RX2400 board(2.2G to 2.9G). Now I want to sense TV frequencies so I have changed the daughter board to wbx daughter board ( 50 MHz to 2.2G). But now I cannot sense the signal by using coaxial cable connected to my usrp2 box and on the other end connect to antenna on the roof top. I have tested that there is a TV signal by plugging the cable into my signal analyser but my program cannot sense that signal. Regards, Umer Rabbani | Researcher Polaris House, PP129 B29, Adastral Park, Ipswich, IP5 3RE 01473645887| - 0743 57 67 821 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WBX and frequencies around 433 MHz?
> Hi, While I was testing the DQPSK-(de)modulation blocks in GRC. >>> I found a frequency region where the reception failed. I >>> >> started with >> >>> the ISM-band (433 MHz) as the center frequency, and the reception >>> didn't work. After checking my code several times I decided >>> >> to change >> >>> the center frequency to 2 GHz and everything started to work. So I >>> tried several other center frequencies with successful outcome, for >>> example 2 GHz, 1.5GHz, 800MHz, 500MHz, 420MHz. If I tuned the >>> frequency to the 430-440 MHz region the reception fails. >>> I've used 2 USRP2s with the WBX and connected them with a >>> cable and 20 dB attenuator. >>> I have 4 different WBX cards and the result is the same for >>> each of them. >>> Have someone encountered the same problem with frequencies >>> around 433 MHz? >>> Br, Patrik >>> Well, there's a lot of amateur radio traffic in that >>> >> frequency range, >> >>> which may be interfering. >>> >> I will keep that in mind. But I used a cable between the >> USRP2s, so I wouldn't expect any interference from other systems. >> >> >>> Also, there's a special frequency at 433.920MHz used for >>> >> garage door >> >>> openers. Are you running >>> your USRP2 with the covers on or off? >>> >> The covers are on. >> >> I will have a look at the received spectrum again, as Nick suggested. >> > > Please have a look at the attached spectrum. > > Cable.png shows the spectrum when the transmitter is connected to the > spectrum analyzer with a cable and 20 dB attenuator. The white line is the > spectrum at the center frequency 433 MHz and the yellow line is at 400 MHz. > The spectrum for 433 MHz looks like crap. > > Figure 400.png and 433.png shows the received constellation points and the > received spectrum after a LPF for 400 MHz and 433 MHz. > > -Patrik > This looks like horrendous phase noise. What base platform is this? (USRP1, USRP2, N2XXX, etc) Do you have multiple base platforms you can try this on, and if so, are the results the same? -- 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
Re: [Discuss-gnuradio] CMake builds vs Autotools builds
On Tue, Dec 6, 2011 at 12:56 AM, Josh Blum wrote: > >> > http://gnuradio.org/cgit/gnuradio.git/commit/?id=56fcd5f9b22af33976f9413d3a9d0aec41a7b556 > >> > >> -josh > >> > >> > >> Marcus, would you be up for trying that? The resulting la files do not > >> match what comes out of autotools. We don't know if they will work, > >> despite their differences, and it'd be good to know. > >> > >> Thanks, > >> Tom > >> > >> > >> ___ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > > Yeah, I'll give it a try tommorow evening sometime. Farking day job > > gets in the way of all the > > fun stuff :-( > > > > This was fixed a month ago. Just clean your install. > > http://gnuradio.org/redmine/issues/473 > > -josh I believe the problem is that he NEEDS the .la files for the gr-fcd compilation. So either the gr-fcd would have to be worked on to link a different way, or we would have to provide the .la files (and make sure they are correct). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2_rx_cfile change of daughter board
On Tue, Dec 6, 2011 at 5:21 AM, wrote: > Hello all, > I was using usrp2_rx_cfile.py module to sense 2.4G channel by using RX2400 > board(2.2G to 2.9G). Now I want to sense TV frequencies so I have changed > the daughter board to wbx daughter board ( 50 MHz to 2.2G). But now I > cannot sense the signal by using coaxial cable connected to my usrp2 box > and on the other end connect to antenna on the roof top. I have tested that > there is a TV signal by plugging the cable into my signal analyser but my > program cannot sense that signal. > > Regards, > Umer Rabbani | Researcher > Umer, It looks like you are using the older libusrp2 code (usrp2_rx_cfile instead of uhd_rx_cfile). If that's the case, there are different images you need on the SD Card in the USRP2 to work with the WBX board. If possible, I suggest updating to the latest GNU Radio code ( http://gnuradio.org/redmine/news/5) and switch over the UHD. It will work for all daughterboards. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange behaviour of example 'variable-config.grc'
On Tue, Dec 6, 2011 at 12:20 AM, John Coppens wrote:
> Hi,
>
> Pardon my newness to gnuradio... I compiled and installed the latest
> dev tar.gz. I tried to compile 3.4.2 with autotools, but didn't get
> anywhere. So I followed an advice in a mail I found, and, using
> cmake/gmake, all went well (no error messages at least).
>
> Impatiently, I composed a small system with a wav-file reader, low-pass,
> and audio-output, and this worked fine. More systematically, I tried to
> load the example in /gnuradio-examples/grc/simple, called
> variable-config.grc. Here I get the error:
>
> Generating:
> "/usr/local/src/hardware/gnuradio/gnuradio-examples/grc/simple/variable_config_demo.py"
> Generate Error: circular dependency caught in sort_variables
> >>> Failue
> Traceback (most recent call last):
> File
> "/usr/local/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
> line 291, in _handle_action
>generator.write()
> File
> "/usr/local/lib64/python2.6/site-packages/gnuradio/grc/python/Generator.py",
> line 66, in write
>open(self.get_file_path(), 'w').write(str(self))
> File
> "/usr/local/lib64/python2.6/site-packages/gnuradio/grc/python/Generator.py",
> line 102, in __str__
>variables = self._flow_graph.get_variables()
> File
> "/usr/local/lib64/python2.6/site-packages/gnuradio/grc/python/FlowGraph.py",
> line 101, in get_variables
>return expr_utils.sort_objects(variables, lambda v: v.get_id(), lambda
> v: v.get_var_make())
> File
> "/usr/local/lib64/python2.6/site-packages/gnuradio/grc/python/expr_utils.py",
> line 148, in sort_objects
>sorted_ids = sort_variables(id2expr)
> File
> "/usr/local/lib64/python2.6/site-packages/gnuradio/grc/python/expr_utils.py",
> line 129, in sort_variables
>if not indep_vars: raise Exception('circular dependency caught in
> sort_variables')
> Exception: circular dependency caught in sort_variables
>
> Executing:
> "/usr/local/src/hardware/gnuradio/gnuradio-examples/grc/simple/variable_config_demo.py"
>
>
> Seemingly randomly, I get a red title in some box, and the error message:
>
> Param - Enabled(_enabled):
>Value "True" cannot be evaluated:
>circular dependency caught in sort_variables
>
> Any suggestions for further testing?
>
> (Python 2.6.6, GNU Radio Companion v3.5.x-xxx-xunknown).
> Linux 2.6.37.3 #1 SMP Sun Mar 13 20:31:56 ART 2011 x86_64 AMD Athlon(tm)
> 64 X2 Dual Core Processor 3600+ AuthenticAMD GNU/Linux
>
>
> Greetings,
> John
>
John,
Where are you running GRC from? And are you trying to run this inside GRC
or on the command line after you generate the .py file?
I'm assuming your examples directory you are reading from is writable? I
ask because the default install is into /usr/local and becomes read-only;
the generated .py file is placed in /tmp. I just tried this in the
read-only environment on my machine and both executing inside GRC worked as
well as from the command-line (in /tmp).
Is there anything else in your directory that could be causing a name
collision during the Python imports?
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WBX and frequencies around 433 MHz?
Patrik,
Can you please check to see that the WBX LO is locked? If you have a
GRC flowgraph, you can use a function probe block with the following
settings:
ID: lo_locked
Block ID: uhd_usrp_source_0 (or whatever your UHD source block is named)
Function name: get_dboard_sensor
Function args: '"lo_locked", 0'
Poll rate: 1
Then use a WXGUI checkbox with a default value set to bool(lo_locked).
When you run your flowgraph, the checkbox will indicate whether the LO
is locked.
In your own non-GRC application you can use .get_dboard_sensor("lo_locked", 0) to check the status of the
daughterboard LO lock.
--n
On Tue, Dec 6, 2011 at 4:40 AM, Patrik Eliardsson
wrote:
>> > > Hi,
>> > >
>> > > While I was testing the DQPSK-(de)modulation blocks in GRC.
>> > I found a frequency region where the reception failed. I
>> started with
>> > the ISM-band (433 MHz) as the center frequency, and the reception
>> > didn't work. After checking my code several times I decided
>> to change
>> > the center frequency to 2 GHz and everything started to work. So I
>> > tried several other center frequencies with successful outcome, for
>> > example 2 GHz, 1.5GHz, 800MHz, 500MHz, 420MHz. If I tuned the
>> > frequency to the 430-440 MHz region the reception fails.
>> > >
>> > > I've used 2 USRP2s with the WBX and connected them with a
>> > cable and 20 dB attenuator.
>> > >
>> > > I have 4 different WBX cards and the result is the same for
>> > each of them.
>> > >
>> > > Have someone encountered the same problem with frequencies
>> > around 433 MHz?
>> > >
>> > > Br,
>> > > Patrik
>> > >
>> > >
>> > Well, there's a lot of amateur radio traffic in that
>> frequency range,
>> > which may be interfering.
>>
>> I will keep that in mind. But I used a cable between the
>> USRP2s, so I wouldn't expect any interference from other systems.
>>
>> > Also, there's a special frequency at 433.920MHz used for
>> garage door
>> > openers. Are you running
>> > your USRP2 with the covers on or off?
>>
>> The covers are on.
>>
>> I will have a look at the received spectrum again, as Nick suggested.
>
>
> Please have a look at the attached spectrum.
>
> Cable.png shows the spectrum when the transmitter is connected to the
> spectrum analyzer with a cable and 20 dB attenuator. The white line is the
> spectrum at the center frequency 433 MHz and the yellow line is at 400 MHz.
> The spectrum for 433 MHz looks like crap.
>
> Figure 400.png and 433.png shows the received constellation points and the
> received spectrum after a LPF for 400 MHz and 433 MHz.
>
> -Patrik
> ___
> 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] How to specify boost include path to configure?
Hello gnuradio world! I'm trying to get started and I'm getting hung up building and installing. I'm following the build guide. How do I point configure for gnuradio to the boost141 include directory? I am building gnuradio-3.4.2 from the source tarball on RHEL 5.7 x86_64. When I try to make I get errors indicating that the wrong boost headers are being used. I have installed boost141 (v1.41 along with the development package) from EPEL as the boost version in RHEL is too old (v1.33.1). Configure found the appropriate version based on my direction: $ PYTHON="/usr/bin/python26" SWIG="/usr/share/swig/2.0.4/bin/swig" ./configure --with-boost-libdir=/usr/lib64/boost141 configure:20483: checking for boost >= 1.35 configure:20545: g++ -c -I/usr/include conftest.cpp >&5 configure:20545: $? = 0 configure:20546: result: yes BOOST_CPPFLAGS='-I/usr/include' BOOST_CXXFLAGS='-pthread' BOOST_DATE_TIME_LIB='-lboost_date_time-mt' BOOST_FILESYSTEM_LIB='-lboost_filesystem-mt' BOOST_LDFLAGS='-L/usr/lib64/boost141' BOOST_PROGRAM_OPTIONS_LIB='-lboost_program_options-mt' BOOST_SYSTEM_LIB='-lboost_system-mt' BOOST_THREAD_LIB='-lboost_thread-mt' I think the BOOST_CPPFLAGS should be '-l/usr/include/boost141' because when I run make I get boost-related errors that point to the wrong include path: $ make mv -f .deps/test_gruel.Tpo .deps/test_gruel.Po /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o test_gruel test_gruel.o -lboost_thread-mt -lboost_system-mt -lboost_filesystem-mt pmt/libpmt-qa.la libgruel.la libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_gruel test_gruel.o -lboost_system-mt -lboost_filesystem-mt pmt/.libs/libpmt-qa.a -L/usr/lib64/boost141 -lboost_thread-mt -lcppunit -ldl ./.libs/libgruel.so -pthread -Wl,-rpath -Wl,/usr/local/lib64 test_gruel.o: In function `__static_initialization_and_destruction_0': /usr/local/include/boost/system/error_code.hpp:214: undefined reference to `boost::system::generic_category()' /usr/local/include/boost/system/error_code.hpp:215: undefined reference to `boost::system::generic_category()' /usr/local/include/boost/system/error_code.hpp:216: undefined reference to `boost::system::system_category()' test_gruel.o: In function `current_path': /usr/local/include/boost/filesystem/v3/operations.hpp:429: undefined reference to `boost::filesystem3::detail::current_path(boost::system::error_code*)' test_gruel.o: In function `boost::filesystem3::operator/(boost::filesystem3::path const&, boost::filesystem3::path const&)': /usr/local/include/boost/filesystem/v3/path.hpp:598: undefined reference to `boost::filesystem3::path::operator/=(boost::filesystem3::path const&)' test_gruel.o: In function `is_directory': /usr/local/include/boost/filesystem/v3/operations.hpp:294: undefined reference to `boost::filesystem3::detail::status(boost::filesystem3::path const&, boost::system::error_code*)' test_gruel.o: In function `create_directory': /usr/local/include/boost/filesystem/v3/operations.hpp:405: undefined reference to `boost::filesystem3::detail::create_directory(boost::filesystem3::path const&, boost::system::error_code*)' test_gruel.o: In function `boost::filesystem3::operator/(boost::filesystem3::path const&, boost::filesystem3::path const&)': /usr/local/include/boost/filesystem/v3/path.hpp:598: undefined reference to `boost::filesystem3::path::operator/=(boost::filesystem3::path const&)' collect2: ld returned 1 exit status make[7]: *** [test_gruel] Error 1 make[7]: Leaving directory `/home/gr/source/gnuradio-3.4.2/gruel/src/lib' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/home/gr/source/gnuradio-3.4.2/gruel/src/lib' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/gr/source/gnuradio-3.4.2/gruel/src/lib' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/gr/source/gnuradio-3.4.2/gruel/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/gr/source/gnuradio-3.4.2/gruel' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/gr/source/gnuradio-3.4.2/gruel' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gr/source/gnuradio-3.4.2' make: *** [all] Error 2 The proper path to boost141 headers is /usr/include/boost141. When I built UHD I had to point cmake to the includes as well as libraries: $ cmake -DPYTHON_EXECUTABLE=/usr/bin/python26 -DBOOST_INCLUDEDIR=/usr/include/boost141 -DBOOST_LIBRARYDIR=/usr/lib64/boost141 ../ How can I specify the boost141 include directory using configure for gnuradio? OS info: $ cat /proc/version Linux version 2.6.18-274.3.1.el5 (mockbu...@hs20-bc2-4.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)) #1 SMP Fri Aug 26 18:49:02 EDT 2011 $ lsb_release -i -r Distributor ID: RedHatEnterpriseClient Release: 5.7 CPU info: Intel Westmere. Thanks for any help! Justin _
Re: [Discuss-gnuradio] How to specify boost include path to configure?
>
> How do I point configure for gnuradio to the boost141 include directory?
>
I discovered that libraries from a failed attempt at building boost from source
were being used. I removed these, and now my problem is more fundamental:
configure fails to identify boost. I have boost141 (v1.41) from EPEL on my
RHEL 5.7 machine. The libraries are in /usr/lib64/boost141. The includes are
in /usr/include/boost141/boost.
How do I get configure to see the correct libraries and includes?
Presently I have:
$ PYTHON="/usr/bin/python26" SWIG="/usr/share/swig/2.0.4/bin/swig" ./configure
--with-boost-libdir=/usr/lib64/boost141 --with-boost=/usr/include/boost141
configure:20483: checking for boost >= 1.35
configure:20545: g++ -c -I/usr/include/boost141/include conftest.cpp >&5
conftest.cpp:112:8: error: #error Boost version is too old
configure:20545: $? = 1
configure: failed program was:
| /* confdefs.h */
| /* end confdefs.h. */
|
| #include
|
| int
| main ()
| {
|
| #if BOOST_VERSION >= 103500
| // Everything is okay
| #else
| # error Boost version is too old
| #endif
|
| ;
| return 0;
| }
configure:20625: g++ -c -I/include/boost-0 conftest.cpp >&5
conftest.cpp:112:12: error: #error Boost version is too old
configure:20625: $? = 1
configure: failed program was:
| /* confdefs.h */
| /* end confdefs.h. */
|
| #include
|
| int
| main ()
| {
|
| #if BOOST_VERSION >= 103500
| // Everything is okay
| #else
| # error Boost version is too old
| #endif
|
| ;
| return 0;
| }
configure:20644: result: no
configure:20648: error: we could not detect the boost libraries (version 1.35
or higher).
If you are sure you have boost installed, then check your version number
looking in .
I have symlinked /usr/include/boost141/include to /usr/include/boost141/boost
but I suspect that the path being followed is
/usr/include/boost141/include/boost which doesn't exist.
What's the right way to do this?
Justin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to specify boost include path to configure?
> > How do I get configure to see the correct libraries and includes? > Well, I found what I think is a solution...I made two symlinks: /usr/include/boost141/include -> /usr/include/boost141/boost /usr/include/boost141/boost/boost -> /usr/include/boost141/boost This can't be "the right way" to direct configure to the proper boost include files. If anyone knows what should be done I'd appreciate hearing about it. I'm past gruel now but I've got other errors from make. I'll make a new thread if I can't figure them out. Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with python blocks [attn: jblum]
On 12/05/2011 06:40 PM, Paul Miller wrote: > On Mon, Dec 05, 2011 at 08:30:17AM -0800, Josh Blum wrote: >> Looks like I had a typo in the forecast call, fix is pushed. I should >> have had unit testing for the general_work as well. >> http://gnuradio.org/cgit/jblum.git/log/?h=python_blocks > > Compiled! > >> I dont really know if thats the cause of the error...? > > Me either. The backtrace looks identical to me, so I might even > recompile just to make sure ... I mean, ... yeah, it's on > 5cd66ee, so. > > #0 0x77af908c in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > #1 0x77aff8ef in PyEval_EvalCodeEx () from > /usr/lib/libpython2.7.so.1.0 > #2 0x77a8c15c in function_call () from /usr/lib/libpython2.7.so.1.0 > #3 0x77a67683 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0 > #4 0x77a762bf in instancemethod_call () from > /usr/lib/libpython2.7.so.1.0 > #5 0x77a67683 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0 > #6 0x77a67d5d in PyObject_CallMethodObjArgs () from > /usr/lib/libpython2.7.so.1.0 > #7 0x74706d84 in SwigDirector_gr_block_gw_handler_safe::call_handle > (this=0x1b1efe0) > at > /home/jettero/code/arch/gnuradio/src/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6851 > #8 0x7669dea5 in gr_block_gateway_impl::start (this=0x1b226e0) > at > /home/jettero/code/arch/gnuradio/src/gnuradio-core/src/lib/general/gr_block_gateway.cc:171 > #9 0x76634d97 in gr_block_executor::gr_block_executor > (this=0x7fffedb05d70, block=) > at > /home/jettero/code/arch/gnuradio/src/gnuradio-core/src/lib/runtime/gr_block_executor.cc:169 > #10 0x76653c14 in gr_tpb_thread_body::gr_tpb_thread_body > (this=0x7fffedb05d70, block=...) > at > /home/jettero/code/arch/gnuradio/src/gnuradio-core/src/lib/runtime/gr_tpb_thread_body.cc:32 > #11 0x7664e9c4 in operator() (this=0x1b03430) at > /home/jettero/code/arch/gnuradio/src/gnuradio-core/src/lib/runtime/gr_scheduler_tpb.cc:42 > #12 operator() (this=0x1b03430) at > /home/jettero/code/arch/gnuradio/src/gruel/src/include/gruel/thread_body_wrapper.h:50 > #13 > boost::detail::function::void_function_obj_invoker0, > void>::invoke (function_obj_ptr=...) > at /usr/include/boost/function/function_template.hpp:153 > #14 0x75e5b2fe in operator() (this=) at > /usr/include/boost/function/function_template.hpp:760 > #15 boost::detail::thread_data >::run (this= out>) at /usr/include/boost/thread/detail/thread.hpp:61 > #16 0x757f8699 in ?? () from /usr/lib/libboost_thread.so.1.48.0 > #17 0x77808df0 in start_thread () from /lib/libpthread.so.0 > #18 0x7754e39d in clone () from /lib/libc.so.6 > >> I attached a copy of your code that worked for me (minus that the unit >> test fails since its not really normalizing) > > Yeah, I had a normalizer there, but when it started sagfaulting, I just > simplified down ... I'm surprised my code worked for you, but not for me. I > wonder if it's my swig or my boost or something. > Whats your OS? I have tested it on a few recent ubuntus and fedoras, and windows with a recent boost. Does the qa code for the python blocks run for you? Within tree, out of tree? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake builds vs Autotools builds
On Tue, Dec 6, 2011 at 6:33 PM, Tom Rondeau wrote: > On Tue, Dec 6, 2011 at 12:56 AM, Josh Blum wrote: > >> >> >> http://gnuradio.org/cgit/gnuradio.git/commit/?id=56fcd5f9b22af33976f9413d3a9d0aec41a7b556 >> >> >> >> -josh >> >> >> >> >> >> Marcus, would you be up for trying that? The resulting la files do not >> >> match what comes out of autotools. We don't know if they will work, >> >> despite their differences, and it'd be good to know. >> >> >> >> Thanks, >> >> Tom >> >> >> >> >> >> ___ >> >> Discuss-gnuradio mailing list >> >> Discuss-gnuradio@gnu.org >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> > Yeah, I'll give it a try tommorow evening sometime. Farking day job >> > gets in the way of all the >> > fun stuff :-( >> > >> >> This was fixed a month ago. Just clean your install. >> >> http://gnuradio.org/redmine/issues/473 >> >> -josh > > > I believe the problem is that he NEEDS the .la files for the gr-fcd > compilation. So either the gr-fcd would have to be worked on to link a > different way, or we would have to provide the .la files (and make sure > they are correct). > > Actually, gr-fcd can link against .so but apparently the autotools prefer .la if they are present. I had issue with the cmake generated .la file a month ago and Josh suggested to disable generation of .la files, see http://lists.gnu.org/archive/html/discuss-gnuradio/2011-10/msg00512.html Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange behaviour of example 'variable-config.grc'
On Tue, 6 Dec 2011 12:51:50 -0500 Tom Rondeau wrote: > John, > Where are you running GRC from? And are you trying to run this inside GRC > or on the command line after you generate the .py file? I call gnuradio-companion from a terminal window (That's where the error messages come from) > I'm assuming your examples directory you are reading from is writable? I > ask because the default install is into /usr/local and becomes read-only; > the generated .py file is placed in /tmp. I just tried this in the > read-only environment on my machine and both executing inside GRC worked as > well as from the command-line (in /tmp). Yes, it is writeable. I did install with default paths, so it is all in /usr/local, but I ran the demo from the original source tree. To discard any permission problems, I tried to run as root too. > Is there anything else in your directory that could be causing a name > collision during the Python imports? > > Tom No idea - in the demo directory, only the three examples are present. >From the error message, it seems as if the word 'True' is causing problems. I cannot image any reason for that. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building on 64-bit Linux
Is there a solution for building gnuradio on 64-bit Linux using the stable v3.4.2 release? I'm seeing errors similar to the following thread when building gnuradio from the v3.4.2 source tarball on RHEL 5.7 x86_64: http://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg2.html. I followed the procedure for cmake (http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork) and encountered new errors: $ cmake -DPYTHON_EXECUTABLE=/usr/bin/python26 -DBOOST_INCLUDEDIR=/usr/include/boost141 -DBOOST_LIBRARYDIR=/usr/lib64/boost141 -DSWIG_EXECUTABLE=/usr/share/swig/2.0.4/bin/swig ../ -- Configuring done -- Generating done -- Build files have been written to: /home/gr/source/git/gnuradio/build $ make [ 47%] Generating general_swig_doc.i Error in xml in file /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml Traceback (most recent call last): File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 253, in make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 196, in make_swig_interface_file blocks = di.in_category(Block) File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 140, in in_category self.confirm_no_error() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 206, in confirm_no_error self.check_parsed() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 203, in check_parsed self._parse() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", line 51, in _parse self._members += converted.members() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 174, in members self.confirm_no_error() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 206, in confirm_no_error self.check_parsed() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 203, in check_parsed self._parse() File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", line 163, in _parse self.set_descriptions(self._retrieved_data.compounddef) AttributeError: 'NoneType' object has no attribute 'compounddef' make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1 make[1]: *** [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2 make: *** [all] Error 2 If it's hopeless to build from the stable release, what's the best path to a working gnuradio installation at the moment? Thanks!Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with new swig docs stuff
> > [ 47%] Generating general_swig_doc.i > Error in xml in file > /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml > Traceback (most recent call last): > File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 253, in > > make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) > File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 196, in > make_swig_interface_file > blocks = di.in_category(Block) > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 140, > in in_category > self.confirm_no_error() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 206, > in confirm_no_error > self.check_parsed() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 203, > in check_parsed > self._parse() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", line > 51, in _parse > self._members += converted.members() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 174, > in members > self.confirm_no_error() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 206, > in confirm_no_error > self.check_parsed() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line 203, > in check_parsed > self._parse() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", line > 163, in _parse > self.set_descriptions(self._retrieved_data.compounddef) > AttributeError: 'NoneType' object has no attribute 'compounddef' > make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1 > make[1]: *** > [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2 > make: *** [all] Error 2 > Tom/Ben, I think doxyindex.py may be relying on an xml field that older doxygen's do not define. Perhaps we could put a big try/catch around this in case it fails and print to stderr. That way the build keeps going, and its just a warning printed out in the terminal. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with new swig docs stuff
On Tue, Dec 6, 2011 at 5:51 PM, Josh Blum wrote: > > > > > [ 47%] Generating general_swig_doc.i > > Error in xml in file > /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml > > Traceback (most recent call last): > > File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line > 253, in > > make_swig_interface_file(di, swigdocfilename, > custom_output=custom_output) > > File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line > 196, in make_swig_interface_file > > blocks = di.in_category(Block) > > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 140, in in_category > > self.confirm_no_error() > > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 206, in confirm_no_error > > self.check_parsed() > > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 203, in check_parsed > > self._parse() > > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", > line 51, in _parse > > self._members += converted.members() > > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 174, in members > > self.confirm_no_error() > > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 206, in confirm_no_error > > self.check_parsed() > > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 203, in check_parsed > > self._parse() > > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", > line 163, in _parse > > self.set_descriptions(self._retrieved_data.compounddef) > > AttributeError: 'NoneType' object has no attribute 'compounddef' > > make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1 > > make[1]: *** > [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error > 2 > > make: *** [all] Error 2 > > > > Tom/Ben, > > I think doxyindex.py may be relying on an xml field that older doxygen's > do not define. > > Perhaps we could put a big try/catch around this in case it fails and > print to stderr. That way the build keeps going, and its just a warning > printed out in the terminal. > > -josh > Version info, please? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building on 64-bit Linux
On Tue, Dec 6, 2011 at 5:35 PM, Justin Ford wrote: > > Is there a solution for building gnuradio on 64-bit Linux using the stable > v3.4.2 release? > > I'm seeing errors similar to the following thread when building gnuradio > from the v3.4.2 source tarball on RHEL 5.7 x86_64: > http://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg2.html. > > I followed the procedure for cmake ( > http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork) and > encountered new errors: > > > $ cmake -DPYTHON_EXECUTABLE=/usr/bin/python26 > -DBOOST_INCLUDEDIR=/usr/include/boost141 > -DBOOST_LIBRARYDIR=/usr/lib64/boost141 > -DSWIG_EXECUTABLE=/usr/share/swig/2.0.4/bin/swig ../ > > > > -- Configuring done > > -- Generating done > > -- Build files have been written to: > /home/gr/source/git/gnuradio/build > > > $ make I'm confused how you are using cmake with the 3.4.2 tarball. That wasn't introduced until 3.5. And that swig-doc stuff was just put in yesterday. Just checking to make sure there's no confusion about something here. Tom > > [ 47%] Generating general_swig_doc.i > Error in xml in file > /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml > Traceback (most recent call last): > File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 253, > in > make_swig_interface_file(di, swigdocfilename, > custom_output=custom_output) > File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line 196, > in make_swig_interface_file > blocks = di.in_category(Block) > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 140, in in_category > self.confirm_no_error() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 206, in confirm_no_error > self.check_parsed() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 203, in check_parsed > self._parse() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", > line 51, in _parse > self._members += converted.members() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 174, in members > self.confirm_no_error() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 206, in confirm_no_error > self.check_parsed() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line > 203, in check_parsed > self._parse() > File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", > line 163, in _parse > self.set_descriptions(self._retrieved_data.compounddef) > AttributeError: 'NoneType' object has no attribute 'compounddef' > make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1 > make[1]: *** > [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error > 2 > make: *** [all] Error 2 > > If it's hopeless to build from the stable release, what's the best path to > a working gnuradio installation at the moment? > Thanks!Justin > > ___ > 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] Strange behaviour of example 'variable-config.grc'
On Tue, Dec 6, 2011 at 5:06 PM, John Coppens wrote: > On Tue, 6 Dec 2011 12:51:50 -0500 > Tom Rondeau wrote: > > > John, > > Where are you running GRC from? And are you trying to run this inside GRC > > or on the command line after you generate the .py file? > > I call gnuradio-companion from a terminal window (That's where the > error messages come from) > > > I'm assuming your examples directory you are reading from is writable? I > > ask because the default install is into /usr/local and becomes read-only; > > the generated .py file is placed in /tmp. I just tried this in the > > read-only environment on my machine and both executing inside GRC worked > as > > well as from the command-line (in /tmp). > > Yes, it is writeable. I did install with default paths, so it is all > in /usr/local, but I ran the demo from the original source tree. To > discard any permission problems, I tried to run as root too. > > > Is there anything else in your directory that could be causing a name > > collision during the Python imports? > > > > Tom > > No idea - in the demo directory, only the three examples are present. > > From the error message, it seems as if the word 'True' is causing > problems. I cannot image any reason for that. > > John > What OS are you running? (I'm asking these questions because I'm stumped and am buying time.) Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake builds vs Autotools builds
On Tue, Dec 6, 2011 at 4:16 PM, Alexandru Csete wrote: > On Tue, Dec 6, 2011 at 6:33 PM, Tom Rondeau wrote: > >> On Tue, Dec 6, 2011 at 12:56 AM, Josh Blum wrote: >> >>> >> >>> http://gnuradio.org/cgit/gnuradio.git/commit/?id=56fcd5f9b22af33976f9413d3a9d0aec41a7b556 >>> >> >>> >> -josh >>> >> >>> >> >>> >> Marcus, would you be up for trying that? The resulting la files do not >>> >> match what comes out of autotools. We don't know if they will work, >>> >> despite their differences, and it'd be good to know. >>> >> >>> >> Thanks, >>> >> Tom >>> >> >>> >> >>> >> ___ >>> >> Discuss-gnuradio mailing list >>> >> Discuss-gnuradio@gnu.org >>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >>> > Yeah, I'll give it a try tommorow evening sometime. Farking day job >>> > gets in the way of all the >>> > fun stuff :-( >>> > >>> >>> This was fixed a month ago. Just clean your install. >>> >>> http://gnuradio.org/redmine/issues/473 >>> >>> -josh >> >> >> I believe the problem is that he NEEDS the .la files for the gr-fcd >> compilation. So either the gr-fcd would have to be worked on to link a >> different way, or we would have to provide the .la files (and make sure >> they are correct). >> >> > Actually, gr-fcd can link against .so but apparently the autotools prefer > .la if they are present. > I had issue with the cmake generated .la file a month ago and Josh > suggested to disable generation of .la files, see > http://lists.gnu.org/archive/html/discuss-gnuradio/2011-10/msg00512.html > > Alex > Alright, good. Just making sure we didn't actually need the .la files. Which is good, since making them "correctly" (that is, identical to the output of autotools) could have been a real pain. Thanks! Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HELP : How to use uhd_fft.py
2011/12/4 Nakajo Tomoyuki > Dear all, > > I try to use uhd_fft.py. > > The viewing area is displayed, but, no waveform is displayed on viewing > area. > Please tell me how to manage the trouble. > > A result of uhd_fft.py is below, > > > jupiter@jupiter-Prime-Series:/usr/local/bin$ ./uhd_fft.py -a > "addr=192.168.10.2" > linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.004.000-07c9d41 > > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > > 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 > --- You are probably receiving a signal too small to be displayed in the default area of the FFT plot. Try setting the the ref level and dB/step or scroll (using a mouse wheel) down to see where the signal is. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake builds vs Autotools builds
On 12/06/2011 06:02 PM, Tom Rondeau wrote: Alright, good. Just making sure we didn't actually need the .la files. Which is good, since making them "correctly" (that is, identical to the output of autotools) could have been a real pain. Thanks! Tom Ok, "this evening" has arrived with a sickening "thud", and I removed the ".la" files from my /usr/local/lib (well, /usr/local/lib64): rm -f libgru*.la rm -f libgnur*.la Then re-ran the gr-fcd: bootstrap; ./configure; make; sudo make install Quadriumvirate, and it all went perfectly well. So, I don't think we *need* the .la files, and they, as observed previously, get in the way. But them being there in some weird-arsed state can certainly screw things up. -- 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
Re: [Discuss-gnuradio] Question about benchmark_tx and benchmark_rx
On Thu, Dec 1, 2011 at 10:15 PM, Muhammad Rosli wrote: > Hi, > > Thanks for your reply. I am using the narrowband example. > > If I attempt using > > ./benchmark_tx.py -f 400M -r 250k -S 4 > > and > > ./benchmark_rx.py -f 400M -r 250k -S 4 > > which I worked out from reading the README file, the receiver still output > overrun (many '0'). I verified that the transmitter working since my > spectrum analyser can pickup the signal from the transmitter. > > > -- > Regards, > Muhammad b Rosli > Student > Bachelor of Electrical and Electronic > University of Canterbury > What is your OS, version of GNU Radio, hardware? By default, the digital benchmarks run GMSK, so that with 250 kbps rate should be easily doable without overruns on most modern machines. Tom > > On Fri, Dec 2, 2011 at 3:56 PM, Marcus D. Leech wrote: > >> ** >> On 12/01/2011 09:36 PM, Muhammad Rosli wrote: >> >> Hi, >> >> Thanks for reading my mail. I would like to ask is there any additional >> setup or configuration required to execute benchmark_tx.py and >> benchmark_rx.py? >> >> My problem is I tried to initiate simple communication between two USRP1 >> using benchmark_rx.py and benchmark_tx.py . I had browse through the >> mailing list looking on how to use the file appropriately. Running >> benchmark_tx.py also execute help which I follow closely but failed to >> receive any packets. If I tried to execute at transmitter: >> >> benchmark_tx.py -f 400M -S 10 >> >> and at receiver >> >> benchmark_rx.py -f 400M -S 10 >> >> I did not received packet status. I only received '0' in the terminal. Is >> it correspond to error? >> >> I also read mailing list sent by other members but none mentioned about >> not able to execute benchmark_tx.py . If I missed any post, could anyone >> please provide me the link. >> >> For additional information: >> Gnuradio version used: v3.5.0rc0 >> USRP1 : revision 4 >> Ubuntu: 11.10 >> Daugtherboard: SBX >> >> Please let me know if I had to provide any additional information. >> >> -- >> Regards, >> Muhammad b Rosli >> Student >> Bachelor of Electrical and Electronic >> University of Canterbury >> >> You're asking for 10 samples per symbol, which may exceed the rate at >> which your receiver computer can keep up, depending on >> the modulation used, and the complexity of the modulation techniques. >> Are you using the narrowband or ofdm examples? >> >> The 'O' means overrun. The hardware (USRP1) is sending samples faster >> than your computer can keep up. >> >> >> >> >> -- >> Marcus Leech >> Principal Investigator >> Shirleys Bay Radio Astronomy Consortiumhttp://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] CMake builds vs Autotools builds
On Tue, Dec 6, 2011 at 6:11 PM, Marcus D. Leech wrote: > On 12/06/2011 06:02 PM, Tom Rondeau wrote: > >> >> Alright, good. Just making sure we didn't actually need the .la files. >> Which is good, since making them "correctly" (that is, identical to the >> output of autotools) could have been a real pain. >> >> Thanks! >> Tom >> >> Ok, "this evening" has arrived with a sickening "thud", and I removed > the ".la" files from my /usr/local/lib (well, /usr/local/lib64): > > rm -f libgru*.la > rm -f libgnur*.la > > Then re-ran the gr-fcd: > > bootstrap; ./configure; make; sudo make install > > Quadriumvirate, and it all went perfectly well. > > So, I don't think we *need* the .la files, and they, as observed > previously, get in the way. But them being there in some weird-arsed state > can certainly screw things up. > > > -- > Marcus Leech We do suggest you uninstall before updating, which would have removed these files. Now, with autotools still building the .la's, if you are going back and forth, that could be a problem. On that, a) we will be moving away from autotools in the next version and b) I hope most people would start and stay with a build structure until then. Thanks for checking into this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Peak detection
Dear all, I finally figure out how to receive packet using OFDM and Alamouti but unfortunately looks like I cannot detect all the peaks. 10% of the packets that I receive are right. I think that I experience a phase rotation, i.e. instead of receiving -1, I receive +1 for some preamble symbols and hence the channel estimate matrix has negative components. I am using PN to detect peaks. Do you have any advise or suggestion on how to fix this? I though to put a delay using a sleep in the alamouti encoder between 2 consecutive OFDM symbols in order to avoid the overlapping of symbols but it doesn't work. Looking forward to hearing from you Vanessa -- Vanessa GARDELLIN, Ph.D. Researcher Institute for Informatics and Telematics (IIT), Italian National Research Council (CNR) Via G. Moruzzi 1 56124 Pisa - ITALY Phone: +390503153267 Room: B65/c E-mail: vanessa.gardel...@iit.cnr.it WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/ Skype: gardellin.vanessa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with new swig docs stuff
On 12/06/2011 02:56 PM, Tom Rondeau wrote: > On Tue, Dec 6, 2011 at 5:51 PM, Josh Blum wrote: > >> >>> >>> [ 47%] Generating general_swig_doc.i >>> Error in xml in file >> /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml >>> Traceback (most recent call last): >>> File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line >> 253, in >>> make_swig_interface_file(di, swigdocfilename, >> custom_output=custom_output) >>> File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line >> 196, in make_swig_interface_file >>> blocks = di.in_category(Block) >>> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 140, in in_category >>> self.confirm_no_error() >>> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 206, in confirm_no_error >>> self.check_parsed() >>> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 203, in check_parsed >>> self._parse() >>> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", >> line 51, in _parse >>> self._members += converted.members() >>> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 174, in members >>> self.confirm_no_error() >>> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 206, in confirm_no_error >>> self.check_parsed() >>> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py", line >> 203, in check_parsed >>> self._parse() >>> File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", >> line 163, in _parse >>> self.set_descriptions(self._retrieved_data.compounddef) >>> AttributeError: 'NoneType' object has no attribute 'compounddef' >>> make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1 >>> make[1]: *** >> [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error >> 2 >>> make: *** [all] Error 2 >>> >> >> Tom/Ben, >> >> I think doxyindex.py may be relying on an xml field that older doxygen's >> do not define. >> >> Perhaps we could put a big try/catch around this in case it fails and >> print to stderr. That way the build keeps going, and its just a warning >> printed out in the terminal. >> >> -josh >> > > > Version info, please? > > Tom > Also please attach the gr__simple__framer__sync_8h.xml -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with python blocks [attn: jblum]
On Tue, Dec 06, 2011 at 12:44:17PM -0800, Josh Blum wrote: > Whats your OS? I have tested it on a few recent ubuntus and fedoras, and > windows with a recent boost. Arch. Everything is wacky new because of rolling release. It's super easy to get going if you build a test box, and I will happily produce gnuradio build suite, based of something I found in AUR but tweaked to taste. > Does the qa code for the python blocks run for you? I don't know how to run just those, so I ran them all... test> 99% tests passed, 1 tests failed out of 92 test> test> Total Test time (real) = 92.74 sec test> test> The following tests FAILED: test> 27 - qa_block_gateway (Failed) (I swear I'm not picking on you though.) > Within tree, out of tree? I don't know what this means. I use cmake (does autotools even work anymore?) and it's in a build/ dir. Is this what you mean? -Paul -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with python blocks [attn: jblum]
On 12/06/2011 06:39 PM, Paul Miller wrote: > On Tue, Dec 06, 2011 at 12:44:17PM -0800, Josh Blum wrote: >> Whats your OS? I have tested it on a few recent ubuntus and fedoras, and >> windows with a recent boost. > > Arch. Everything is wacky new because of rolling release. It's > super easy to get going if you build a test box, and I will > happily produce gnuradio build suite, based of something I found > in AUR but tweaked to taste. > >> Does the qa code for the python blocks run for you? > > I don't know how to run just those, so I ran them all... > > test> 99% tests passed, 1 tests failed out of 92 > test> > test> Total Test time (real) = 92.74 sec > test> > test> The following tests FAILED: > test> 27 - qa_block_gateway (Failed) > So it looks like everything else passed which included gr_feval (another thing in gnuradio-core that uses swig directors). It looks like the last recognizable thing the thread calls (from your traceback) is the swig director used in gr_block_gateway: #7 0x746ca774 in SwigDirector_gr_block_gw_handler_safe::call_handle (this=0x1b5ef90) So perhaps, if the problem is the director, and if we remove the things that are different from gr_feval, this might work for you? Can you try this patch: http://pastebin.com/nThT5RBj I wonder if anyone else on arch has the same issue? -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
