Re: [Discuss-gnuradio] Large FFTs
Hi Thomas, What antenna are you using for GPS? If possible, can you give us a link or specifications of it. Patrik - Original Message - From: Thomas Hobiger hobi...@nict.go.jp To: Carles Fernandez carles.fernan...@gmail.com Cc: discuss-gnuradio@gnu.org Sent: Tuesday, August 24, 2010 7:38 Subject: Re: [Discuss-gnuradio] Large FFTs Hi Carles, I mean that the PLL lost lock after a few seconds, so we were able to extract only a few (and useless) navigation bits. We played with the filter loop, without success for the moment. We are quite confident in the software receiver, it works nice with other hardware configurations, and that is why we suspect that it could be a hardware issue. We will be working on this in the next month. I will let you know our advaces. Thanks. I am looking forward to have my USRP2 in the hands, to start playing with it. Your experience is highly appreciated. Best regards, Thomas -- ** 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 -- homepage (priv.): http://www.hobiger.org ** ___ 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] Large FFTs
Hi, What antenna are you using for GPS? If possible, can you give us a link or specifications of it. Beside some geodetic high end antenna (Trimble), we'd like to test the 3G1215A-XS-1 http://webserv.novatel.ca:7005/Antcom/partDetails.do?partid=53lineparam=5 for some GNSS-R stuff. As this is an active antenna, I hope the power it up via the DBSRX as the spec say The DBSRX is MIMO capable, and can power an active antenna via the coax. Regards, Thomas -- ** 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 -- homepage (priv.): http://www.hobiger.org ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large FFTs
Thanks Thomas, We'll try to replicate the antenna using a USRP1 within a few weeks Patrik - Original Message - From: Thomas Hobiger hobi...@nict.go.jp To: Patrik Tast pat...@poes-weather.com Cc: discuss-gnuradio@gnu.org; Jerry jerrymar...@verizon.net Sent: Tuesday, August 24, 2010 10:13 Subject: Re: [Discuss-gnuradio] Large FFTs Hi, What antenna are you using for GPS? If possible, can you give us a link or specifications of it. Beside some geodetic high end antenna (Trimble), we'd like to test the 3G1215A-XS-1 http://webserv.novatel.ca:7005/Antcom/partDetails.do?partid=53lineparam=5 for some GNSS-R stuff. As this is an active antenna, I hope the power it up via the DBSRX as the spec say The DBSRX is MIMO capable, and can power an active antenna via the coax. Regards, Thomas -- ** 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 -- homepage (priv.): http://www.hobiger.org ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large FFTs
Thomas, I'm some affraid to fry the DBSRX, draw too much current for the amplifier, so I use a general power inserter instead of feeding the Antenna bias pin on the daughterboard. I use a cheap Johansson (BE) TV power inserter (VHF - L-Band) so I wont ever have to worry about damaging the board I could not find the direct link to the inserter I'm using but the price was ~$15 Google gave these suggestions: http://www.google.com/products?hl=q=antenna+power+inserterrlz=1B3GGGL_enFI341FI342um=1ie=UTF-8ei=an5zTJn5NuWjOMjUsMsOsa=Xoi=product_result_groupct=titleresnum=4ved=0CCwQrQQwAw Regards, Patrik - Original Message - From: Thomas Hobiger hobi...@nict.go.jp To: Patrik Tast pat...@poes-weather.com Cc: discuss-gnuradio@gnu.org; Jerry jerrymar...@verizon.net Sent: Tuesday, August 24, 2010 10:13 Subject: Re: [Discuss-gnuradio] Large FFTs Hi, What antenna are you using for GPS? If possible, can you give us a link or specifications of it. Beside some geodetic high end antenna (Trimble), we'd like to test the 3G1215A-XS-1 http://webserv.novatel.ca:7005/Antcom/partDetails.do?partid=53lineparam=5 for some GNSS-R stuff. As this is an active antenna, I hope the power it up via the DBSRX as the spec say The DBSRX is MIMO capable, and can power an active antenna via the coax. Regards, Thomas -- ** 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 -- homepage (priv.): http://www.hobiger.org ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large FFTs
Your reply is related to running the FFT on the CPU, right? Do you have any experience running it on the FPGA of the USRP1 or USRP2? No, but I know that radio astronomers do this. I have done FFT with CUDA. As long as you can keep the data inside the GPU for long enough, you can get pretty nice performance. I have measured over 100 GFLOPS on FFT with a $300 Nvidia GPU. I haven't tried yet with my new 480 GTX, but it should be even faster. juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2+WBX full duplex doesn't receive
On Aug 23, 2010, at 10:10 PM, George Nychis wrote: If you stop transmitting, does your RX sample stream then begin again? Alas, no. Once it stops receiving, it never starts again. Time to dig into the firmware. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Power Supply Noise
Hello, I am attempting to build an analog front-end to a USRP 1 device. I have selected a VCO that will suit the frequency range we are looking at: It is an RFVC1800 and has a tuning range of approximately 7.4 - 12.4 GHz over a 13 volt tuning voltage. As this VCO is very sensitive to external noise, some power filtering will be necessary to minimize jitter and phase noise. What I would like to know is whether or not there are any other adverse effects from using the simple switch mode supply that is included with the USRP? Thanks, ~Jeffrey Lambert -- ~Jeffrey Lambert, K1VZX ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Power Supply Noise
On Tue, Aug 24, 2010 at 9:32 AM, Jeffrey Lambert je...@k1vzx.com wrote: Hello, I am attempting to build an analog front-end to a USRP 1 device. I have selected a VCO that will suit the frequency range we are looking at: It is an RFVC1800 and has a tuning range of approximately 7.4 - 12.4 GHz over a 13 volt tuning voltage. As this VCO is very sensitive to external noise, some power filtering will be necessary to minimize jitter and phase noise. What I would like to know is whether or not there are any other adverse effects from using the simple switch mode supply that is included with the USRP? Are you referencing the power brick that comes with the USRP (and provides the raw +6V DC input)? If so, you'll definitely want to do some significant filtering/cleaning up of this supply, and want to think carefully about the gnd paths to your VCO as well. IIRC, we saw non-trivial ringing on the gnd that had a period of ~5 uS and occurred every 20 mS (don't quote me on the exacts here, as my memory is a bit fuzzy, though this is what I sketched into my engineering notebook at the time). We ultimately determined we were simply seeing the residual effects of the switching power supply in the power brick and had to live with it or use a better external power suply. Most daughterboards take the raw +6V passed to it right from the power brick, and the use LDOs on the daughterboard to generate the voltages necessary for the sensitive RF components. But this is typically stepping down to 5V/3.3V, which, with a 6V input, provides enough margin for an LDO to work and still provide excellent power supply ripple rejection (PSRR). This is key when generating a stable supply for feeding a VCO, as any variation (i.e. ripple) will show up as variation in the output of your VCO. If I were you, I'd start with a good oscilloscope and begin probing around the power supply lines and the gnd lines of the USRP to see what the supplies look like, and from there you should be able to assess whether or not you'll be able to use this voltage as a starting point for your design. You'll also want to make sure the gnd reference point for the scope is as close to the measurement point as possible to ensure that you aren't picking up stray signals/interference. Good luck, and keep the list posted of progress. Sounds like quite a challenging project :-) -- John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Peak detector block does not really work. It need to be fixed
Hello Tom, Can you explain me why should gr_peak_detector need negative inputs ? What about the variable look ahead ? I wrote in the last message that look ahead has no function in gr_peak_detector. Do you know how can I add this feature in peak detector ? Thanks in advance Phong Do On Thu, Aug 12, 2010 at 8:26 AM, Phong Do stadtwald...@yahoo.de wrote: Hello, I'm working now with peak_detector block and find out that some functions don't really work. I've used the following 2 blocks: - Peak Detector (gr_peak_detector): the parameter look ahead seems have no function. I gave look ahead many values but the peak value did not change. I've seen in the gr_peak_detector_xx.cc that the variable d_look_ahead is called but it is not used in the main program. So I think the developer has forgotten this function. - Peak Detector 2 (gr_peak_detector2): in this block look ahead is used, but sometimes the peak detector freezes (output signal stops running in scope sink). I've changed the cpp code a little bit and it does not freeze anymore. But I'm not sure if the detector will work correctly after that. Here is what I've changed: original code: return tmp - 1; changed code: return tmp; Can anyone of the development team have a look at the 2 cpp ? best regards Phong Do Keep in mind that the gr_peak_detector actually expects negative inputs. So if your signal goes from 0 to 100, adjust it so that it goes from -100 to 0. Of course, I say keep in mind even though we probably haven't provided any documentation in the code to that affect... Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Peak-detector-block-does-not-really-work.-It-need-to-be-fixed-tp29415858p29526305.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] Peak detector block does not really work. It need to be fixed
On Tue, Aug 24, 2010 at 01:49:09PM -0700, Phong Do wrote: Hello Tom, Can you explain me why should gr_peak_detector need negative inputs ? If you use grep, you can find places in the code where it is used, and then answer your own question. What about the variable look ahead ? I wrote in the last message that look ahead has no function in gr_peak_detector. My guess is that look_ahead was a feature that turned out not to be needed to solve the problem at hand, but was accidentally left in the constructor. Do you know how can I add this feature in peak detector ? Yes. Write the code that implements it. Eric On Thu, Aug 12, 2010 at 8:26 AM, Phong Do stadtwald...@yahoo.de wrote: Hello, I'm working now with peak_detector block and find out that some functions don't really work. I've used the following 2 blocks: - Peak Detector (gr_peak_detector): the parameter look ahead seems have no function. I gave look ahead many values but the peak value did not change. I've seen in the gr_peak_detector_xx.cc that the variable d_look_ahead is called but it is not used in the main program. So I think the developer has forgotten this function. - Peak Detector 2 (gr_peak_detector2): in this block look ahead is used, but sometimes the peak detector freezes (output signal stops running in scope sink). I've changed the cpp code a little bit and it does not freeze anymore. But I'm not sure if the detector will work correctly after that. Here is what I've changed: original code: return tmp - 1; changed code: return tmp; Can anyone of the development team have a look at the 2 cpp ? best regards Phong Do Keep in mind that the gr_peak_detector actually expects negative inputs. So if your signal goes from 0 to 100, adjust it so that it goes from -100 to 0. Of course, I say keep in mind even though we probably haven't provided any documentation in the code to that affect... Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
So far, the only way I've been able to get gnuradio to link against libusb-legacy has been to uninstall libusb-1.0. Even when I overrode pkg-config by setting the USB_* variables, it'd still (apparently) link against libusb-1.0 and then crash at runtime when it couldn't find the _usb_debug symbol. Hopefully I'll be able to find a workaround for this since I'd like to use some other stuff that requires libusb-1.0, but in the mean time this seems to have fixed my usrper problem. I configured this way: ./configure \ CC=/usr/bin/gcc \ CXX=/usr/bin/g++ \ LDFLAGS=-F/opt/local/Library/Frameworks -L/opt/local/lib \ CPPFLAGS=-I/opt/local/include -I/opt/local/include/qwt -I/opt/local/include/qwtplot3d \ --with-fusb-tech=darwin Now usrper appears to be happy: ~/gnuradio% usrper -v load_standard_bits usrper: found unconfigured usrp; needs firmware. ~/gnuradio% usrper -v get_hash0 hash: ???7???g8!?_Md ~/gnuradio% usrper -v set_hash0 deadbeef ~/gnuradio% usrper -v get_hash0 hash: deadbeef ~/gnuradio% While I don't know what any of those usrper commands are actually doing, at least they seem to be not-crashing! -- 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
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Tue, Aug 24, 2010 at 4:18 PM, Mark J. Blair n...@nf6x.net wrote: Now usrper appears to be happy: ~/gnuradio% usrper -v load_standard_bits usrper: found unconfigured usrp; needs firmware. ~/gnuradio% usrper -v get_hash0 hash: ???7???g8!?_Md ~/gnuradio% usrper -v set_hash0 deadbeef ~/gnuradio% usrper -v get_hash0 hash: deadbeef ~/gnuradio% While I don't know what any of those usrper commands are actually doing, at least they seem to be not-crashing! Good to hear that it's all working. Unless you're writing your own firmware, usrper is usually limited in terms usefulness. If you're wondering, the hash commands are used for conditional loading of the fpga or USB controller. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large FFTs
Hi, Your reply is related to running the FFT on the CPU, right? Do you have any experience running it on the FPGA of the USRP1 or USRP2? No, but I know that radio astronomers do this. I have done FFT with CUDA. As long as you can keep the data inside the GPU for long enough, you can get pretty nice performance. We have done our prior developments with the GPU http://www.springerlink.com/content/j17244nu708381n6/ But since we were looking for a cheaper front-end solution, we stumbled over GNU radio. If there would be a way to do the FFT on the FPGA (for the signal) and do the rest on the GPU we should be able to speed up things. Anyway, thanks. Thomas -- ** 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
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
Hi Mark - I'm glad you got it working; if you installed all of the background dependencies with MacPorts, compiling GNU Radio should be as simple as: [fix bootstrap] ./bootstrap ./configure make make check sudo make install with no other options. IIRC, the 3 primary environment variables you need to have set are PATH (so that /opt/local/bin comes first), PYTHONPATH (so that /opt/local/lib/python2.6/site-packages comes first), and PKG_CONFIG_PATH (so that /opt/local/lib/pkgconfig comes first). You do not need to set --with-fusb-tech at all; it will auto-detect. You also don't need to set LDFLAGS as you have. Further, I don't think gr-qtgui is working on OSX just yet, so you really don't need to set CPPFLAGS either. And, you can have MacPorts select the CC and CXX for you via gcc_select -- so those aren't necessary. My question now is whether or not the other tests you talked about work (e.g., usrp_benchmark_usb.py). If that works, then you're good to go can play around with all the other pieces of GNU Radio USRP. But, I'm glad you've gotten this far. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Aug 24, 2010, at 4:58 PM, Michael Dickens wrote: Hi Mark - I'm glad you got it working; if you installed all of the background dependencies with MacPorts, compiling GNU Radio should be as simple as: [fix bootstrap] ./bootstrap ./configure Should be... but isn't. with no other options. IIRC, the 3 primary environment variables you need to have set are PATH (so that /opt/local/bin comes first), PYTHONPATH (so that /opt/local/lib/python2.6/site-packages comes first), and PKG_CONFIG_PATH (so that /opt/local/lib/pkgconfig comes first). You do not need to set --with-fusb-tech at all; it will auto-detect. You also don't need to set LDFLAGS as you have. Further, I don't think gr-qtgui is working on OSX just yet, so you really don't need to set CPPFLAGS either. And, you can have MacPorts select the CC and CXX for you via gcc_select -- so those aren't necessary. The --with-fusb-tech probably isn't necessary for me since I temporarily uninstalled libusb-1.0, but with that installed I found it to be necessary to specify --with-fusb-tech=libusb1 to get it to work. Anyhting else would cause the USRP code to crash when it failed to find the _usb_debug symbol. I have /opt/local/lib in my path, but I found it necessary to force the compilation to use the native compilers in /usr/bin instead in order to find the Mac frameworks. I chose to do this with the CC and CXX variables instead of gcc_select in this case. I modified my site.py file so it wouldn't be necessary to add that site-packages directory to my PYTHONPATH. The CPPFLAGS and LDFLAGS variable settings were necessary to get gr-qtgui to build, though I don't know if it actually works yet. In particular, some of the code included qwt and qwtplot3d headers without specifying their subdirectories (i.e., foo.h vs. qwt/foo.h), so I had to add the -I flags to get them to be found. I also had to add that -F flag for the linker to find the QtOpenGL framework. I don't know if there's something screwy about my system configuration, but that's what I had to do to get things to build and run. My question now is whether or not the other tests you talked about work (e.g., usrp_benchmark_usb.py). If that works, then you're good to go can play around with all the other pieces of GNU Radio USRP. Ah, good question. I've already been playing with some of the scripts such as usrp_fft.pw, usrp_siggen.py and a few others, and with grc, but there have been a bunch of pieces that didn't work. I'll try the benchmark script now that I've fixed (?) the USB stuff... Success! It consistently gives me one USB under-run (I think; it prints uU) at the beginning, but then runs and declares I can get 32MB/sec throughput. One of the other things that hasn't been working still isn't, but I think it's an unrelated error. When I run usrp_am_mw_rcv.py it complains: RuntimeError: gr_remez: insufficient extremals -- cannot continue But, I'm glad you've gotten this far. - MLD Thanks! I didn't expect it to be entirely painless (particularly since I'm running not-Linux here), and I'll keep plugging along. -- 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
