Re: [Discuss-gnuradio] XCVR2450 simple questions
Hi, Now it is clear enough that the XCVR2450 is not full duplex. The question I asked in my first post in the case it is not full duplex is still unknown for me. How long does it take to the board to switch from transmission mode to reception mode? In the data sheet I can read a picture called TX-RX turnaround frequency settling but for me it is not very clear is the number I am looking for. Furthermore it scares me a little bit because if it takes several microseconds to change state will mean that is going to affect very seriously the minimum range of my radar detection system. It can take even the whole range (if I do not use an amplifier and a good antenna). Does anybody have any idea? Many thanks for your answers, Jorge Well, then. Jason and I then were both confused. I thought it was full-duplex but with the proviso that owing to it having only the one VFO/PLL, the full-duplex had to be same frequency, which would be perfect for scenarios like radar. You have too many daughtercards, Matt :-) Makes it hard to keep track of exactly which does what. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org On 10/12/2010 07:33 PM, Matt Ettus wrote: NO. The XCVR2450 is NOT full duplex. I have never said anything different. The XCV2450 is NOT full duplex. Never was. Never will be. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ImportError: cannot import name ais
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 module 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/bin/ld) 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 for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the
[Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm?
Hello, I want to know if GNU Radio USRP2 can connect to Beagle Board- Xm I know Beagle-board can connect to USRP by USB connection. Now BeagleBoard-XM has 100M Ethernet, and USPP2 uses 1000M Ethernet, can they work together? Thanks Zhen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm?
On 10/13/2010 10:35 AM, Zhen wrote: Hello, I want to know if GNU Radio USRP2 can connect to Beagle Board- Xm I know Beagle-board can connect to USRP by USB connection. Now BeagleBoard-XM has 100M Ethernet, and USPP2 uses 1000M Ethernet, can they work together? I do not know of any Gig-E solutions for the Beagleboard, so you can't connect a USRP2 to a beagle board. Philip Thanks Zhen ___ 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] HPSDR talk in London (UK), Thurs 21st October.
Hello, Thought this event might be of interest to subscribers of the list that are based in and around London: http://oshug.org/event/5 And if anyone would be interested in doing a slot on GNU Radio/USRP they can contact me off-list. Regards, Andrew -- Andrew Back mailto:and...@osmosoft.com http://carrierdetect.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to adjust the Low pass filter bandwidth
Hi all, My incoming signal has a bandwidth of 1MHz while the DBSRX daughter board that I am using has a low pass filter bandwidth of 60MHz. Is it possible for me to adjust the low pass filter bandwidth in USRP2? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm?
I head that you can use a gigE switch between usrp2 and 100M Ethernet. Then it may work. -Josh On 10/13/2010 07:35 AM, Zhen wrote: Hello, I want to know if GNU Radio USRP2 can connect to Beagle Board- Xm I know Beagle-board can connect to USRP by USB connection. Now BeagleBoard-XM has 100M Ethernet, and USPP2 uses 1000M Ethernet, can they work together? Thanks Zhen ___ 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
Re: [Discuss-gnuradio] differences between USRP2 rev 3 and rev 4 boards
What's the push button for? Dave - Original Message From: Matt Ettus m...@ettus.com To: Steve Mcmahon steve.mcmaho...@yahoo.com Cc: GNR discuss-gnuradio@gnu.org Sent: Tue, 12 October, 2010 23:16:23 Subject: Re: [Discuss-gnuradio] differences between USRP2 rev 3 and rev 4 boards On 10/12/2010 02:22 PM, Steve Mcmahon wrote: I am wondering what are the differences between the USRP2 rev 3 board and the rev 4 board? I have one of each (one I ordered maybe a year ago and one I ordered this past summer), and I don't see any differences on the board itself. I understand that the versions of the FPGA image and the firmware that shipped on the SD card from the factory would be different, since over a year of time elapsed between my purchasing the two boards. But what else is different? I can't find a changelog for the USRP2 boards anywhere. Some clocks were reorganized for layout reasons and the PPS input circuit was modified to have a more consistent delay. The same FPGA image works for both. Matt ___ 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
Re: [Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm?
Unfortunately that doesn't work, I tried doing that with a TI board, DM6446, it had 100M Ether and I used a GigE switch so I ended up using a regular USRP. You can detect the USRP2 using the provided script but you won't be able to receive radio samples. If memory serves correctly, there are some GigE specific throtteling packets that the USRP2 sends out that 100M Ethernet can't understand. al -Original Message- From: Josh Blum j...@joshknows.com To: discuss-gnuradio@gnu.org Sent: Wed, Oct 13, 2010 12:06 pm Subject: Re: [Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm? I head that you can use a gigE switch between usrp2 and 100M Ethernet. Then it may work. -Josh On 10/13/2010 07:35 AM, Zhen wrote: Hello, I want to know if GNU Radio USRP2 can connect to Beagle Board- Xm I know Beagle-board can connect to USRP by USB connection. Now BeagleBoard-XM has 100M Ethernet, and USPP2 uses 1000M Ethernet, can they work together? Thanks Zhen ___ 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
Re: [Discuss-gnuradio] How to adjust the Low pass filter bandwidth
My incoming signal has a bandwidth of 1MHz while the DBSRX daughter board that I am using has a low pass filter bandwidth of 60MHz. Is it possible for me to adjust the low pass filter bandwidth in USRP2? If you are using the UHD, it is fairly easy to adjust the bandwidth (4M-33M), there is a bandwidth property for it which might even be exposed in the gr-uhd wrapper in an upcoming release. In the meantime, it is fairly easy to change the call to set_bandwidth in the daughterboard constructor to give your desired bandwidth http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/usrp/dboard/db_dbsrx.cpp#L226 If you are using the rawethernet USRP2 software in the GNUradio tree, you will need to modify the values of common.d_m and common.d_fdac in the firmware (around line 100 of the file below), and then rebuild the firmware and write it to your sd card. http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/lib/db_dbsrx.c#L99 The equation for filter bandwidth is on page 10 of the max2118 datasheet: F_3dB = Fxtal / M * (4 + 0.145 * FDAC) where: M = common.d_m FDAC = common.d_fdac Fxtal = 4MHz However, be aware that integrated noise power inside the filter bandwidth remains constant, regardless of filter bandwidth, so as you narrow the filter bandwidth, the noise power per hertz goes up. We generally leave the filter set fairly wide because the ADC in the USRP is usually not limiting the linearity, so narrowing the baseband filter just degrades noise performance. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm?
On 10/13/2010 09:31 AM, Almohanad Fayez wrote: Unfortunately that doesn't work, I tried doing that with a TI board, DM6446, it had 100M Ether and I used a GigE switch so I ended up using a regular USRP. You can detect the USRP2 using the provided script but you won't be able to receive radio samples. If memory serves correctly, there are some GigE specific throtteling packets that the USRP2 sends out that 100M Ethernet can't understand. The pause frames are for tx throttling, so that means receive should be fine. Anyways, there is good news! Host based flow control is on its way (and will do away with those pause frames). -Josh al -Original Message- From: Josh Blumj...@joshknows.com To: discuss-gnuradio@gnu.org Sent: Wed, Oct 13, 2010 12:06 pm Subject: Re: [Discuss-gnuradio] Can USRP2 connect to Beagle Board-Xm? I head that you can use a gigE switch between usrp2 and 100M Ethernet. Then it may work. -Josh On 10/13/2010 07:35 AM, Zhen wrote: Hello, I want to know if GNU Radio USRP2 can connect to Beagle Board- Xm I know Beagle-board can connect to USRP by USB connection. Now BeagleBoard-XM has 100M Ethernet, and USPP2 uses 1000M Ethernet, can they work together? Thanks Zhen ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: cannot import name ais
On Wed, 2010-10-13 at 03:06 -0700, 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 module from gnuradio import ais ImportError: cannot import name ais Everything seems to install properly. Any ideas? Looks like it installed correctly. It installed itself to /usr/local/lib/python2.6/dist-packages/gnuradio. Check to see that is also where Gnuradio's dist-package was installed to, and set your PYTHONPATH to that directory. Try running python from the command line and executing import gnuradio and see if it works. As a side note, I noticed you're compiling, installing, and running it as root. I haven't tried this so I don't know that it won't work, but it's generally considered dangerous to do everyday tasks as root. --n 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...
[Discuss-gnuradio] Re: GNU Radio roadmap
Tom, You have been doing some good work in using more efficient filters; have you integrated your code into GNU Radio code base yet? If there is a working version, could you please tell me where I can find it? Is it in the development version or in GNU Radio 3.3 release version. More importantly, which function modules are using the new filters? Thanks, Andrew Message: 1 Date: Sat, 9 Oct 2010 12:08:55 -0400 From: Tom Rondeautrondeau1...@gmail.com Subject: Re: [Discuss-gnuradio] GNU Radio roadmap To: Pandeya, Neel L.npand...@draper.com Cc: discuss-gnuradio@gnu.org Message-ID: aanlkti=ojz50iled_c=mpccq1n5ob5q6xosonlah6...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 5, 2010 at 7:36 PM, Pandeya, Neel L.npand...@draper.com wrote: Hello: What is the roadmap for GNU Radio releases over the next 12 to 18 months?? What new features are planned?? Will the next release be a minor release (3.3.1), or major release (3.4.0)?? When is the next release planned for?? Any insight is much appreciated. Thanks. --Sunil Sunil, Thanks for asking. That's a fair question, and I haven't been ignoring it. The problem is, we don't have a really well-defined roadmap right now, but it's something we are working on. By we, I'm mostly talking about Johnathan Corgan and myself. If I tried to tell you everything we are thinking about for the future, it would be a) a really long list and b) pretty incoherent. We have a few big ideas coming down the line, but it's going to take some time still, and we need a bit more time to define when we can properly role them out and in what releases. I will give you some insight into the next couple of things we want to do in the immediate future. 1. Rework the USRP-based examples to use UHD and get rid of duplication (usrp_thing.py and usrp2_thing.py) 2. Refactor the build system. This is pretty major from the developers side but hopefully fairly transparent to the user (if we do it right, of course). This will make more top-level blocks that will be mostly split out of gnuradio-core. The main purpose of this is to make libgnuradio-core hold just what you need to get the runtime engine working. We will then have a separate library for all of the signal processing blocks. We also want to move all of the digital modulation stuff (including OFDM) into its own top-level block space. This work is to help with a few issues. First, ease up the requirements for getting the runtime engine installed, and second, make it easier to understand how things interact. Exposing the second bit of information will, hopefully, allow people more easily work with the existing blocks as well as add their own. A third consequence of this move is that I want to improve the code maintenance by making unit testing procedures that exercise more of the code and make sure we don't let bit rot bite us. With the new structure, we expect to improve on the testing procedures and help make it obvious how to add your test code. There are a few other ideas coming out soon that I want to announce before December. My timeline here is due to a tutorial on GNU Radio that I am giving at the WinnForum's SDR Technical Conference. So more soon, but I hope that helps give you some clues as to where we are headed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: GNU Radio roadmap
Tom, Can you make the materials of the tutorial available? Cheers, Rafael Diniz There are a few other ideas coming out soon that I want to announce before December. My timeline here is due to a tutorial on GNU Radio that I am giving at the WinnForum's SDR Technical Conference. So more soon, but I hope that helps give you some clues as to where we are headed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] differences between USRP2 rev 3 and rev 4 boards
For now it doesn't do anything. If you'd like to connect it in the verilog you are welcome to. Matt On 10/13/2010 09:16 AM, David Evans wrote: What's the push button for? Dave - Original Message From: Matt Ettusm...@ettus.com To: Steve Mcmahonsteve.mcmaho...@yahoo.com Cc: GNRdiscuss-gnuradio@gnu.org Sent: Tue, 12 October, 2010 23:16:23 Subject: Re: [Discuss-gnuradio] differences between USRP2 rev 3 and rev 4 boards On 10/12/2010 02:22 PM, Steve Mcmahon wrote: I am wondering what are the differences between the USRP2 rev 3 board and the rev 4 board? I have one of each (one I ordered maybe a year ago and one I ordered this past summer), and I don't see any differences on the board itself. I understand that the versions of the FPGA image and the firmware that shipped on the SD card from the factory would be different, since over a year of time elapsed between my purchasing the two boards. But what else is different? I can't find a changelog for the USRP2 boards anywhere. Some clocks were reorganized for layout reasons and the PPS input circuit was modified to have a more consistent delay. The same FPGA image works for both. Matt ___ 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
Re: [Discuss-gnuradio] differences between USRP2 rev 3 and rev 4 boards
On 10/13/2010 03:04 PM, Matt Ettus wrote: For now it doesn't do anything. If you'd like to connect it in the verilog you are welcome to. Matt Paint it red, and label it Do Not Push This Button :-) -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 27C3-tickets available through pre-sale only
FYI, Always a good time, the Chaos Communication Congress 27C3 will be held from Monday December 27 to Thursday December 30, 2010 in Berlin, Germany. Eric ---BeginMessage--- For those who haven't noticed yet but want to attend the CCC-congress 27C3 in december: tickets are pre-sale only this year due to the demand exceeding building capacity. Please also let other people know who you think may want to attend that they need to buy their tickets in advance. The process works as follows: 1. you go to https://presale.events.ccc.de/ and register a ticket account (at least 24 hours before the next batch is release) 2. tickets are sold in batches, next batch up 11th of November (announcement among other channels at Twitter @27c3) 3. with an account, you can order up to two tickets, the moment a batch is released (usually they are gone within a couple of hours) 4. pay tickets 5. enjoy the best hacker conference in Europe For more details see: http://events.ccc.de/2010/10/10/how-to-survive-the-pre-sale-2/ There might be day-tickets available at the counter, but I really would not rely on that. Thanks Greetings from Berlin, Frank PS: for questions etc., please use the e-mail adresses provided at the events.ccc.de website, I am only the messenger here. - To unsubscribe, e-mail: main-unsubscr...@lists.airprobe.org For additional commands, e-mail: main-h...@lists.airprobe.org ---End Message--- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Change in Phase on a USRP2 configured as a VNA
Hello Everyone, I have put together a simple vna setup using a USRP2. For right now Im using the loop back cable that ettus sells (SMA-SMA) and a 3dB pad to connect the RX to the TX port. While running the attached setup in GRC I see a couple of things that concearn me and I was hoping to get some help on them. The first thing is the startup phase. If Im not mistaken without calibration there is no way to determine what this should be even though the cable thru does not change substantially each time I restart the grc file. From what I read I believe this just has to do with the phase of the internal clock in the usrp when I execute a file in grc. I think I can live with this since I ll have a reference in my measurement that I can set the phase off of. The second thing that I see though that is more troublesome is that when I start the file and just allow it to run the phase changes over time. It will be stable for like .5 minute or so and then jump in value and then stay stable again for another interval. This pattern repeats. Im runnig at 200k sample frequency and 500 decimation so I don't think Im pushing the bounds of gig-e by any means. Plus not that Im sure that this has anything to do with it but the decimation is a multiple of 4 so Im getting the full benefit of the hardware. Am I wrong in thinking this should be stable over time while the hardware is running? Is this indicative of a drop in communication to the USRP2 which causes it to shut down and then its merely the first problem again, that is a random intial startup phase. I don't see any U of O s in the log so I don't think Im having that problem. That third thing that I m curious about is the affects of changing transmit frequency (LO Frequency) , at run time, of the USRP2, and its affect on the measurement. Im assuming that there is some sort of settling time before I should assume the measurment is valid what is this? I m guessing this will also change the phase value. But how. I saw that matt asked in a previous thread why the user didn't just transmit the bandwidth they needed to the USRP2 instead of using the LO. In this case since Im using the WBX board and I can't use an LO of 0 MHz (I assume) it makes sense to use the LO of the WBX board as the RF source. It would allow me to use the full bandwidth of the WBX board 68MHZ to 2.2GHz without the gig-e limitations. The final thing is which is better as a source. A constant or a sinusoid? I settled on a sin function by trial and error. But is there a better rationale for selection? Thanks, Justin attachment: Picture1.png___ 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
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 dsch...@cs.uni-kl.de wrote: From: Gregor Dschung dsch...@cs.uni-kl.de Subject: Re: [Discuss-gnuradio] gcc 4.5 and GNU Radio 3.3.0 To: Steve Mcmahon steve.mcmaho...@yahoo.com 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 phi...@balister.org: 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] Strange side-band when transmitting using WBX on USRP1
Hi All, We're having some problems with transmitting using the WBX board on a USRP1 (not an old one). We have a flow graph with a NULL source going into a NBFM, then through a multiply_const and into the USRP. At low frequencies (100MHz) the signal looks ok, but when we get up passed 500MHz we can see/hear that what should be an unmodulated carrier also has a single side-band (and is audible as a tone when demodulated) . And by increasing the const in the multiply_const, we can see our wanted signal getting stronger while the side-band remains there at a constant level. We've had a play with manually adjusting the DC offset of the USRP sink, which seems to change the size of the side-band a bit, but we don't really know what to do with that. We've tried several USRPS and several WBX boards and seen the same problem on all of them. We don't see it on the USRP2. We don't see it with the flex400 board. This picture http://tinyurl.com/27w5s8n shows the side-band on the left and the wanted signal on the right. The grc file is also attached. Any help you can offer would be greatly appreciated thanks! Drew -- Andrew Read +64 (03) 357 0787 Test Analyst Design Verification and Validation Team Tait Electronics Ltd === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === weird-sideband.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange side-band when transmitting using WBX on USRP1
On Oct 13, 2010, at 8:45 PM, Drew Read wrote: We're having some problems with transmitting using the WBX board on a USRP1 (not an old one). We have a flow graph with a NULL source going into a NBFM, then through a multiply_const and into the USRP. At low frequencies (100MHz) the signal looks ok, but when we get up passed 500MHz we can see/hear that what should be an unmodulated carrier also has a single side-band (and is audible as a tone when demodulated) . And by increasing the const in the multiply_const, we can see our wanted signal getting stronger while the side-band remains there at a constant level. That sounds (and looks) like an issue that I encountered yesterday with my USRP + WBX. I was using it to generate some test signals in the 1.5-1.7 GHz range, and I found that there was a constant spur about 1-2 kHz above the transmitter's center frequency. I also found that I could reduce its effects by playing with the signal level, transmitter gain and an external attenuator. For now, I think I can work around it by simply generating my test signals at an offset from the transmitter center frequency and adjusting the center frequency to put them back where I want them, thus moving the spur out of the middle of my test signal. We've had a play with manually adjusting the DC offset of the USRP sink, which seems to change the size of the side-band a bit, but we don't really know what to do with that. I also found a bit of the transmitter center frequency bleeding through when I modulated it with no DC component. I haven't tried to mitigate this yet, but my workaround for the spur should also let me ignore this little bit of unwanted carrier for the time being. I presume that it's due to a small DC offset error in the DACs, based on the my observation of what appears to be a small (sub-LSB) DC error in the receiver ADCs. In my receive path, I found there to always be a received component at the tuned receiver frequency, and I found that I could null it out by adding a small (magnitude 1.0) complex constant to the USRP source output before it passed to the rest of my receive chain. Over the course of a few hours and a power-cycle, I found that I had to readjust the constant once or twice. This little error is pretty negligible when receiving larger signals, but it was annoying while I was trying to look at some pretty weak signals. I may be able to swamp it out with some external gain, but I didn't have an LNA handy yesterday to try that. For the time being, I'm going to try to ignore these DC components in both the receiver and transmitter by simply offsetting the LO a bit from the signal that I want to transmit or receive. I have to do some more tests tomorrow using my USRP as a signal generator, so I hope this will work. In the longer term, I'm interested in looking into whether there's a better approach to trimming out any DC offsets in the DACs and ADCs. I'm also interested in learning more about that unwanted spur in the transmit output (particularly since it's quite a bit larger than the component that appears to be caused by a small DC error). We've tried several USRPS and several WBX boards and seen the same problem on all of them. We don't see it on the USRP2. Interesting. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
