[Discuss-gnuradio] FS USRP1 , WBX, LFX
For sale 30 days old USRP1 , WBX, LFX pse direct email -- View this message in context: http://old.nabble.com/FS-USRP1-%2C-WBX%2C-LFX-tp29977247p29977247.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD Announcement - October 15th 2010
Hello list, I would like to announce additional daughterboard support and API changes in regards to the UHD. As of this announcement, all Ettus hardware is supported under UHD. --- Daughter board features and support --- TVRX support DBSRX fixes and ability to set the filter bandwidth XCVR2450 ability to set the filter bandwidth Notes on the bandwidth ranges can be found here: http://www.ettus.com/uhd_docs/manual/html/dboards.html --- API Changes --- The device::send() call now has an optional timeout parameter. Meaning: a call to send() can timeout if there is not an available buffer to fill with data. In the case of USRP2, send() currently blocks regardless of the timeout. This will be fixed with host-based flow control; or if you really need it, there is a #define waiting to be uncommented. The send timeout for USRP1 functions properly. All device timeouts are now doubles, and in units of seconds. For device::recv() and device::recv_async_msg(), this is an API breakage. The reason for the change being: to provide maximum precision to the underlying implementation of the timeout should the need to do so arise. If you were not using timeouts, then just rebuild your application (this includes gr-uhd). If you were using the recv timeouts, convert from units of milliseconds to seconds. --- On buffer resizing --- I believe the warning about buffer resizing has lead to some confusion and misuse so I would like to clarify some things: A UDP socket has re-sizable kernel buffers for send and receive. A large receive buffer improves performance (reduces data overflows). However, a large send buffer actually seems to hurt performance (increases data underflow). By default, the UHD will automatically resize the receive buffer to something large, and print a warning if it cannot. On linux, the *fix* is to change a sysctl value that caps the max receive buffer size. There was some confusion as to how to deal with this warning and resizing buffers with special device parameters. To clarify this, the warning now prints the sysctl command that you should run, its even polite. The notes about resizing the socket buffers has been moved to the transport application notes and marked for "advanced users": http://www.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers --- Feedback is welcome! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: cannot import name ais
You don't need to set a receiver subdevice if you are loading data from a file. You will also need to set a decimation so the software knows what rate to expect in the file. So, if your recorded data is at 1Msps: ./ais_decode.py -d 64 -F signal_filename I know it's sort of weird to specify a decimation value for recorded data when it's really setting a data rate, but I'm trying to be consistent with parameters. The decimation is relative to the 64Msps sample rate of the USRP. One of these days I'll update the AIS software to use the new UHD drivers; when that happens you'll be able to specify a sample rate on the command line and it will "just work". It'll also "just work" on USRP2, which would be nice. I'll probably take care of that after I (finally) polish up a Mode S decoder I'm working on. It expects data in the usual complex format, such as that output by usrp_rx_cfile.py. --n On Fri, 2010-10-15 at 03:49 -0700, Thunder87 wrote: > changed prefix to /usr instead of default /usr/local > > ./configure --prefix=/usr > > Looks like it's working. Can't verify at the moment. > I think I saw recorded AIS signals somewhere in the web. Should be able to > test package with one of those (if I can find them again). > > Should be something like './ais_decode.py -R B -F signal_filename' for > files? > > > Thunder87 wrote: > > > > Installed gr-ais package from cgran: > > apt-get install autoconf automake libtool gcc g++ subversion python-dev > > svn co https://www.cgran.org/svn/projects/gr-ais/trunk /home/gr-ais > > cd /home/gr-ais/trunk > > ./bootstrap > > ./configure > > make install > > > > No errors at this point. Only few warnings in make. > > Then tried to execute ais_decode.py: > > cd src/python > > python ais_decode.py -R B -g 55 -e -2e3 > > > > Got import error: > > Traceback (most recent call last): > > File "ais_decode.py", line 11, in > > from gnuradio import ais > > ImportError: cannot import name ais > > > > Everything seems to install properly. Any ideas? > > > > Output of "make" : > > r...@th-d:/home# cd /home/gr-ais > > r...@th-d:/home/gr-ais# ./bootstrap > > r...@th-d:/home/gr-ais# ./configure > > checking build system type... i686-pc-linux-gnu > > checking host system type... i686-pc-linux-gnu > > checking target system type... i686-pc-linux-gnu > > 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 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 for g++... g++ > > checking whether we are using the GNU C++ compiler... yes > > checking whether g++ accepts -g... yes > > checking dependency style of g++... gcc3 > > checking how to run the C++ preprocessor... g++ -E > > checking whether C++ has std::isnan... yes > > checking gr_libdir_suffix... > > checking whether to append 64 to libdir... no > > checking whether user wants warnings... yes > > checking whether gcc accepts -Wall... yes > > checking whether g++ accepts -Wall... yes > > checking whether g++ accepts -Woverloaded-virtual... yes > > 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 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 list
[Discuss-gnuradio] Underruns
Hello, I've been getting a series of underruns when running a USRP2 at 10MHz (Interpolation = 10) using RTS and a fast machine. I plugged a serial cable into the UART and can see one or more 'U's pop up on the screen. Depending on how many custom blocks I have, the occurrence of a U can take from 2 minutes to an hour. The average processor usage varies with which blocks I use but only over a range from 20% to 35% with no spikes above 40% according to gnome-system-monitor. More-over, if I make a simple flowgraph in GRC of the following: GLFSR(23, True, 0,1) -> char_to_float -> float_to_complex -> USRP2_sink(Interp = 10, freq = 2.4e9, gain = 20, Clock: Lock to external SMA) (With Real Time scheduling enabled) I still get underruns! Anyone have any ideas on what might cause my underruns or just underruns in general? Thanks, James Streitman Sorry if this is a repeat email, I sent it from the wrong email the first time which I don't believe should go through. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Underruns
Hello, I've been getting a series of underruns when running a USRP2 at 10MHz (Interpolation = 10) using RTS and a fast machine. I plugged a serial cable into the UART and can see one or more 'U's pop up on the screen. Depending on how many custom blocks I have, the occurrence of a U can take from 2 minutes to an hour. The average processor usage varies with which blocks I use but only over a range from 20% to 35% with no spikes above 40% according to gnome-system-monitor. More-over, if I make a simple flowgraph in GRC of the following: GLFSR(23, True, 0,1) -> char_to_float -> float_to_complex -> USRP2_sink(Interp = 10, freq = 2.4e9, gain = 20, Clock: Lock to external SMA) (With Real Time scheduling enabled) I still get underruns! Anyone have any ideas on what might cause my underruns or just underruns in general? Thanks, James Streitman ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD USRP2 Board Syncronisation on Firmware
Marc, This mailing list is only for discussing GNU Radio related topics. We have another list for users of USRPs with other software like Simulink and Matlab, which would be a better place to ask your question. You can find it here: http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com Thanks, Matt On 10/15/2010 07:20 AM, MarcW wrote: Hi all, I am interested in using the new simulink block in the communications blockset for the USRP2 receive in MATLAB. However, I wish to syncronise multiple boards together using an external 10MHz clock reference and 1PPS signal. I assume that I can do this by making some modifications to the UHD firmware that loads onto the SD cards instead of implementing by sending host commands during runtime. Does anybody have any experience of doing this? If so, please could you tell me which parts of the firmware must be modified to allow this syncronisation and the commands required? Any help is greatly appreciated, Best regards, Marc. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD USRP2 Board Syncronisation on Firmware
Hi all, I am interested in using the new simulink block in the communications blockset for the USRP2 receive in MATLAB. However, I wish to syncronise multiple boards together using an external 10MHz clock reference and 1PPS signal. I assume that I can do this by making some modifications to the UHD firmware that loads onto the SD cards instead of implementing by sending host commands during runtime. Does anybody have any experience of doing this? If so, please could you tell me which parts of the firmware must be modified to allow this syncronisation and the commands required? Any help is greatly appreciated, Best regards, Marc. -- View this message in context: http://old.nabble.com/UHD-USRP2-Board-Syncronisation-on-Firmware-tp29972053p29972053.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python level documentation
On Sun, Oct 10, 2010 at 7:40 PM, Ben Reynwar wrote: > Hi all, > > I've been experimenting with creating some python level documentation > for gnuradio to complement the existing doxygen docs. > > My first attempt was pure autogeneration, but I wasn't successful in > creating any documentation that wouldn't be more painful to wade > through than the source code itself. I'm currently of the opinion > that using Sphinx is the way to go. It's a compromise between manual > creation and autogeneration, where you manually create the structure > of the documentation but the docstrings are automatically pulled out > of the python modules. It also easy using Sphinx to create links from > the python docs to the doxygen C++ docs. Thanks for taking a stab at this, Ben! I'm not convinced right now that this is the best way to handle it. What's wrong with using Doxygen for the Python documentation as well? I've never tried to do this myself, but I think other people have. No one's really seemed to "get it right." But adding another documentation system on top of Doxygen wouldn't be my first choice (we're already heavy on dependencies, and I try to avoid adding more if it can be helped). Also, I'm not fond of having a file that has to be maintained like this. Now, if you can show that this is really the best way to go, I'll reconsider. > I've created some example documentation and put it online at > www.reynwar.net/gnuradio/sphinx/. It's only a small subsection of > gnuradio, because I didn't want to go to the effort of creating it all > until I got some feedback. Do you guys think that the maintenance > effort of documentation like this would be worth the help it would be > to beginning users? If you click on the 'Show Source' link on the nav > bar you can see text files that would need to be manually maintained. > > Cheers, > Ben So right now, this seems most helpful in exposing the namespace and the Python modules. Everything inside is just a link to the C++ documentation. I'm not sure that's quite enough to make this kind of documentation worthwhile. Now, I think the real benefit for doing Python-level code documentation is in the all-Python blocks. Specifically, there's a lot of under-documented and under-exposed stuff sitting in the blks2 module (gnuradio-core/src/python/gnuradio/blks2impl). Also, there are all of the examples. If you can get a good documentation system for them so that we can easily browse it and generate it, then I think that's greatly beneficial to the community. I'm not trying to be discouraging here. Hopefully, you can see where I'm coming from. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: cannot import name ais
changed prefix to /usr instead of default /usr/local ./configure --prefix=/usr Looks like it's working. Can't verify at the moment. I think I saw recorded AIS signals somewhere in the web. Should be able to test package with one of those (if I can find them again). Should be something like './ais_decode.py -R B -F signal_filename' for files? Thunder87 wrote: > > Installed gr-ais package from cgran: > apt-get install autoconf automake libtool gcc g++ subversion python-dev > svn co https://www.cgran.org/svn/projects/gr-ais/trunk /home/gr-ais > cd /home/gr-ais/trunk > ./bootstrap > ./configure > make install > > No errors at this point. Only few warnings in make. > Then tried to execute ais_decode.py: > cd src/python > python ais_decode.py -R B -g 55 -e -2e3 > > Got import error: > Traceback (most recent call last): > File "ais_decode.py", line 11, in > from gnuradio import ais > ImportError: cannot import name ais > > Everything seems to install properly. Any ideas? > > Output of "make" : > r...@th-d:/home# cd /home/gr-ais > r...@th-d:/home/gr-ais# ./bootstrap > r...@th-d:/home/gr-ais# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > 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 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 for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking dependency style of g++... gcc3 > checking how to run the C++ preprocessor... g++ -E > checking whether C++ has std::isnan... yes > checking gr_libdir_suffix... > checking whether to append 64 to libdir... no > checking whether user wants warnings... yes > checking whether gcc accepts -Wall... yes > checking whether g++ accepts -Wall... yes > checking whether g++ accepts -Woverloaded-virtual... yes > 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 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 for /usr/bin/ld option to reload object files... -r > checking for objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for ar... ar > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for dlfcn.h... yes > checking whether we are using the GNU C++ compiler... (cached) yes > checking whether g++ accepts -g... (cached) yes > checking dependency style of g++... (cached) gcc3 > checking how to run the C++ preprocessor... g++ -E > 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 > c
[Discuss-gnuradio] underruns at medium sample rates using UHD
Hey list, I regularly encounter underrun messages when running the UHD transmitter (uhd_mimo_sink or uhd_simple_sink) with sample rates of 12.5 MSps or higher. The OS (Ubuntu 10.04, 64bit) setup is according to the guidelines (realtime priority for user, buffer size set to recommended 50 MB) and the current git version is in use. While runnning the application the system load using a Quadcore CPU @ 2.66 GHz and 4 GB RAM is moderate but never high. Has anybody else experienced such underrun problems and/or knows a solution how to solve it? BR Christoph ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: cannot import name ais
Oh, found where problem was. Gnuradio is installed into usr/lib/python2.6/dist-packages/gnuradio AIS package was installed into usr/local/lib/python2.6/dist-packages/gnuradio Could this happen because I used sudo su before downloading and installation of package? I'll try and reinstall, hope this works. Thunder87 wrote: > > Installed gr-ais package from cgran: > apt-get install autoconf automake libtool gcc g++ subversion python-dev > svn co https://www.cgran.org/svn/projects/gr-ais/trunk /home/gr-ais > cd /home/gr-ais/trunk > ./bootstrap > ./configure > make install > > No errors at this point. Only few warnings in make. > Then tried to execute ais_decode.py: > cd src/python > python ais_decode.py -R B -g 55 -e -2e3 > > Got import error: > Traceback (most recent call last): > File "ais_decode.py", line 11, in > from gnuradio import ais > ImportError: cannot import name ais > > Everything seems to install properly. Any ideas? > > Output of "make" : > r...@th-d:/home# cd /home/gr-ais > r...@th-d:/home/gr-ais# ./bootstrap > r...@th-d:/home/gr-ais# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > 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 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 for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking dependency style of g++... gcc3 > checking how to run the C++ preprocessor... g++ -E > checking whether C++ has std::isnan... yes > checking gr_libdir_suffix... > checking whether to append 64 to libdir... no > checking whether user wants warnings... yes > checking whether gcc accepts -Wall... yes > checking whether g++ accepts -Wall... yes > checking whether g++ accepts -Woverloaded-virtual... yes > 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 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 for /usr/bin/ld option to reload object files... -r > checking for objdump... objdump > checking how to recognize dependent libraries... pass_all > checking for ar... ar > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /usr/bin/nm -B output from gcc object... ok > checking for dlfcn.h... yes > checking whether we are using the GNU C++ compiler... (cached) yes > checking whether g++ accepts -g... (cached) yes > checking dependency style of g++... (cached) gcc3 > checking how to run the C++ preprocessor... g++ -E > 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/bi
RE: [Discuss-gnuradio] C++ and python in OFDM doubt
Benchmark_ofdm_rx.py program uses C + + functions OFDM? Is there any way to see a python code in graphical form? as block diagrams or something? Using c++ there is a function you can use on the flow-graph object called "dump_flowgraph()" or similar. Look in the doxygen documentation for the object for reference. I don't know if there is any similar functionality in python, since I never used it. My ultimate goal is to take the blocks C + + and use them in simulink for a receiver, is it possible? I know that someone once said they had something like this going... But I don't remember who it was... I think it was a .de- address... Try your favorite search-engine-provider ;) Best regards, Mattias Kjellsson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Large spurious in data obtained from USRP2+DBSRX
Hi all, I am implementing a GPS receiver based on the USRP2 with a DBSRX daughterboard equipped, whereas the software is only using the URSP2 C++ interface, the rest is done without GNURADIO. The receiver works quite well, but I noticed that whatever I do I get really huge spurious signals in the obtained spectra. In order to make clear what I mean, I am attaching a plot of direct sampling at 1.0 GHz with a decimation of 4 and gain=1. There is no signal going in the URSP2 so what you should see is something like instrumental noise. Nevertheless, there are these huge spurious signals. These spurious signals don't change their amplitude nor their relative position w.r.t. the center frequency independent of which RF I choose. Is this a problem of the DBSRX or is it related to the FPGA, firmware, etc? Any comments highly appreciated. Best regards, Thomas Hobiger -- ** Dr. Thomas Hobiger Space-Time Measurement Project Space-Time Standards Group New Generation Network Research Center National Institute of Information and Communications Technology -- 4-2-1 Nukui-Kitamachi, Koganei 184-8795 Tokyo Japan -- email: hobi...@nict.go.jp phone: ++81-042-327-7561 fax:++81-042-327-6664 -- homepage (priv.): http://www.hobiger.org ** <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] C++ and python in OFDM doubt
Hello, I am working on OFDM. I have several questions about OFDM codes, and in general GNU radio. As I understand, there are functions in C + + that are linked through python, right? if I look on the web: http://www.gnuradio.org/doc/doxygen/ I can find the C + + blocks there for OFDM: gr_ofdm_bpsk_demapper, gr_ofdm_cyclic_prefixer, gr_ofdm_frame_acquisition ect On the other hand, if you look at the code: benchmark_ofdm_rx.py, it calls another function that is ofdm_demod belonging to "ofdm.py." Then call "ofdm_receiver.py" later "ofdm_sync_ml.py" But I never see the function calls in C + + mentioned above. For me this raises several questions: Benchmark_ofdm_rx.py program uses C + + functions OFDM? Is there any way to see a python code in graphical form? as block diagrams or something? My ultimate goal is to take the blocks C + + and use them in simulink for a receiver, is it possible? Thanks -- View this message in context: http://old.nabble.com/C%2B%2B-and-python-in-OFDM-doubt-tp29969780p29969780.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gcc 4.5 and GNU Radio 3.3.0
You can install various gcc versions in parallel without problems. But I suggest to use the gcc from the repositories. Just search for it: "zypper search gcc", and in your case, where the machine has no connection to the internet, just download the appropriate rpms from the "openSUSE:11.3/standard"-repository. http://software.opensuse.org/ is the right place for you. /usr/bin/gcc and /usr/bin/g++ are just symlinks to /usr/bin/gcc-4.5 and /usr/bin/g++-4.5 If you want to use a version different than the default, just change the symlinks (there are a few more... /usr/bin/c++, /usr/bin/cc). You should also consider to use update-alternatives ... just google for it. Or you set the environment variables ... Just for the package you want to compile: "CC=/usr/bin/gcc-4.3 CXX=/usr/bin/g++-4.3 ./configure " Gregor 2010/10/14 Steve Mcmahon : > Gregor: > > Thanks for your reply. I have never installed a second version of gcc on a > Linux machine before. How can I install gcc 4.4.4 in /opt so that it exists > alongside the gcc 4.5.0 that comes packaged with openSUSE 11.3?? My machine > is in a lab, and does not have a connection to the internet, so I would have > to download packages and put them on a USB pen drive and walk them to the > machine. Your help is greatly appreciated. Thanks. > > Steve McMahon > > > --- On Tue, 10/12/10, Gregor Dschung wrote: > >> From: Gregor Dschung >> Subject: Re: [Discuss-gnuradio] gcc 4.5 and GNU Radio 3.3.0 >> To: "Steve Mcmahon" >> Cc: discuss-gnuradio@gnu.org >> Date: Tuesday, October 12, 2010, 11:49 PM >> >> Hi, >> >> 3.3.0 stable doesn't compile under openSUSE 11.3 with gcc >> 4.5.0. But >> installing gcc43 and gcc43-c++ (and using them... just set >> the >> appropriate environment variables) did the job for me. >> >> The last time I compiled the git branch under openSUSE was >> 2 months >> ago. At this time, gcc45 didn't work for this branch, too. >> Maybe, this >> changed in the meantime. >> >> Gregor >> >> 2010/10/12 Philip Balister : >> > On 10/12/2010 12:04 PM, Steve Mcmahon wrote: >> >> >> >> I am trying to compile GNU Radio 3.3.0 under >> openSuse 11.3, which uses gcc >> >> 4.5.0. I have all the dependencies built and >> resolved, but when I compile >> >> GNU Radio 3.3.0, I get errors. It seems that GNU >> Radio does not compile >> >> successfully with the new gcc 4.5.0, although I >> know it compiles with gcc >> >> 4.4.1 on openSuse 11.2. However, I specifically >> need to run openSuse 11.3 >> >> for my application. How, exactly, can I get GNU >> Radio 3.3.0 to build under >> >> gcc 4.5.0? Will the next release of GNU Radio >> address this? Is there a >> >> compiler flag I can use, or a quick-and-easy hack >> to the GNU Radio code? >> >> What is the problem with gcc 4.5.0? Thank you very >> much for your help on >> >> this issue. I really appreciate it. >> > >> > I am building gnuradio from git (next branch) on gcc >> 4.5 and am not having >> > any gcc issues. >> > >> > Philip >> > >> > >> >> >> >> Steve McMahon >> >> >> >> >> >> >> >> >> >> >> >> ___ >> >> Discuss-gnuradio mailing list >> >> Discuss-gnuradio@gnu.org >> >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> > >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] costasloop
I build bpsk process on gnu using costas loop. But I don't know how to set 'alpha' parameter. Now I change it and fc min ,fc max by hand. Thanks Thangnt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
