[Discuss-gnuradio] installing gnuradio on mint - libboost problem

j@lt1:~/gnuradio$ ./bootstrap
configure.ac:39: installing `./install-sh'
configure.ac:39: installing `./missing'
gnuradio-core/src/guile/Makefile.am: installing `./depcomp'
gnuradio-core/src/lib/swig/Makefile.am:77: installing `./py-compile'
configure.ac:22: installing `./install-sh'
configure.ac:22: installing `./missing'
lib/Makefile.am: installing `./depcomp'
j@lt1:~/gnuradio$ ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for git... /usr/bin/git
checking existence of git version control directory... ok
checking git description of current commit... v3.5.2.1-83-g1aecf534
configure: GNU Radio Release v3.5.2.1-83-g1aecf534
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to create a ustar tar archive... gnutar
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for library containing strerror... none required
checking whether we are using the GNU C++ compiler... no
checking whether g++-4.6.1 accepts -g... no
checking dependency style of g++-4.6.1... none
checking how to run the C++ preprocessor... /lib/cpp
checking gr_libdir_suffix... 64
checking whether to append 64 to libdir... yes. Setting libdir to ${exec_prefix}/lib64
checking whether gcc accepts -Wall... yes
checking whether gcc accepts -Werror-implicit-function-declaration... yes
checking whether gcc accepts -Wno-uninitialized... yes
checking whether g++-4.6.1 accepts -Wall... no
checking whether g++-4.6.1 accepts -Woverloaded-virtual... no
checking whether g++-4.6.1 accepts -Wno-uninitialized... no
checking whether user wants gprof... no
checking whether user wants prof... no
checking dependency style of gcc... gcc3
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for rm... /bin/rm
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... /lib/cpp
checking whether the g++-4.6.1 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
libtool.m4: error: problem compiling CXX test program
checking for g++-4.6.1 option to produce PIC... -DPIC
checking if g++-4.6.1 PIC flag -DPIC works... no
checking if g++-4.6.1 static flag works... no
checking if g++-4.6.1 supports -c -o file.o... no
checking if g++-4.6.1 supports -c -o file.o... (cached) no
checking whether the g++-4.6.1 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... unsupported
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/dist-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.7/dist-packages
checking for Python include path... /usr/include/python2.7
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for guile... /usr/bin/guile
checking for guile-config... /usr/bin/guile-config
checking for library containing lt_dladvise_global... -lltdl
checking for swig... /usr/bin/swig
checking for SWIG version... 1.3.40
checking for xmlto... no
checking for socket in -lsocket... no
checking sys/ipc.h usability... yes
checking sys/ipc.h presence... yes
checking for sys/ipc.h... yes
checking sys/shm.h usability... yes
checking sys/shm.h presence... yes
checking for sys/shm.h... yes
checking for library containing shmat... none required
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for strings.h... (cached) yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking linux/ppdev.h usability... yes
checking linux/ppdev.h presence... yes
checking for linux/ppdev.h... yes
checking dev/ppbus/ppi.h usability... no
checking dev/ppbus/ppi.h presence... no
checking for dev/ppbus/ppi.h... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for sys/types.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for stdint.h... (cached) yes
checking sched.h usability... yes
checking sched.h presence... yes
checking for sched.h... yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking sys/syscall.h usability... yes
checking sys/syscall.h presence... yes
checking for sys/syscall.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking vec_types.h usability... no
checking vec_types.h presence... no
checking for vec_types.h... no
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking for sys/types.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether byte ordering is bigendian... no
checking whether struct tm is in sys/time.h or time.h... time.h
checking for working alloca.h... yes
checking for alloca... yes
checking for posix_memalign... yes
checking for vprintf... yes
checking for _doprnt... no
checking for mmap... yes
checking for select... yes
checking for socket... yes
checking for strcspn... yes
checking for strerror... yes
checking for strspn... yes
checking for getpagesize... yes
checking for sysconf... yes
checking for snprintf... yes
checking for gettimeofday... yes
checking for nanosleep... yes
checking for sched_setscheduler... yes
checking for modf... yes
checking for sqrt... no
checking for sigaction... yes
checking for sigprocmask... yes
checking for pthread_sigmask... no
checking for sched_setaffinity... yes
checking for sincos in -lm... yes
checking for sincosf in -lm... yes
checking for sinf in -lm... yes
checking for cosf in -lm... yes
checking for exp10 in -lm... yes
checking for log2 in -lm... yes
checking whether to try shm vmcircbuf methods... yes
checking for library containing shm_open... -lrt
checking for shm_open... yes
checking for ld used by gcc... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking whether /usr/bin/ld accepts --enable-runtime-pseudo-reloc... no
checking for CreateFileMapping function... no
checking for sys/types.h... (cached) yes
checking for fcntl.h... (cached) yes
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking for windows.h... (cached) no
checking for winioctl.h... no
checking for winbase.h... no
checking for getopt... yes
checking for usleep... yes
checking for gettimeofday... (cached) yes
checking for nanosleep... (cached) yes
checking for rand... yes
checking for srand... yes
checking for random... yes
checking for srandom... yes
checking for sleep... yes
checking for sigaction... (cached) yes
checking for struct timezone... yes
checking for struct timespec... yes
checking for ssize_t... yes
checking for getopt... (cached) yes
checking for usleep... (cached) yes
checking for gettimeofday... (cached) yes
checking for Sleep... no
checking for dot... NO
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.18... yes
checking for FFTW3F... yes
checking for doxygen... /usr/bin/doxygen
checking for dot... no
checking for machine dependent speedups... x86
checking for CPPUNIT... yes
checking for boost >= 1.35... no
configure: 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 <boost/version.hpp>.
j@lt1:~/gnuradio$

Hi,

We are trying to install gnuradio on our home laptop running mint
12.  ./configure for gnuradio indicates that the boost libraries could not be
found. After reading the READMEboost, I downloaded the latest boost,
boost_1_49.tar.bz2. This version of boost uses bootstrap and configure
to install. The boost lib files are installed:
/usr/local/boost_1_49_0/lib/library files
 
include headers are in:
/usr/local/boost_1_49_0/include/boost/hpp file

I have added:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/boost_1_49_0/lib

Attached are outputs from the .bootstrap and ./configure commands for gnuradio.
Any thoughts suggestions for getting ./configure to see the libboost files? Have we
correctly set the LD_LIBRARY_PATH for our boost lib/include locations

Thank You,

Sincerely,

J.

Re: [Discuss-gnuradio] dbpsk on gnuradio-3.5 and Ubuntu 11.10

Hi Tom, 

Thanks for your suggestions but unfortunately they did not work so far. As per your suggestion, I have tried tuning the center frequency of the receiver node according to the estimated frequency offset between the receiver and the transmitter but it did not help :( 

I have again verified that the two aforementioned flow-graphs work fine on gnuradio-3.4 when i) USRP1 radios are used with libusrp(2),  ii) USRP N200 radios are used with uhd: usrp source/sink. But the same setup does not work with gnuradio-3.5 where I use uhd: usrp source/sink along with USRP N200 radios. I am a bit surprised to see this weird behavior because the frequency offset between two USRP N200 radios is usually on the order of few hundreds of Hz while the frequency offset between two USRP1 nodes is on the order of few KHz (and I have been able to retrieve/decode the transmitted symbols via dbpsk on gnuradio-3.4 with USRP1 radios successfully). So, I am a bit baffled now about what is going on. I have also attached to this email my two flow-graphs for your information. You will see that I have removed the LPF at the receiver, decreased the sampling rate inside the two flow-graphs to 500K Sps (because with a sampling rate of 1M Sps, if I run the receiver flow-graph long enough then I start seeing overruns occurring at a crazy rate). Moreover, I have now changed the payload of packet encoder on the transmitter to 4 bytes so as to make sure that the packet encoder packetizes every input sample and sends it with no delay. With this setting, 500K/(8*8*24)= ~325.520 symbols should be transmitted every second. So, I should be receiving 325.520*N samples(or symbols) in the file sink if I run the receiver flow-graph for N seconds (assuming transmitter is already on), but I rather find the file sink just empty. Is there any recent change/upgrade in the functionality of packet encoder/decoder, uhd: usrp sink/source etc (which might be causing this phenomena)? Lastly, I did simulated the flow-graph you provided me and was able to write the decoded symbols in a file and later read them from octave. What are your thoughts now?

Thanks a lot for the help.

Jon

---

From: Tom Rondeau <tom@trondeau.com>
To: Jon Watson <jon_watson@rocketmail.com>
Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Sent: Saturday, March 31, 2012 9:34 AM
Subject: Re: [Discuss-gnuradio] dbpsk on gnuradio-3.5 and Ubuntu 11.10

Jon,

I'm not sure why this would change between 3.4 and 3.5, but my guess
is that it's something to do with the frequency offset, which tends to
be the biggest problem with these things. I've attached a GRC example
that runs what you want in a loopback simulation (you need gr-qtgui
installed for this). It looks good here, but I haven't tried going
over the air. This was just to make sure the data and everything were
passing through the algorithm blocks correctly.

Try figuring out what the frequency difference is between your two
USRPs (to about 100 Hz or so) and correct either the transmitter or
receiver to more closely match them up.

Also, when you were using 3.4, were you using UHD or libusrp(2)?

Tom

[Discuss-gnuradio] /. : Software-Defined Radio For $11

Nice job, RTL developers! - MLD

< http://hardware.slashdot.org/story/12/03/31/1914217/software-defined-radio-for-11 >

Don't have $1500 to drop on a USRP? A Linux kernel developer has discovered that a Realtek digital TV tuner chip has an undocumented mode that turns it into a software-defined radio, with a frequency range of 64-1700MHz. The going rate for one of these USB devices can be as low as US$11. If you're unfamiliar with software-defined radio and have 20 minutes to spare, Balint Seeber has a great video introduction.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star

I found this post quite useful, interesting, and relevant for projects such as GNU Radio.

< http://www.softwarequalityconnection.com/2012/03/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/ >

The following post is more of a summary, specifically with respect to his project, of the above post; both are good, quick reads.

< http://www.lucidimagination.com/blog/2012/03/26/14-ways-to-contribute-to-solr/ >

- MLD

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Customized packet sink

On Fri, Mar 30, 2012 at 10:32 PM, anay tuljapurkar
<anay.tuljapurkar@gmail.com> wrote:
> Hey All,
>      Is the gr_packet_sink.cc capable of handling a customized packet format
> structure or would one have to come up with a customized packet sink
> structure of ones own ignoring the complexity of access code/ sync vector ?
>
> Thanks,
> Anay.

Anay,

No, that code wasn't really designed to be highly customizable. It
expects an sync vector and threshold, so you can play with those as
much as you want to as long as the sync word you use has 64 or fewer
bits (has to git into a long long int).

If you want something more, you'd have to create your own block.

Tom

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Error in usage of digital_constellation_sptr

Hi all,

I have a block which uses digital_constellation_sptr as an input parameter type. I read the parameter as "raw" data in the xml file. The header file "digital_constellation.h" has been included in both the c++ and the h files of my block. However, when I pass the parameter - digital.constellation_qpsk().base()
I still get the following error:
Using Volk machine: ssse3_64
Traceback (most recent call last):
  File "/home/lupinox/Desktop/radiotests/top_block.py", line 248, in <module>
    tb = top_block()
  File "/home/lupinox/Desktop/radiotests/top_block.py", line 145, in __init__
    self.howto_phase_correction_vcvc_0 = howto.phase_correction_vcvc(2, 4, 90, 0.01, 0.01, 0, digital.constellation_qpsk().base())
  File "/usr/local/lib/python2.7/dist-packages/howto/howto_swig.py", line 557, in phase_correction_vcvc
    return _howto_swig.phase_correction_vcvc(*args, **kwargs)
TypeError: in method 'phase_correction_vcvc', argument 7 of type 'digital_constellation_sptr'

The constellation block has been installed properly, the same argument works perfectly with the lms_dd_equalizer block. Any suggestions as to what could be wrong here?

Thank you,
--
Srinagesh Sharma
University of Michigan, Ann Arbor

Re: [Discuss-gnuradio] gr_sync_block question

On Sat, Mar 31, 2012 at 07:52, Tom Rondeau <tom@trondeau.com> wrote:
> On Fri, Mar 30, 2012 at 2:58 PM, Josh Blum <josh@joshknows.com> wrote:
>> On 03/30/2012 11:23 AM, Nowlan, Sean wrote:

>>> Do objects that extend gr_sync_block *require* that their work
>>> function *always* returns as many items as the scheduler asked in
>>> noutput_items, except for the case when a block may be completely
>>> finished producing items?
>>
>> Returning 0 or -1 will tell the block executor code to stop.
>>
>> -Josh
>
> Just to clarify, a block can legitimately return 0; it just means that
> it didn't produce any output, but it will try again.

To clarify even further--a *source* block that returns 0 samples will
be treated as done, for other blocks it is ok.

Johnathan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-Trellis FSM

great catch!

It appears that in the constructor we (ie, I) forgot to close the file...

I will submit a patch ASAP, but in the meantime, please add

fclose(fsmfile);

just before

generate_PS_PI();
generate_TM();

in the fsm constructor fsm::fsm(const char *name)
in gr-trellis/src/lib/fsm.cc

remake reinstall and test.

Please let us know if this fixes your problem.

Achilleas

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_sync_block question

On Fri, Mar 30, 2012 at 2:58 PM, Josh Blum <josh@joshknows.com> wrote:
>
>
> On 03/30/2012 11:23 AM, Nowlan, Sean wrote:
>> Do objects that extend gr_sync_block *require* that their work
>> function *always* returns as many items as the scheduler asked in
>> noutput_items, except for the case when a block may be completely
>> finished producing items? What does the scheduler do if the (number
>> of items returned) < noutput_items? Does it ever try calling the work
>> function again?
>>
>
> You can return any number of items between 1 and noutput_items. The
> scheduler will simply call work again with any items that werent
> consumed + extra that accumulated into the input buffers in the interim
> time.
>
> Returning 0 or -1 will tell the block executor code to stop.
>
> -Josh

Just to clarify, a block can legitimately return 0; it just means that
it didn't produce any output, but it will try again.

A -1 will cause this block to stop. If the block is a source and it
produces -1, it will stop the flowgraph completely.

Tom

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Discuss-gnuradio] gnuradio build on Lion OSX 10.7.3 64-bit fails

Thank you Michael! With CMAKE and instructions here http://lists.gnu.org/archive/html/discuss-gnuradio/2012-03/msg00419.html
I was able to build gr succesfully :) Now to wait for my rtl-sdr stick.. hi! :-)

73

Mikko, OH2FXD

On Mar 31, 2012, at 4:57 PM, Michael Dickens wrote:

> Mikko - It looks like you're using the GNU Autotools for building, yes? If so, try using CMake instead; 'volk' in particular compiles must more robustly using CMake. I don't know that I've ever gotten volk to compile using GNU Autotools, but I've almost never had an issue when using CMake. Hope this helps! - MLD
>
> On Mar 31, 2012, at 9:36 AM, Mikko Lähteenmäki wrote:
>
>> Hello, I have following environment:
>>
>> Newest Xcode + homebrew port for other needed software/libs.
>> gr is installed via SVN.
>>
>> When running make I get this problem which I cant pass:
>>
>> Making all in hid
>> Makefile:935: *** extraneous `else'. Stop.
>> make[5]: *** [all-recursive] Error 1
>> make[4]: *** [all] Error 2
>> make[3]: *** [all-recursive] Error 1
>> make[2]: *** [all] Error 2
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>>
>> and make check produces this error message:
>>
>> dyld: Symbol not found: _volk_machine_sse2_32
>> Referenced from: /Users/ifreq/gnuradio/volk/lib/.libs/libvolk.0.dylib
>> Expected in: flat namespace
>> in /Users/ifreq/gnuradio/volk/lib/.libs/libvolk.0.dylib
>> /bin/sh: line 1: 65660 Trace/BPT trap: 5 ${dir}$tst
>>
>>
>> Waiting for possible fix, thanks in advance! :-)
>
>
> _______________________________________________
> 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] [discuss-gnuradio]ofdm sync using only one preamble in gnuradio example benchmark_tx.py and benchmark_rx.py

On Tue, Mar 27, 2012 at 10:29 PM, Alex Zhang <cingular.alex@gmail.com> wrote:
> Hi Tom,
>
> Thanks for the reply.
> In the ofdm_sync_pn.py, I see that a matched filter is used, after the
> timing metric is obtained based on the correlation of the two halves of the
> preamble. I understand this matched filter is trying to find the end of the
> plateau of the metric and get the smooth peak. But I am a little confused
> with the length of this matched filter.
> In the code, the length of this matched filter is set as equal to cp_length.
> But in T.M.Schmidl's paper(page 1615), the plateau length is equal to the
> cp_length minus the channel impulse response length. I am thinking, without
> counting the channel response length, can we get the peak accurately,
> especially in multipath environment?

It's been so long since I've looked closely at that. You could be
right. Test it and see and let us know the results.

Tom

> On Sun, Mar 25, 2012 at 12:40 PM, Tom Rondeau <tom@trondeau.com> wrote:
>>
>> On Sat, Mar 24, 2012 at 8:52 PM, Alex Zhang <cingular.alex@gmail.com>
>> wrote:
>> > Hi Gurus,
>> >
>> > I just want to make sure how the current gnuradio ofdm exampel is
>> > doing synchronization.
>> > According to T. M. Schmidl and D. C. Cox, "Robust Frequency and
>> > Timing  Synchonization for OFDM," IEEE Trans. Communications, vol.
>> > 45, no.
>> > 12, 1997.
>> > When, estimating the carrier frequency offset at the receiver, if the
>> > phase
>> > difference between the two halves of the 1st training symbol is
>> > guaranteed
>> > to be less than PI, then the frequency offset estimate can derived by
>> > Phi/(Pi*T). In this situation, the even PN sequencies of the second
>> > training
>> > symbol would not be needed. Otherwise, the actual frequency offset would
>> > be
>> >
>> > Phi/(Pi*T)  + 2*z/T
>> >  and the z can be estimated by some optimization algorithm, using both
>> > of
>> > the training symbols. Also, the paper mentioned that the odd frequencies
>> > of
>> > the second training symbol can be used to measure the sub-channels.
>> >
>> > However, I find that only one training symbol is generated to act as
>> > preamble at the ofdm transmitter. And on the receiver, it seems that
>> > only
>> > one preamble is used to estimate the timing peak and the frequency
>> > offset.
>> > Is the current implementation assuming that the frequency is less than
>> > PI?
>> > Or anything I missed?
>> >
>> > Looking forward to your input!
>> > --
>> >
>> > Alex,
>> > Dreams can come true – just believe.
>>
>>
>> Alex,
>>
>> Take a look at the presentation we put together here:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Wireless
>>
>> It explains the synchronization process. Basically, the single
>> preamble is made up of two identical sections, so the correlation is
>> done between those two sections to get the timing and fine frequency
>> estimate. Since this preamble is known, we also use it to handle the
>> coarse frequency (number of bins) offset.
>>
>> Tom
>
>
>
>
> --
>
> Alex,
> Dreams can come true – just believe.
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dbpsk on gnuradio-3.5 and Ubuntu 11.10

On Thu, Mar 29, 2012 at 10:04 AM, Jon Watson <jon_watson@rocketmail.com> wrote:
> All,
>
> I have been playing with two simple flow-graphs in gnuradio-companion, one
> for dbpsk transmitter and other for dbpsk receiver. The transmitter
> flow-graph is:
>
> vector source -- > packet encoder -- > dpsk modulator -- > uhd: usrp sink
>
> The receiver flow-graph is:
>
> uhd: usrp source --> low-pass filter --> dpsk demodulator --> packet decoder
> --> file sink
>
> The vector source is given a vector {10,20,30} as input, repeat is set to
> "yes"; in the packet encoder, samples/symbols is set to 8,  bits/symbols is
> set to 1 (because dbpsk scheme is to be used), pad for usrp is set to "yes"
> and payload is set to "0"; in the dpsk modulator, samples/symbols is set to
> 8 and all other parameters are left unchanged.
>
> At the receiver, I use matching/appropriate parameters inside the dpsk
> demodulator and low-pass filter blocks. And the sampling rate is set to be
> 1M Sps on both transmitter and receiver.
>
> Now, the issue is that I do not receive any decoded symbols in the file
> sink. Previously, when I was running the two flow-graphs on two computers
> with Ubuntu 11.04 and gnuradio-3.4 on them, everything was just fine, but as
> soon as I have upgraded the OS and gnuradio to 11.10 and 3.5 versions, I do
> not get anything in the file sink.
>
> Could someone provide a suggestion in this regard?
>
> Thanks.
> Jon

Jon,

I'm not sure why this would change between 3.4 and 3.5, but my guess
is that it's something to do with the frequency offset, which tends to
be the biggest problem with these things. I've attached a GRC example
that runs what you want in a loopback simulation (you need gr-qtgui
installed for this). It looks good here, but I haven't tried going
over the air. This was just to make sure the data and everything were
passing through the algorithm blocks correctly.

Try figuring out what the frequency difference is between your two
USRPs (to about 100 Hz or so) and correct either the transmitter or
receiver to more closely match them up.

Also, when you were using 3.4, were you using UHD or libusrp(2)?

Tom

Re: [Discuss-gnuradio] gnuradio build on Lion OSX 10.7.3 64-bit fails

Mikko - It looks like you're using the GNU Autotools for building, yes? If so, try using CMake instead; 'volk' in particular compiles must more robustly using CMake. I don't know that I've ever gotten volk to compile using GNU Autotools, but I've almost never had an issue when using CMake. Hope this helps! - MLD

On Mar 31, 2012, at 9:36 AM, Mikko Lähteenmäki wrote:

> Hello, I have following environment:
>
> Newest Xcode + homebrew port for other needed software/libs.
> gr is installed via SVN.
>
> When running make I get this problem which I cant pass:
>
> Making all in hid
> Makefile:935: *** extraneous `else'. Stop.
> make[5]: *** [all-recursive] Error 1
> make[4]: *** [all] Error 2
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> and make check produces this error message:
>
> dyld: Symbol not found: _volk_machine_sse2_32
> Referenced from: /Users/ifreq/gnuradio/volk/lib/.libs/libvolk.0.dylib
> Expected in: flat namespace
> in /Users/ifreq/gnuradio/volk/lib/.libs/libvolk.0.dylib
> /bin/sh: line 1: 65660 Trace/BPT trap: 5 ${dir}$tst
>
>
> Waiting for possible fix, thanks in advance! :-)

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio build on Lion OSX 10.7.3 64-bit fails

Terve Mikko,

Have you tried to remove/reposition the extraneous `else' and build again?

Patrik
----- Original Message -----
From: "Mikko Lähteenmäki" <ifreq@deviate.fi>
To: <discuss-gnuradio@gnu.org>
Sent: Saturday, March 31, 2012 16:36
Subject: [Discuss-gnuradio] gnuradio build on Lion OSX 10.7.3 64-bit fails

> Hello, I have following environment:
>
> Newest Xcode + homebrew port for other needed software/libs.
> gr is installed via SVN.
>
> When running make I get this problem which I cant pass:
>
> Making all in hid
> Makefile:935: *** extraneous `else'. Stop.
> make[5]: *** [all-recursive] Error 1
> make[4]: *** [all] Error 2
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> and make check produces this error message:
>
> dyld: Symbol not found: _volk_machine_sse2_32
> Referenced from: /Users/ifreq/gnuradio/volk/lib/.libs/libvolk.0.dylib
> Expected in: flat namespace
> in /Users/ifreq/gnuradio/volk/lib/.libs/libvolk.0.dylib
> /bin/sh: line 1: 65660 Trace/BPT trap: 5 ${dir}$tst
>
>
> Waiting for possible fix, thanks in advance! :-)
>
>
> 73
>
> Mikko, OH2FXD
>
> _______________________________________________
> 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 update of GNU Radio

On 03/31/2012 09:33 AM, frankist wrote:
> Hi,
>
> I am using the computer of my university lab which had the 3.4.1 version of
> GNU Radio installed. I decided to download the build-gnuradio script from
> the gnuradio.org/ website. I installed the newest version and now every time
> I use the USRP it gives me this error:
>
> RuntimeError:
> Please update the firmware and FPGA images for your device. See the
> application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 9 but got 7:
> The FPGA build is not compatible with the host code build.
>
> This seems to be a problem of multiple builds, however the build-gnuradio
> script says that it will remove any old version of gnuradio so I don't
> know... Anyway, one possible solution would be eliminating every gnuradio
> file from the usr/local/share, etc. and install everything again. However, I
> am not the owner of the computer so I don't have permission to delete this
> files.
>
> So the only solution I have is making this work with the 2 versions
> installed I think. Isn't there a way to do this?
The build-gnuradio script updates UHD, as well as Gnu Radio, which means
that if there was a protocol version change, you'll need to update
your N210 firmware as well:

http://files.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-on-board-flash-usrp-n-series-only

The build-gnuradio script *could* update the firmware
semi-automatically, if people are interested, I can add this
functionality to the
"firmware download" part of the script. It could prompt you and ask
if you want to update the firmware for your devices. This would be
limited to N210, and maybe USRP2.

--
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] [USRP-users] Gnu Radio apps freezes (locks up)

On Thu, Mar 29, 2012 at 6:04 AM, Rickard Radio <rickardradio@gmail.com> wrote:
>
> On Mar 29, 2012, at 3:26 AM, Tom Rondeau wrote:
>
>> On Wed, Mar 28, 2012 at 10:02 AM, Rickard Radio <rickardradio@gmail.com> wrote:
>>> Hi list,
>>>
>>> After I upgraded to latest Gnu Radio 3.5.2, and latest UHD (and images), GR applications just freeze when running. No warnings, error messages or overflows etc. Just freeze.
>>> A simple FFT plot directly on received samples from the USRPN210 just freezes after some seconds, or minutes (depending on the sample rate), although the load on the machine is not high. Need to kill GR-app and restart it, with the same problem occurring again.
>>>
>>> This has never been a problem with earlier versions of GR/UHD, from about 6 months ago.
>>> The freezing happens quicker with high sample rate setting but also with lower, eventually. No overflows happen (which was possible to get before with too high sample rates or load, etc.)
>>>
>>> The USRPN210 stops sending samples to the computer at the same moment as GnuRadio freezes (as observed on the system monitor).
>>>
>>> Same thing happen on two identical laptops running Ubuntu 10.10 (also upgraded it from 10.04). Not sure if its a strict GnuRadio problem (since it worked before), UHD, or some problem with the Ubuntu Linux 10.10. It work(ed) flawlessly with another machine on OSX (before I tried to upgrade GR on it but then got stuck...) with identical UHD version and images.
>>>
>>> Installation of UHD+GnuRadio with the automatic linux script runs without any problems, as before, no errors or warnings.
>>>
>>> Any de-freezing help or clues appreciated!
>>>
>>> Rickard
>>
>> Rickard,
>>
>> Just to be clear. When you install 3.5.2 from the tarball, it freezes.
>> When you use the build-gnuradio, everything works fine?
>>
>> What's your machine?
>>
>> Tom
>
> Tom,
>
> The installation with build-gnuradio script works just fine, as before (no tarballs).
> Same result on both laptops, Acer Aspire TimelineX with i3 processors (2.26 GHz),  running Ubuntu 10.10.
> I did not have this problem earlier with Ubuntu 10.04. Or on a Mac with OS X (with the source from git).  Could Ubuntu 10.10 cause the problem somehow?
>
> Note: Halting/freezing only happens when running an application (with the N210) as a receiver. (Not transmitter, see below.)
> The flow of receiving samples just halts after a while and the application freezes/halts (as a consequence).
> This happen sooner with high sampling rate (after a few seconds with 25MSPS), but eventually also with a bit lower sample rates. The CPU's are not overwhelmed (< 50%).
> It happens even if the UHD usrp source is connected directly to a null sink only. I do not get any overflows before the halt.
> In fact, I cannot even provoke a continuos stream of overflows since the reception just halts instead of producing overflows, which was the result earlier.
>  GnuRadio itself does not freeze as a whole (like the grc in the background), just the running application, which I then need to abort.
>
> Strangely enough, this "freezing/halting" does NOT happen when transmitting, correspondingly, even with high transmit sample rates such as 25 MSPS (or now possible even with 50MSPS with 8 bit/samples!). Then it works just fine - even without underruns (when using just a file source).
>
>
> / Rickard

Rickard,

Thanks for the data. Unfortunately, I have no idea what to make of
this. There isn't that much difference between the last release
(3.5.2.1) and what you get using the build-gnuradio script. That just
grabs the latest master version from our git repo, and we haven't done
all that much since the release. That really doesn't make a lot of
sense.

How's your git? If you're comfortable doing so, can you check out the
v3.5.2.1 tag on git and try that one instead of the tarball release?

Thanks,
Tom

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio build on Lion OSX 10.7.3 64-bit fails

Hello, I have following environment:

Newest Xcode + homebrew port for other needed software/libs.
gr is installed via SVN.

When running make I get this problem which I cant pass:

Making all in hid
Makefile:935: *** extraneous `else'. Stop.
make[5]: *** [all-recursive] Error 1
make[4]: *** [all] Error 2
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

and make check produces this error message:

dyld: Symbol not found: _volk_machine_sse2_32
Referenced from: /Users/ifreq/gnuradio/volk/lib/.libs/libvolk.0.dylib
Expected in: flat namespace
in /Users/ifreq/gnuradio/volk/lib/.libs/libvolk.0.dylib
/bin/sh: line 1: 65660 Trace/BPT trap: 5 ${dir}$tst

Waiting for possible fix, thanks in advance! :-)

73

Mikko, OH2FXD

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem with update of GNU Radio

Hi,

I am using the computer of my university lab which had the 3.4.1 version of
GNU Radio installed. I decided to download the build-gnuradio script from
the gnuradio.org/ website. I installed the newest version and now every time
I use the USRP it gives me this error:

RuntimeError:
Please update the firmware and FPGA images for your device. See the
application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 9 but got 7:
The FPGA build is not compatible with the host code build.

This seems to be a problem of multiple builds, however the build-gnuradio
script says that it will remove any old version of gnuradio so I don't
know... Anyway, one possible solution would be eliminating every gnuradio
file from the usr/local/share, etc. and install everything again. However, I
am not the owner of the computer so I don't have permission to delete this
files.

So the only solution I have is making this work with the 2 versions
installed I think. Isn't there a way to do this?
--
View this message in context: http://old.nabble.com/Problem-with-update-of-GNU-Radio-tp33544947p33544947.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

Re: [Discuss-gnuradio] Strange problem when using build-gnuradio script

On 03/31/2012 03:36 AM, Alick Zhao wrote:
> On Tue, 27 Mar 2012 17:06:49 -0400, Marcus D. Leech wrote:
>> However, it seems that the pre-requisites installer for UBuntu 10.X is
>> asking for installation of "liborc" (I added that the other day), and
>> that causes the pre-requisites install to fail for everything. I've
>> removed that in the pre-requisites. Please try again.
>>
>> I've also added the "--ignore-missing" option to the apt-get.
>>
>>
> I recently install gnuradio with build-gnuradio on Ubuntu 11.10, and
> liborc also cause the pre-requisites apt-get install to fail for all.
> After some apt-cache search, I find the package name on 11.10 is
> liborc-0.4-0 indeed.
>
> [1] https://launchpad.net/ubuntu/oneiric/i386/liborc-0.4-0
>
Thanks, fixed and pushed.

--
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] Strange problem when using build-gnuradio script

On Tue, 27 Mar 2012 17:06:49 -0400, Marcus D. Leech wrote:
>
> However, it seems that the pre-requisites installer for UBuntu 10.X is
> asking for installation of "liborc" (I added that the other day), and
> that causes the pre-requisites install to fail for everything. I've
> removed that in the pre-requisites. Please try again.
>
> I've also added the "--ignore-missing" option to the apt-get.
>
>

I recently install gnuradio with build-gnuradio on Ubuntu 11.10, and
liborc also cause the pre-requisites apt-get install to fail for all.
After some apt-cache search, I find the package name on 11.10 is
liborc-0.4-0 indeed.

[1] https://launchpad.net/ubuntu/oneiric/i386/liborc-0.4-0

--
alick

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] A interface between UHD source code function send() and benchmark?

Hi，

  Is there anyone who use the uhd source code like tx_burst.cpp, use the function send(buffs, samples_to_send, md, timeout) to send data, I use the tx_burst.cpp and rx_samples_to_file.cpp to transmit and receive data, but the received data is without rules. 

  I think the data must be deal with like modulated and framer packed as in benchmark,  I want to circular call the function send() and recv() in a source file and convert the received data in form of which it to be send, like benchmark_tx and benchmark_rx, but I have no idea how to do a interface between function send() and benchmark.

  Maybe it is means I want to convert the data form from stream to packet, is it right? hey!

  Is there anyone do the same work? would you  so nice to give me a hand, thanks very much!

--
Ding Yuzhen
Beijng University of Posts and Telecommunications
School of computer science
E-mail：baobaonanpo@gmail.com 

[Discuss-gnuradio] Customized packet sink

Hey All,
     Is the gr_packet_sink.cc capable of handling a customized packet format structure or would one have to come up with a customized packet sink structure of ones own ignoring the complexity of access code/ sync vector ?

Thanks,
Anay.

Re: [Discuss-gnuradio] Pack k bits?

Any comment on this? I think the current implementation of gr_packed_to_unpacked_bb(int k, gr_endianness_t endianness) puts bits in an incorrect order when k > 1 and endianness = gr.GR_LSB_FIRST.

 

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org] On Behalf Of Nowlan, Sean
Sent: Wednesday, March 28, 2012 9:26 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Pack k bits?

 

I think it would work if I modified gnuradio/gnuradio-core/src/lib/gengen/gr_packed_to_unpacked_XX.cc.t (line 119) to the following:

 

x = (x>>1) | (get_bit_le(in, index_tmp) << (d_bits_per_chunk - 1) );

 

-OR-

 

x |= get_bit_le(in, index_tmp) << j;

 

I haven’t tested, but I think these are functionally equivalent. Does this change sound reasonable?

 

-- Sean

 

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org] On Behalf Of Nowlan, Sean
Sent: Wednesday, March 28, 2012 8:49 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Pack k bits?

 

I want to take an input stream of bytes in which only one LSB is relevant (e.g., the output of the GR GLFSR block) and pack these bits into bytes with k relevant bits. For example, I’d like to take a stream of raw bits generated by the GLFSR and feed them to an M-PSK modulator, which requires chunks with k=log2(M) bits. Unfortunately I haven’t found this to be straightforward. There is no “pack_k_bits” module that I could find, so I tried using  unpacked_to_packed_bb and packed_to_unpacked_bb. They are not working like I would expect. For instance, here’s an example in Python:

 

…

data = [1,0,1,0, 0,0,1,0, 1,1,1,0, 0,1,1,0]                                # 45 67

self.source = gr.vector_source_b(data, False, 1)

self.pack = gr.unpacked_to_packed_bb(1, gr.GR_LSB_FIRST)

self.unpack = gr.packed_to_unpacked_bb(2, gr.GR_LSB_FIRST)      # stuff 2 bits into LSB of each output byte

self.head = gr.head(gr.sizeof_char, 8)                              # should have 16/2 = 8 output bytes

self.sink = gr.file_sink(gr.sizeof_char, “out.bin”)

self.connect(self.source, self.pack, self.unpack, self.head, self.sink)

…

 

This gives the following:

$ hexdump -C out.bin

0000000  02 02 00 02 03 02 01 02                           |……..|

0000008

 

But I would expect the following:

0000000  01 01 00 01 03 01 02 01                           |……..|

0000008

 

Notice that the two least significant bits are in reverse order. Any clue what’s going on here?

 

Thanks,

Sean

Re: [Discuss-gnuradio] gr_sync_block question

On 03/30/2012 11:23 AM, Nowlan, Sean wrote:
> Do objects that extend gr_sync_block *require* that their work
> function *always* returns as many items as the scheduler asked in
> noutput_items, except for the case when a block may be completely
> finished producing items? What does the scheduler do if the (number
> of items returned) < noutput_items? Does it ever try calling the work
> function again?
>

You can return any number of items between 1 and noutput_items. The
scheduler will simply call work again with any items that werent
consumed + extra that accumulated into the input buffers in the interim
time.

Returning 0 or -1 will tell the block executor code to stop.

-Josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-Trellis FSM

I've implemented a Manchester Decoder via an FSM using the combined Viterbi
algorithm in gr-trellis, and its working great decoding my signal. However,
I've noticed that after ~1000 times running (see code), I get an error...

what(): fsm::fsm(const char *name): file open error

I'd expect this to happen in case of a buffer overrun or RAM limitation, but
even if I reduce the time between packets, I get the same error.

Thanks for your help.

***************************************************************
Manchester_FSM_test.py
***************************************************************
#!/usr/bin/env python

from gnuradio import gr
from gnuradio import trellis
from gnuradio import eng_notation
import math
import sys
#import fsm_utils
from gnuradio.eng_option import eng_option
from optparse import OptionParser

def main():
for i in range(2005):

x=manchester([1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0])
print i

def run_test (f,Kb,bitspersymbol,K,dimensionality,constellation,data_in):
tb = gr.top_block ()

src = gr.vector_source_s(data_in)

#src_head = gr.head (gr.sizeof_short,Kb/16) # packet size in shorts
#s2fsmi = gr.packed_to_unpacked_ss(bitspersymbol,gr.GR_MSB_FIRST) #
unpack shorts to symbols compatible with the FSM input cardinality
#enc = trellis.encoder_bb(f,0) # initial state = 0
#mod = gr.chunks_to_symbols_sf(constellation,dimensionality)
va =
trellis.viterbi_combined_sb(f,K,0,-1,dimensionality,constellation,trellis.TRELLIS_EUCLIDEAN)
# Put -1 if the Initial/Final states are not set.
dst = gr.vector_sink_b();
tb.connect (src,va,dst)

tb.run()

return dst.data()

def manchester(data_in):

fname="fsm_files/manchester_encoder.fsm"

# system parameters
f=trellis.fsm(fname) # get the FSM specification from a file (will
hopefully be automated in the future...)

Kb=64
bitspersymbol = int(round(math.log(f.I())/math.log(2))) # bits per FSM
input symbol
K=Kb/bitspersymbol # packet size in trellis steps

dimensionality = 2
constellation = [0, 0,0,1,1,0,1,1]
if len(constellation)/dimensionality != f.O():
sys.stderr.write ('Incompatible FSM output cardinality and
modulation size.\n')
#sys.exit (1)

(data)=run_test(f,Kb,bitspersymbol,K,dimensionality,constellation,data_in) #
run experiment with different seed to get different noise realizations
return data

if __name__ == '__main__':
main()

***************************************************************
Manchester_encoder.fsm
***************************************************************
2 2 4

0 1
0 1

1 2
1 2

Manchester Encoder
--
View this message in context: http://old.nabble.com/gr-Trellis-FSM-tp33544924p33544924.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] gr_sync_block question

Do objects that extend gr_sync_block *require* that their work function *always* returns as many items as the scheduler asked in noutput_items, except for the case when a block may be completely finished producing items? What does the scheduler do if the (number of items returned) < noutput_items? Does it ever try calling the work function again?

 

Thanks,

Sean

[Discuss-gnuradio] Reminder for the GSoC

There's one week left to submit applications (due April 6) as students
to this year's GSoC. I have heard that a number of people already
have, so this is just a gentle reminder to come and participate this
year!

Since we are participating under the larger GNU project's umbrella, we
will follow their student application for consistency. Our webpage has
been updated to reflect this.
http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC

Thanks!
Tom

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fw: [amateur-DSN] 8.4GHz LNA Boards

FYI,

Patrik

----- Original Message -----
From: "l_moline" <wa7skt@comcast.net>
To: <amateur-DSN@yahoogroups.com>
Sent: Monday, March 26, 2012 18:07
Subject: [amateur-DSN] 8.4GHz LNA Boards

> Hello,
> If anyone is interested in boards for an 8.4GHz LNA please contact
> Downeast Microwave. They may generate boards if there is enough interest.
> Thanks!
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
> http://groups.yahoo.com/group/amateur-DSN/

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] benchmark_tx.py timing

Hello,

since there is an option for discontinuous transmission for the benchmark_tx.py script, I was wondering if the signal is really being transmitted continuously when the option is not enabled or if there still is some time division scheme involved.

Thanks in advance.

Peter

Re: [Discuss-gnuradio] RTL2832 ($20 USB SDR) support now in gr-baz

Hi Rafael,

The intention for upstream submission is certainly there, however time is
not quite... hopefully soon.

Some blocks need optimisation, cleaning and re-styling - if anyone wishes to
help by sending a patch, that would be wonderful (I just received my first a
little while ago!).

Re: getting the dongle, I happened to get lucky on eBay. I can only suggest
to keep searching! Good luck.

Kind regards,
Balint

PS: Lots happening here: http://www.reddit.com/r/RTLSDR/
And
http://www.reddit.com/r/amateurradio/comments/rjp8v/20_ultracheap_software_d
efined_radio_with_rtl2832/

> -----Original Message-----
> From: discuss-gnuradio-bounces+balint256=gmail.com@gnu.org
> [mailto:discuss-gnuradio-bounces+balint256=gmail.com@gnu.org] On Behalf Of
> Rafael Diniz
> Sent: Friday, 30 March 2012 3:43 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] RTL2832 ($20 USB SDR) support now in gr-
> baz
>
> Indeed, F****ng awesome!
> Do you plan to submit upstream your gr-baz?
>
> People, in dealextreme store the dongle is sold out.
> I do not want to start an off-topic trend, but could you please mail me in
> private where are you buying such dongle?
>
> Best regards,
> Rafael Diniz
>
> > Awesome! I'm still waiting on my RTL-based card to arrive via
> > snail-mail from an unknown factory on the other side of the world.
> > Will test when it arrives!
> >
> > From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org
> > [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org]
> > On Behalf Of Balint Seeber
> > Sent: Thursday, March 29, 2012 11:22 AM
> > To: discuss-gnuradio@gnu.org
> > Subject: [Discuss-gnuradio] RTL2832 ($20 USB SDR) support now in
> > gr-baz
> >
> > Hi folks,
> >
> > I've just added RTL2832 support to gr-baz with support for both tuners
> > (Elonics E4000 and Fitipower FC0013).
> >
> > If you're not aware, this is sold as a DVB-T USB receiver for ~$20,
> > which is a pretty decent price for a device that can do general
> > purpose SDR at
> > 3.2 MHz and 8-bits! The journey starts with Antti
> > Palosaari<http://thread.gmane.org/gmane.linux.drivers.video-input-infr
> > astructure/44461/focus=44461> who discovered it can be put in a mode
> > where it streams baseband data directly over USB (for analog FM
> > demodulation in software). This resulted in Steve Markgraf's
> > rtl-sdr<http://sdr.osmocom.org/trac/wiki/rtl-sdr>
> > user-space capture utility over at Osmocom (see the Osmocom page to
> > find compatible devices).
> >
> > I've taken that source and created a fully-featured GNU Radio Source
> > block
> > 'baz.rtl_source_c'<http://wiki.spench.net/wiki/Gr-baz#rtl_source_c>
> > (with GRC block) that outputs complex values, and allows adjustment of
> > frequency, sample rate and LNA gain. There is also an optional
> > automatic tuner mode control for the E4000. If you also like using
> > Winrad/HDSDR/WRplus, my ExtIO
> > plugin<http://wiki.spench.net/wiki/USRP_Interfaces> now has support
> > for the device too. The Source block performs internal multi-threaded
> > buffering for smoother performance (this might be over-engineered, but
> it seemed to help with the ExtIO plugin).
> >
> > You can get the source code from my
> > SVN<http://svn.spench.net/main/gr-baz/> or
> > github<https://github.com/balint256/gr-baz> (though please visit the
> > info page<http://wiki.spench.net/wiki/Gr-baz#rtl_source_c> first for
> > more info/pre-reqs - e.g. libusb-1.0, etc). It's experimental, and not
> > the prettiest because I actually ported it back from the ExtIO plugin,
> > but it works for me and if you want to help test/clean it up then that
> > would be very much appreciated!
> >
> > To see it in action, have a peek here: http://youtu.be/FUQd9HOVTk8
> >
> > Balint @spenchdotnet<http://twitter.com/spenchdotnet>
> > _______________________________________________
> > 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 command fails for GR v3.5.2.1 on Mac OSX

Hi Rickard - I have about your setup, and it works well for me. I use MacPorts for all of the background dependencies, then I install UHD, then GNU Radio, both from GIT. I'm using Mac OS X 10.6.8 64-bit, XCode 3.2.3 (gcc 4.2.1), and MacPorts' Python 2.7; I find that MacPorts' Python 2.6 generates occasional threading errors. My "usual" way of doing things is:

0) uninstall GNU Radio
1) uninstall UHD
2) cd into $prefix (/usr/local for me), and remove cruft
3) cd UHD, git pull, rm -rf the build, cmake, make, install
4) cd GNU Radio, git pull, rm -rf the build, cmake, make, install

Although the above takes some effort, it almost always works. Most of the time, I find that "rm -rf the build" takes care of the issues such as what you wrote about; occasionally the GIT master has a build issue, but that's pretty rare. So, you -can- get UHD + GNU Radio working with your setup; just keep persisting. Good luck! - MLD

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Make command fails for GR v3.5.2.1 on Mac OSX

On 29 mar 2012, at 19.48, Josh Blum wrote:

On 03/29/2012 10:26 AM, Rickard Radio wrote:

Dear list,

I was trying to upgrade my UHD+ GnuRadio package to latest release (v3.5.2.1) on Mac OS X (10.6.8).  Dependencies are as before from Macports.

Everything with the UHD went fine, using cmake, followed by make and make install.

Cmake for GR also went fine (sources via git), but make command fails (see attched log file) for some reason?!

Seems to be something relating to "Generating gengen_swig_doc.i" but I don't understand this error or how to fix it.

This procedure has worked for me before on Mac OS X.

Any ideas what causing the error and how to fix it?

Its a bug in the python parser or what the parser is expecting. Can you
post the doxygen version?

For reference, ubuntu 11.10 has doxygen 1.7.4

My OSX doxygen version was 1.7.5.1_1, now upgraded it to 1.8.0_0 but the error remains. Furthermore, I was using python26, tried now instead with python27 but it resulted in the same error. With python27, however, grc, gr-qtgui, and gr-wxgui becomes disabled (don't know why) when building with cmake and python26 worked with an older GR version.  

Any other idea?

Traceback (most recent call last):
 File "/Users/rickard/GnuRadio/docs/doxygen/swig_doc.py", line 294, in
<module>
   make_swig_interface_file(di, swigdocfilename,
custom_output=custom_output)
 File "/Users/rickard/GnuRadio/docs/doxygen/swig_doc.py", line 222, in
make_swig_interface_file
   make_func = di.get_member(make_name(block.name()), DoxyFunction)
 File "/Users/rickard/GnuRadio/docs/doxygen/doxyxml/base.py", line 157,
in get_member
   raise member()
doxyxml.base.Duplicate
make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1
make[1]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all]
Error 2
make: *** [all] Error 2
~/GnuRadio/build>

I'm guessing the parser is yielding NoSuchMember

member = self._get_dict_members(cat).get(first, self.NoSuchMember)
       # Raise any errors that are returned.
       if member in set([self.NoSuchMember, self.Duplicate]):
           raise member()

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [discuss-gnuradio]ofdm sync using only one preamble in gnuradio example benchmark_tx.py and benchmark_rx.py

Resend this mail for some comments. Thanks.

On Tue, Mar 27, 2012 at 9:29 PM, Alex Zhang <cingular.alex@gmail.com> wrote:

Hi Tom,

Thanks for the reply.

In the ofdm_sync_pn.py, I see that a matched filter is used, after the timing metric is obtained based on the correlation of the two halves of the preamble. I understand this matched filter is trying to find the end of the plateau of the metric and get the smooth peak. But I am a little confused with the length of this matched filter. 

In the code, the length of this matched filter is set as equal to cp_length. But in T.M.Schmidl's paper(page 1615), the plateau length is equal to the cp_length minus the channel impulse response length. I am thinking, without counting the channel response length, can we get the peak accurately, especially in multipath environment? 

On Sun, Mar 25, 2012 at 12:40 PM, Tom Rondeau <tom@trondeau.com> wrote:

On Sat, Mar 24, 2012 at 8:52 PM, Alex Zhang <cingular.alex@gmail.com> wrote:
> Hi Gurus,
>
> I just want to make sure how the current gnuradio ofdm exampel is
> doing synchronization.
> According to T. M. Schmidl and D. C. Cox, "Robust Frequency and
> Timing  Synchonization for OFDM," IEEE Trans. Communications, vol. 45, no.
> 12, 1997.
> When, estimating the carrier frequency offset at the receiver, if the phase
> difference between the two halves of the 1st training symbol is guaranteed
> to be less than PI, then the frequency offset estimate can derived by
> Phi/(Pi*T). In this situation, the even PN sequencies of the second training
> symbol would not be needed. Otherwise, the actual frequency offset would be
>
> Phi/(Pi*T)  + 2*z/T
>  and the z can be estimated by some optimization algorithm, using both of
> the training symbols. Also, the paper mentioned that the odd frequencies of
> the second training symbol can be used to measure the sub-channels.
>
> However, I find that only one training symbol is generated to act as
> preamble at the ofdm transmitter. And on the receiver, it seems that only
> one preamble is used to estimate the timing peak and the frequency offset.
> Is the current implementation assuming that the frequency is less than PI?
> Or anything I missed?
>
> Looking forward to your input!
> --
>
> Alex,
> Dreams can come true – just believe.

Alex,

Take a look at the presentation we put together here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Wireless

It explains the synchronization process. Basically, the single
preamble is made up of two identical sections, so the correlation is
done between those two sections to get the timing and fine frequency
estimate. Since this preamble is known, we also use it to handle the
coarse frequency (number of bins) offset.

Tom

--

Alex,

Dreams can come true – just believe.

--

Alex,

Dreams can come true – just believe.

Re: [Discuss-gnuradio] RTL2832 ($20 USB SDR) support now in gr-baz

This kinda thing is gonna be incredibly useful even to us with USRP's.
I've been working on a digital voice mode but without a second
expensive USRP I have no way to know what I'm broadcasting or how
reliable the modulation is. The uses for cheap, semi-disposable SDR's
are limitless!

~Andrew

On Thu, Mar 29, 2012 at 12:43 PM, Rafael Diniz <rafael@riseup.net> wrote:
> Indeed, F****ng awesome!
> Do you plan to submit upstream your gr-baz?
>
> People, in dealextreme store the dongle is sold out.
> I do not want to start an off-topic trend, but could you please mail me in
> private where are you buying such dongle?
>
> Best regards,
> Rafael Diniz
>
>> Awesome! I'm still waiting on my RTL-based card to arrive via snail-mail
>> from an unknown factory on the other side of the world. Will test when it
>> arrives!
>>
>> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org
>> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org] On
>> Behalf Of Balint Seeber
>> Sent: Thursday, March 29, 2012 11:22 AM
>> To: discuss-gnuradio@gnu.org
>> Subject: [Discuss-gnuradio] RTL2832 ($20 USB SDR) support now in gr-baz
>>
>> Hi folks,
>>
>> I've just added RTL2832 support to gr-baz with support for both tuners
>> (Elonics E4000 and Fitipower FC0013).
>>
>> If you're not aware, this is sold as a DVB-T USB receiver for ~$20, which
>> is a pretty decent price for a device that can do general purpose SDR at
>> 3.2 MHz and 8-bits! The journey starts with Antti
>> Palosaari<http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461/focus=44461>
>> who discovered it can be put in a mode where it streams baseband data
>> directly over USB (for analog FM demodulation in software). This resulted
>> in Steve Markgraf's rtl-sdr<http://sdr.osmocom.org/trac/wiki/rtl-sdr>
>> user-space capture utility over at Osmocom (see the Osmocom page to find
>> compatible devices).
>>
>> I've taken that source and created a fully-featured GNU Radio Source block
>> 'baz.rtl_source_c'<http://wiki.spench.net/wiki/Gr-baz#rtl_source_c> (with
>> GRC block) that outputs complex values, and allows adjustment of
>> frequency, sample rate and LNA gain. There is also an optional automatic
>> tuner mode control for the E4000. If you also like using
>> Winrad/HDSDR/WRplus, my ExtIO
>> plugin<http://wiki.spench.net/wiki/USRP_Interfaces> now has support for
>> the device too. The Source block performs internal multi-threaded
>> buffering for smoother performance (this might be over-engineered, but it
>> seemed to help with the ExtIO plugin).
>>
>> You can get the source code from my
>> SVN<http://svn.spench.net/main/gr-baz/> or
>> github<https://github.com/balint256/gr-baz> (though please visit the info
>> page<http://wiki.spench.net/wiki/Gr-baz#rtl_source_c> first for more
>> info/pre-reqs - e.g. libusb-1.0, etc). It's experimental, and not the
>> prettiest because I actually ported it back from the ExtIO plugin, but it
>> works for me and if you want to help test/clean it up then that would be
>> very much appreciated!
>>
>> To see it in action, have a peek here: http://youtu.be/FUQd9HOVTk8
>>
>> Balint @spenchdotnet<http://twitter.com/spenchdotnet>
>> _______________________________________________
>> 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] Error after setting Realtime Scheduling=on

Hi,

I got the following error from gnuradio companion:

GThread-ERROR **: file
/build/buildd/glib2.0-2.30.0/./gthread/gthread-posix.c: line 348
(g_thread_create_posix_impl): error 'Invalid argument' during
'pthread_attr_setschedparam (&attr, &sched)'

>>> Done

Google did not reveal too much to me either.

With kind regards

Mario

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Make command fails for GR v3.5.2.1 on Mac OSX

On 03/29/2012 10:26 AM, Rickard Radio wrote:
> Dear list,
>
> I was trying to upgrade my UHD+ GnuRadio package to latest release (v3.5.2.1) on Mac OS X (10.6.8). Dependencies are as before from Macports.
> Everything with the UHD went fine, using cmake, followed by make and make install.
>
> Cmake for GR also went fine (sources via git), but make command fails (see attched log file) for some reason?!
> Seems to be something relating to "Generating gengen_swig_doc.i" but I don't understand this error or how to fix it.
>
> This procedure has worked for me before on Mac OS X.
> Any ideas what causing the error and how to fix it?
>

Its a bug in the python parser or what the parser is expecting. Can you
post the doxygen version?

For reference, ubuntu 11.10 has doxygen 1.7.4

Traceback (most recent call last):
File "/Users/rickard/GnuRadio/docs/doxygen/swig_doc.py", line 294, in
<module>
make_swig_interface_file(di, swigdocfilename,
custom_output=custom_output)
File "/Users/rickard/GnuRadio/docs/doxygen/swig_doc.py", line 222, in
make_swig_interface_file
make_func = di.get_member(make_name(block.name()), DoxyFunction)
File "/Users/rickard/GnuRadio/docs/doxygen/doxyxml/base.py", line 157,
in get_member
raise member()
doxyxml.base.Duplicate
make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1
make[1]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all]
Error 2
make: *** [all] Error 2
~/GnuRadio/build>

I'm guessing the parser is yielding NoSuchMember

member = self._get_dict_members(cat).get(first, self.NoSuchMember)
# Raise any errors that are returned.
if member in set([self.NoSuchMember, self.Duplicate]):
raise member()

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Make command fails for GR v3.5.2.1 on Mac OSX

~/GnuRadio/build> cmake -DCMAKE_INSTALL_PREFIX=$GR_INSTALL ../
-- Build type not specified: defaulting to release.
-- Extracting version information from version.sh...
-- Extracting version information from git describe...
-- Minimum SWIG version required is 1.3.31
--
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
--
-- Configuring python-support support...
-- Dependency PYTHONLIBS_FOUND = TRUE
-- Dependency SWIG_FOUND = TRUE
-- Dependency SWIG_VERSION_CHECK = TRUE
-- Enabling python-support support.
-- Override with -DENABLE_PYTHON=ON/OFF
--
-- Configuring testing-support support...
-- Dependency CPPUNIT_FOUND = TRUE
-- Enabling testing-support support.
-- Override with -DENABLE_TESTING=ON/OFF
--
-- Configuring volk support...
-- Enabling volk support.
-- Override with -DENABLE_VOLK=ON/OFF
-- 32 overruled
-- Available arches: generic;64;3dnow;abm;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2
-- Available machines: generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_1_64
-- Using install prefix: /Users/rickard/GnuRadio/local
--
-- Configuring doxygen support...
-- Dependency DOXYGEN_FOUND = YES
-- Enabling doxygen support.
-- Override with -DENABLE_DOXYGEN=ON/OFF
--
-- Configuring gruel support...
-- Dependency Boost_FOUND = TRUE
-- Dependency PYTHONINTERP_FOUND = TRUE
-- Enabling gruel support.
-- Override with -DENABLE_GRUEL=ON/OFF
--
-- Configuring gnuradio-core support...
-- Dependency ENABLE_GRUEL = ON
-- Dependency ENABLE_VOLK = ON
-- Dependency Boost_FOUND = TRUE
-- Dependency GSL_FOUND = 1
-- Dependency FFTW3F_FOUND = TRUE
-- Dependency PYTHONINTERP_FOUND = TRUE
-- Enabling gnuradio-core support.
-- Override with -DENABLE_GR_CORE=ON/OFF
-- Loading build date Thu, 29 Mar 2012 14:53:35 into gr_constants...
-- Loading version v3.5.2.1-61-gfc115e6a into gr_constants...
--
-- Python checking for python >= 2.5
-- Python checking for python >= 2.5 - found
--
-- Python checking for Cheetah >= 2.0.0
-- Python checking for Cheetah >= 2.0.0 - found
--
-- Python checking for lxml >= 1.3.6
-- Python checking for lxml >= 1.3.6 - found
--
-- Python checking for pygtk >= 2.10.0
Xlib: extension "RANDR" missing on display "/tmp/launch-xzenxF/org.x:0".
-- Python checking for pygtk >= 2.10.0 - found
--
-- Python checking for numpy
-- Python checking for numpy - found
--
-- Configuring gnuradio-companion support...
-- Dependency ENABLE_GR_CORE = ON
-- Dependency ENABLE_PYTHON = ON
-- Dependency PYTHON_MIN_VER_FOUND = TRUE
-- Dependency CHEETAH_FOUND = TRUE
-- Dependency LXML_FOUND = TRUE
-- Dependency PYGTK_FOUND = TRUE
-- Dependency NUMPY_FOUND = TRUE
-- Enabling gnuradio-companion support.
-- Override with -DENABLE_GRC=ON/OFF
--
-- Configuring gr-atsc support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Enabling gr-atsc support.
-- Override with -DENABLE_GR_ATSC=ON/OFF
--
-- Configuring gr-audio support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Enabling gr-audio support.
-- Override with -DENABLE_GR_AUDIO=ON/OFF
-- checking for module 'alsa'
-- package 'alsa' not found
-- Found jack: /opt/local/lib/libjack.dylib
-- checking for module 'comedilib'
-- package 'comedilib' not found
--
-- Configuring gr-comedi support...
-- Dependency COMEDI_FOUND =
-- Dependency LINUX =
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Disabling gr-comedi support.
-- Override with -DENABLE_GR_COMEDI=ON/OFF
--
-- Configuring gr-digital support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Enabling gr-digital support.
-- Override with -DENABLE_GR_DIGITAL=ON/OFF
--
-- Configuring gr-noaa support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Enabling gr-noaa support.
-- Override with -DENABLE_GR_NOAA=ON/OFF
--
-- Configuring gr-pager support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Enabling gr-pager support.
-- Override with -DENABLE_GR_PAGER=ON/OFF
--
-- Python checking for PyQt4
-- Python checking for PyQt4 - found
--
-- Configuring gr-qtgui support...
-- Dependency Boost_FOUND = TRUE
-- Dependency QT4_FOUND = TRUE
-- Dependency QWT_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Dependency PYTHONLIBS_FOUND = TRUE
-- Dependency PYQT4_FOUND = TRUE
-- Enabling gr-qtgui support.
-- Override with -DENABLE_GR_QTGUI=ON/OFF
--
-- Configuring gr-trellis support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Dependency ENABLE_GR_DIGITAL = ON
-- Enabling gr-trellis support.
-- Override with -DENABLE_GR_TRELLIS=ON/OFF
--
-- Configuring gr-uhd support...
-- Dependency Boost_FOUND = TRUE
-- Dependency UHD_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Enabling gr-uhd support.
-- Override with -DENABLE_GR_UHD=ON/OFF
-- checking for module 'shd'
-- package 'shd' not found
-- Could NOT find SHD (missing: SHD_LIBRARIES SHD_INCLUDE_DIRS)
--
-- Configuring gr-shd support...
-- Dependency Boost_FOUND = TRUE
-- Dependency SHD_FOUND = FALSE
-- Dependency ENABLE_GR_CORE = ON
-- Disabling gr-shd support.
-- Override with -DENABLE_GR_SHD=ON/OFF
--
-- Configuring gr-utils support...
-- Dependency ENABLE_GR_CORE = ON
-- Dependency ENABLE_PYTHON = ON
-- Enabling gr-utils support.
-- Override with -DENABLE_GR_UTILS=ON/OFF
--
-- Configuring gr-video-sdl support...
-- Dependency SDL_FOUND = YES
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Enabling gr-video-sdl support.
-- Override with -DENABLE_GR_VIDEO_SDL=ON/OFF
--
-- Configuring gr-vocoder support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Enabling gr-vocoder support.
-- Override with -DENABLE_GR_VOCODER=ON/OFF
--
-- Configuring gr-fcd support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GR_CORE = ON
-- Dependency ENABLE_GR_AUDIO = ON
-- Enabling gr-fcd support.
-- Override with -DENABLE_GR_FCD=ON/OFF
--
-- Python checking for wx >= 2.8
-- Python checking for wx >= 2.8 - found
--
-- Python checking for numpy
-- Python checking for numpy - found
--
-- Configuring gr-wxgui support...
-- Dependency ENABLE_GR_CORE = ON
-- Dependency ENABLE_PYTHON = ON
-- Dependency NUMPY_FOUND = TRUE
-- Dependency WX_FOUND = TRUE
-- Enabling gr-wxgui support.
-- Override with -DENABLE_GR_WXGUI=ON/OFF
--
-- ######################################################
-- # Gnuradio enabled components
-- ######################################################
-- * python-support
-- * testing-support
-- * volk
-- * doxygen
-- * gruel
-- * gnuradio-core
-- * gnuradio-companion
-- * gr-atsc
-- * gr-audio
-- * gr-digital
-- * gr-noaa
-- * gr-pager
-- * gr-qtgui
-- * gr-trellis
-- * gr-uhd
-- * gr-utils
-- * gr-video-sdl
-- * gr-vocoder
-- * gr-fcd
-- * gr-wxgui
--
-- ######################################################
-- # Gnuradio disabled components
-- ######################################################
-- * gr-comedi
-- * gr-shd
--
-- Using install prefix: /Users/rickard/GnuRadio/local
-- Building for version: v3.5.2.1-61-gfc115e6a / 3.5.3git
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rickard/GnuRadio/build
~/GnuRadio/build>
~/GnuRadio/build> make
[ 4%] Built target volk
[ 5%] Built target test_all
[ 6%] Built target volk_profile
[ 6%] Built target doxygen_target
[ 7%] Built target gruel
[ 7%] Built target test_gruel
[ 7%] Built target _pmt_swig_doc_tag
[ 7%] Built target _pmt_swig_swig_tag
[ 7%] Built target _pmt_swig
[ 8%] Built target pygen_gruel_src_swig_14998
[ 8%] Built target pygen_gruel_src_python_7225f
[ 8%] Built target pygen_gruel_src_python_9a097
Scanning dependencies of target gnuradio-core
[ 8%] Building CXX object gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/general/gr_constants.cc.o
Linking CXX shared library libgnuradio-core.dylib
[ 41%] Built target gnuradio-core
Linking CXX executable gnuradio-config-info
ld: warning: duplicate dylib /opt/local/lib/libboost_date_time-mt.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_program_options-mt.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_filesystem-mt.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_system-mt.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_thread-mt.dylib
[ 41%] Built target gnuradio-config-info
[ 41%] Built target gr_core_rstest
Linking CXX shared library libtest-gnuradio-core.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_date_time-mt.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_program_options-mt.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_filesystem-mt.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_system-mt.dylib
ld: warning: duplicate dylib /opt/local/lib/libboost_thread-mt.dylib
[ 43%] Built target test-gnuradio-core
Linking CXX executable benchmark_dotprod_ccc
[ 43%] Built target benchmark_dotprod_ccc
Linking CXX executable benchmark_dotprod_ccf
[ 43%] Built target benchmark_dotprod_ccf
Linking CXX executable benchmark_dotprod_fcc
[ 43%] Built target benchmark_dotprod_fcc
Linking CXX executable benchmark_dotprod_fff
[ 43%] Built target benchmark_dotprod_fff
Linking CXX executable benchmark_dotprod_fsf
[ 43%] Built target benchmark_dotprod_fsf
Linking CXX executable benchmark_dotprod_scc
[ 44%] Built target benchmark_dotprod_scc
Linking CXX executable benchmark_nco
[ 44%] Built target benchmark_nco
Linking CXX executable benchmark_vco
[ 44%] Built target benchmark_vco
Linking CXX executable gr_core_test_all
[ 44%] Built target gr_core_test_all
Linking CXX executable test_filter
[ 44%] Built target test_filter
Linking CXX executable test_general
[ 44%] Built target test_general
Linking CXX executable test_runtime
[ 44%] Built target test_runtime
Linking CXX executable test_vmcircbuf
[ 44%] Built target test_vmcircbuf
[ 44%] Built target _filter_swig_doc_tag
[ 44%] Built target _general_swig_doc_tag
[ 45%] Built target _gengen_swig_doc_tag
[ 49%] Built target gengen_generated
[ 49%] Built target filter_generated
[ 49%] Built target _gnuradio_core_filter_swig_tag
[ 49%] Built target _runtime_swig_doc_tag
[ 49%] Generating gengen_swig_doc.i
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing error with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing error with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing error with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing problem with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying.
XML parsing error with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up.
XML parsing error with file /Users/rickard/GnuRadio/build/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up.
Traceback (most recent call last):
File "/Users/rickard/GnuRadio/docs/doxygen/swig_doc.py", line 294, in <module>
make_swig_interface_file(di, swigdocfilename, custom_output=custom_output)
File "/Users/rickard/GnuRadio/docs/doxygen/swig_doc.py", line 222, in make_swig_interface_file
make_func = di.get_member(make_name(block.name()), DoxyFunction)
File "/Users/rickard/GnuRadio/docs/doxygen/doxyxml/base.py", line 157, in get_member
raise member()
doxyxml.base.Duplicate
make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1
make[1]: *** [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2
make: *** [all] Error 2
~/GnuRadio/build> Dear list,

I was trying to upgrade my UHD+ GnuRadio package to latest release (v3.5.2.1) on Mac OS X (10.6.8). Dependencies are as before from Macports.
Everything with the UHD went fine, using cmake, followed by make and make install.

Cmake for GR also went fine (sources via git), but make command fails (see attched log file) for some reason?!
Seems to be something relating to "Generating gengen_swig_doc.i" but I don't understand this error or how to fix it.

This procedure has worked for me before on Mac OS X.
Any ideas what causing the error and how to fix it?

BR,
Rickard