Re: [Discuss-gnuradio] LFTX Rev 2.2 Compatibility Issue with USRP2
On 06/20/2012 05:08 PM, juancolon wrote: > > Hi, > > We have a USRP2 with a LFTX Rev 2.2 daughterboard. When I run a GRC program, > I try to look at the signal with a spectrum analyzer and the signal is not > there. There is no error at all, everything seems to be up and running. The > system is recognizing the USRP2, daughterboard and I have also played around > with the subdev's but everything is correct. > > To make sure there is nothing wrong with the LFTX, I pulled it out from the > USRP2 and installed it on a USRP N210. In the N210 I re-run the same exact > GRC program and finally see the signal at the spectrum analyzer. To confirm > that the USRP2 transmit side is working, I've installed a RFX1800 and re-run > the same GRC program and this also works perfect. > LFTX and RFX1800 have very different frequency ranges. Perhaps you are not looking in the right frequency range for your signal? LFTX is just a direct line from the DAC, so +/- 30 or so MHz centered about DC. I suggest putting a known signal into the usrp sink and put a scope on the output of the LFTX. If RFX is working, the DAC output should definitely be there. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-filter tests
On Thu, Jun 21, 2012 at 11:18:36PM -0400, Tom Rondeau wrote: > So if you run 'make test' after getting the most recent master branch > and you see any test failures, let me know. If you get failures, the > first thing to do is run "volk_profile". This is a program that is > installed into $prefix/bin that will test all Volk kernels and select > the fastest version for your machine. Rerun 'make test' and let me > know if this fixes any problems. If you still have problems, please > send me the unit test output files found at > $builddir/gr-filter/lib/.unittests/gr_filter.xml and > $builddir/gr-filter/python/unittests/python/tests_*.xml. That should > help me get an understanding for what's going wrong. pfb_channelizer fails here (on a 32-bit Ubuntu), before and after volk_profile (XML attached). It's a very close mismatch of floats, though. I'll try this on a different machine later. M -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association (-0.9921348736850316-0.12517344933326072j) != (-0.9921236038208008-0.1252521276473999j) within 4 places File "/usr/lib/python2.7/unittest/case.py", line 327, in run testMethod() File "/home/braun/src/gnuradio/gr-filter/python/qa_pfb_channelizer.py", line 99, in test_000 self.assertComplexTuplesAlmostEqual(expected2_data[-Ntest:], dst2_data[-Ntest:], 4) File "/home/braun/src/gnuradio/gnuradio-core/src/python/gnuradio/gr_unittest.py", line 71, in assertComplexTuplesAlmostEqual self.assertComplexAlmostEqual (a[i], b[i], places, msg) File "/home/braun/src/gnuradio/gnuradio-core/src/python/gnuradio/gr_unittest.py", line 47, in assertComplexAlmostEqual (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) pgp35y338Je12.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Q's on gr-filter (was: Developers' Call for June, 2012)
On Thu, Jun 21, 2012 at 08:35:14AM -0400, Tom Rondeau wrote: > Apologies for the late posting. We will be having our monthly > developers call today (third Thursday). > > Call time is 4 PM (1600) EDT or 2000 UTC. Hi, I didn't make it to the call (10 PM is a bit of an awkward time for me), but I have a couple of questions/comments on gr-filter: - I like the namespace usage! Finally this is how it should be. - The automatic doc-block export to Python does not work in gr-filter (yet). - Also, (and yes, this is nitpicking), can Doxygen be changed such that it says '#include ' instead of '#include ' in the block documentation? - Can you please comment on making *all* blocks virtual and totally separating the DSP from the block definition? Is this simply taking the separation to a new 'extreme', or are there other reasons? Is it still possible to make the block non-virtual and put everything inside? And how on earth did you convince SWIG to understand all of this (that's not really a question, more an expression of how impressed I am). - Will everything look like this eventually (namespaces, virtual blocks)? In particular, will you change gr-howto-write-a-block in the same fashion (that will throw spanners into gr-modtool, but I'll figure out a way how to handle that). - By which logic is mmse_fir_interpolator_cc.cc not a '_impl.cc' file? Thanks for any answers... MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpq5vJPoqArp.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] up converter circuit
Hello, I wonder if someone might be able to provide me with a link to an up converter circuit? I want to extend the range (downwards) of my ezcap dongle. A Google search hasn't provided anything useful. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] up converter circuit
On Friday 22 Jun 2012 11:47:13 Phil wrote: > A Google search hasn't provided anything useful. Add 'funcube' to your search query. alexd ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] up converter circuit
On 22/06/12 21:01, Alex Dekker wrote: On Friday 22 Jun 2012 11:47:13 Phil wrote: > A Google search hasn't provided anything useful. Add 'funcube' to your search query. Thanks yet again Alex. I found several articles. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-filter tests
On Fri, Jun 22, 2012 at 11:17:50AM +0200, Martin Braun (CEL) wrote: > I'll try this on a different machine later. On a 64-Bit Ubuntu 12.04 with an i3 (using Volk machine avx_64), test_gr_filter fails here (I ran volk_profile before). XML attached. I should mention that I pulled the source from the first test from 'next', on the 64-bit machine, it was from 'master'. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association gr::filter::fff::qa_fir_filter_with_buffer_fff::t1 Assertion /home/braun/src/gnuradio/gr-filter/lib/qa_fir_filter_with_buffer.cc 163 double equality assertion failed - Expected: 15802834 - Actual : -nan - Delta : 671.0067225 gr::filter::qa_mmse_fir_interpolator_ff::t1 Assertion /home/braun/src/gnuradio/gr-filter/lib/qa_mmse_fir_interpolator_ff.cc 62 double equality assertion failed - Expected: 1.45274364948273 - Actual : -nan - Delta : 0.004 gr::filter::qa_firdes::t1 gr::filter::qa_firdes::t2 gr::filter::qa_firdes::t3 gr::filter::qa_firdes::t4 gr::filter::qa_firdes::t5 gr::filter::qa_firdes::t6 gr::filter::qa_firdes::t7 gr::filter::fff::qa_fir_filter_with_buffer_fff::t2 gr::filter::fff::qa_fir_filter_with_buffer_fff::t3 gr::filter::ccc::qa_fir_filter_with_buffer_ccc::t1 gr::filter::ccc::qa_fir_filter_with_buffer_ccc::t2 gr::filter::ccc::qa_fir_filter_with_buffer_ccc::t3 gr::filter::ccf::qa_fir_filter_with_buffer_ccf::t1 gr::filter::ccf::qa_fir_filter_with_buffer_ccf::t2 gr::filter::ccf::qa_fir_filter_with_buffer_ccf::t3 gr::filter::qa_mmse_fir_interpolator_cc::t1 18 2 0 2 pgpY1pQ3vtepa.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hello, someone has worked as the spectrum analyzer usrp2 ?
___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Possible bug and performance improvement in digital_fll_band_edge_cc.cc
Hello all I believe I have found a bug in digital_fll_band_edge_cc.cc: with the same input under different cpu loads I see different outputs. It seems to have something to do with how the block uses output history from the output_items parameter. Modifying it to use its own internal buffer to store output for the next iteration instead of using the output_items parameter seems to fix the problem. Also modifying digital_fll_band_edge_cc to use SSE instructions for its dot product instead of a for loop gives a nice performance improvement. I have attached diffs of my version of the files. Regards Hendrik van Wyk digital_fll_band_edge_cc.cc.patch Description: Binary data digital_fll_band_edge_cc.h.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LFTX Rev 2.2 Compatibility Issue with USRP2
Hi Josh, Definitely both daughterboards has different frequency ranges, I just wanted to test the TX channel of the USRP2 to make sure is working. That is the way I'm testing the LFTX, I have a spectrum analyzer connected to the RX ports. This is the flowgraph: SignaSource ---> UHD:USRPSink I have tested the USRP2 with previous UHD and also with the legacy gnuradio version, but did not work either. LFTX pins are OK, and it works in the N210, so probably something with the USRP2 motherboard. Thanks for suggestions, Juan Josh Blum-3 wrote: > > > > On 06/20/2012 05:08 PM, juancolon wrote: >> >> Hi, >> >> We have a USRP2 with a LFTX Rev 2.2 daughterboard. When I run a GRC >> program, >> I try to look at the signal with a spectrum analyzer and the signal is >> not >> there. There is no error at all, everything seems to be up and running. >> The >> system is recognizing the USRP2, daughterboard and I have also played >> around >> with the subdev's but everything is correct. >> >> To make sure there is nothing wrong with the LFTX, I pulled it out from >> the >> USRP2 and installed it on a USRP N210. In the N210 I re-run the same >> exact >> GRC program and finally see the signal at the spectrum analyzer. To >> confirm >> that the USRP2 transmit side is working, I've installed a RFX1800 and >> re-run >> the same GRC program and this also works perfect. >> > > LFTX and RFX1800 have very different frequency ranges. Perhaps you are > not looking in the right frequency range for your signal? LFTX is just a > direct line from the DAC, so +/- 30 or so MHz centered about DC. > > I suggest putting a known signal into the usrp sink and put a scope on > the output of the LFTX. If RFX is working, the DAC output should > definitely be there. > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/LFTX-Rev-2.2-Compatibility-Issue-with-USRP2-tp34044804p34054371.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using the UHD API for Python Programming
Hi all, I'm having some trouble using the C++ UHD API for writing Python code. I understand that the code has been SWIG'd from C++ to Python. Specifically, the C++ code I want to convert to Python is: --- uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); stream_cmd.num_samps = samps_to_recv; stream_cmd.stream_now = false; stream_cmd.time_spec = time_to_recv; usrp->issue_stream_cmd(stream_cmd); uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1); usrp->set_command_time(cmd_time); usrp->set_rx_freq(1.03e9, 0/*ch0*/); usrp->set_rx_freq(1.03e9, 1/*ch1*/); usrp->set_clear_time(); With my attempt at Python: --- self.stream_cmd = uhd.stream_cmd_t(uhd.stream_cmd_t.stream_mode_t.STREAM_MODE_NUM_SAMPS_AND_DONE) self.stream_cmd.num_samps = samps_to_recv; self.stream_cmd.stream_now = false; self.stream_cmd.time_spec = time_to_recv; self.uhd_usrp_source_0.issue_stream_cmd(self.stream_cmd) cmd_time = self.uhd_usrp_source_0.get_time_now() + uhd.time_spec_t(0.1) self.uhd_usrp_source_0.set_command_time(cmd_time) self.uhd_usrp_source_0.set_rx_freq(1.03e9, 0) self.uhd_usrp_source_0.set_rx_freq(1.03e9, 1) self.uhd_usrp_source_0.set_clear_time() - Running this, I get the error: AttributeError: 'module' object has no attribute 'stream_cmd_t' What is this struct called after it has been swigged into Python, and how do I access it? As a follow up, does anyone have any general guidelines to follow when writing code from the C++ UHD API into Python? I've checked the gr-uhd source tree examples, but they didn't provide the insight needed to access the full C++ API. -Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-announce] Announcing the LiveUSB SDR Environment
Hi Matt, Could you pass us the apt repository address? Will the included OpenBTS versio work with a single RFX900 and a USRP1? Best regards, Rafael Diniz > Yes, the link is on the order page. > > Matt > > On Tue, Jun 19, 2012 at 8:55 PM, S'dir wrote: >> Hi Matt, >> >> Would like to know if there is an iso image file which we can write to >> CD/USB. >> >> Thanks & Regds, >> Sudhir. >> >> On Tue, Jun 19, 2012 at 2:27 AM, Matt Ettus wrote: >>> >>> Ettus Research has released the LiveUSB SDR Environment - a 16 GB >>> bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10, >>> UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated >>> documentation. The SDR Environment enables users to get up and running >>> with the USRP product family quickly and easily, and lets users >>> familiarize themselves with the included software before installing it >>> on their own. Additionally, the portability of the LiveUSB file >>> system can be used to deploy standard configurations in classrooms, >>> R&D labs, or other USRP installations. >>> >>> https://www.ettus.com/product/details/LiveUSB >>> >>> Features: >>> * Ubuntu 11.10, 64-bit >>> * Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, >>> OpenBTS >>> * Documentation Included on Drive >>> * 16 GB >>> * USB 3.0 Read/Write Speeds - fast boot times and RF record/playback >>> capability >>> * USB 2.0 Fallback >>> * Persistent File system - save files, configurations, and other >>> customizations >>> * Portability - take your projects with you and boot on any PC >>> >>> The LiveUSB includes the most recent release of UHD, GNU Radio, and >>> OpenBTS. UHD is compatible with all USRP devices, and allows >>> applications to be easily ported across different USRP models. The >>> UHD installation includes documentation and examples. GNU Radio is an >>> easy-to-use, open-source, DSP toolbox that comes with GNU Radio >>> Companion, a graphical development tool. OpenBTS is an open-source >>> GSM air-interface implementation, which can be used with the USRP >>> product family to assemble a fully functional cellular base station. >>> >>> The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio >>> from the Ettus Research 'apt' repositories. This allows users to >>> update the software without manually downloading, building, and >>> installing the source code. >>> >>> This drive is compatible with USB 2.0 ports, but the system will take >>> longer to boot, load programs, and respond to user interaction. >>> >>> Now, developing with the USRP product family is as easy as plugging in >>> the LiveUSB SDR Environment and booting up! >>> >>> You can buy a USB 3 Flash Drive with the environment on it here: >>> >>> https://www.ettus.com/product/details/LiveUSB >>> >>> Matt Ettus >>> >>> ___ >>> USRP-announce mailing list >>> usrp-annou...@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-announce_lists.ettus.com >> >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Q's on gr-filter (was: Developers' Call for June, 2012)
On Fri, Jun 22, 2012 at 2:42 AM, Martin Braun (CEL) wrote: > I didn't make it to the call (10 PM is a bit of an awkward time for me), > but I have a couple of questions/comments on gr-filter: > > - I like the namespace usage! Finally this is how it should be. > Many agree with you :-) > - The automatic doc-block export to Python does not work in gr-filter > (yet). > - Also, (and yes, this is nitpicking), can Doxygen be changed such that > it says '#include ' instead of '#include > ' in the block documentation? > I'm sure these can be fixed at the same time. > - Can you please comment on making *all* blocks virtual and totally > separating the DSP from the block definition? Is this simply taking the > separation to a new 'extreme', or are there other reasons? Is it still > possible to make the block non-virtual and put everything inside? > I don't quite follow your question. Could you elaborate? > And how on earth did you convince SWIG to understand all of this > (that's not really a question, more an expression of how impressed I > am). > Actually, it wasn't that much work. SWIG didn't originally support namespaces (that was the reason this wasn't done back in the origin 2.8 C++ API.) Somewhere along the line, it did. Moving the shared pointer definition and 'make' function into the class definition, and moving all the private stuff out of the public header, allowed a simple three-lines-per-block style in a single SWIG .i file for the whole thing. > - Will everything look like this eventually (namespaces, virtual > blocks)? In particular, will you change gr-howto-write-a-block in the > same fashion (that will throw spanners into gr-modtool, but I'll > figure out a way how to handle that). > Yes, all the block code will change including the howto stuff. It's not clear yet whether some internal code that is not exported to the API is worth converting. > - By which logic is mmse_fir_interpolator_cc.cc not a '_impl.cc' file? > It's not actually a block, and the header isn't exported. It is code used internally by the fractional_interporlator_cc and _ff blocks, which *are* impled. Tom did a lot of work to get gr-filter done in the new API style. I'll make another post summarizing the current status of all the other 3.7 stuff Tom and I are working on. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the UHD API for Python Programming
On 06/22/2012 07:33 AM, Alexander Olihovik wrote: > Hi all, > I'm having some trouble using the C++ UHD API for writing Python code. > I understand that the code has been SWIG'd from C++ to Python. > > > Specifically, the C++ code I want to convert to Python is: > --- > uhd::stream_cmd_t > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); > stream_cmd.num_samps = samps_to_recv; > stream_cmd.stream_now = false; > stream_cmd.time_spec = time_to_recv; > usrp->issue_stream_cmd(stream_cmd); > Stream command is not swigged because the control of streaming is part of gnuradio's scheduler. So start() and stop() get automatically called by the scheduler. For convenience this is a set_command_time() to control stream_cmd.time_spec. Basically, gnuradio is handling the streaming for you. Think block-based streaming model. > uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1); > usrp->set_command_time(cmd_time); > usrp->set_rx_freq(1.03e9, 0/*ch0*/); > usrp->set_rx_freq(1.03e9, 1/*ch1*/); > usrp->set_clear_time(); This part is swigged. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Block key "rtl2832_source" not found in Platform
Dear All,
I am new of SDR. I've read a lot and compiled Gnuradio and gr-baz on my macbook
snow leopard 10.6.8but nothing, gnuradio doesn't recognize my ezcap as
source...It's a week that I try different combinations but i really don't
understand what to change.
Can you help me?
Many Thanks
Giulio
MacBook-di-Giulio:~ Giulio$ export
PYTHONPATH=$PYTHONPATH:/opt/local/lib/python2.6/site-packages:/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/:/usr/local/lib/python2.7/site-packages/
MacBook-di-Giulio:~ Giulio$
gnuradio-companion/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/random/__init__.py:87:
RuntimeWarning: compiletime version 2.6 of module 'mtrand' does not match
runtime version 2.7
from mtrand import *
<<< Welcome to GNU Radio Companion 3.3.0 >>>
Loading: "/Users/Giulio/rtl2832-fm.grc"
>>> Error: Block key "rtl2832_source" not found in Platform - grc(GNU Radio
>>> Companion)
Traceback (most recent call last):
File "/opt/local/bin/gnuradio-companion", line 51, in
try: gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc',
256, 0))
GError: Icona «gnuradio-grc» non presente nel tema
>>> Error: Connection between rtl2832_source_0(0) and
>>> gr_freq_xlating_fir_filter_xxx_0(0) could not be made.
Traceback (most recent call last):
File "/opt/local/lib/python2.6/site-packages/gnuradio/grc/base/FlowGraph.py",
line 197, in import_data
assert(source_block_id in block_ids)
AssertionError
>>> Done
Showing: "/Users/Giulio/rtl2832-fm.grc"
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-announce] Announcing the LiveUSB SDR Environment
Hi Matt, Thanks able to download casper-rw file. Could you please point me to the instructions about how to make bootable usb from casper-rw file. Regds, Sudhir. On Wed, Jun 20, 2012 at 10:24 PM, Matt Ettus wrote: > Yes, the link is on the order page. > > Matt > > On Tue, Jun 19, 2012 at 8:55 PM, S'dir wrote: > > Hi Matt, > > > > Would like to know if there is an iso image file which we can write to > > CD/USB. > > > > Thanks & Regds, > > Sudhir. > > > > On Tue, Jun 19, 2012 at 2:27 AM, Matt Ettus wrote: > >> > >> Ettus Research has released the LiveUSB SDR Environment - a 16 GB > >> bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10, > >> UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated > >> documentation. The SDR Environment enables users to get up and running > >> with the USRP product family quickly and easily, and lets users > >> familiarize themselves with the included software before installing it > >> on their own. Additionally, the portability of the LiveUSB file > >> system can be used to deploy standard configurations in classrooms, > >> R&D labs, or other USRP installations. > >> > >> https://www.ettus.com/product/details/LiveUSB > >> > >> Features: > >> * Ubuntu 11.10, 64-bit > >> * Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, OpenBTS > >> * Documentation Included on Drive > >> * 16 GB > >> * USB 3.0 Read/Write Speeds - fast boot times and RF record/playback > >> capability > >> * USB 2.0 Fallback > >> * Persistent File system - save files, configurations, and other > >> customizations > >> * Portability - take your projects with you and boot on any PC > >> > >> The LiveUSB includes the most recent release of UHD, GNU Radio, and > >> OpenBTS. UHD is compatible with all USRP devices, and allows > >> applications to be easily ported across different USRP models. The > >> UHD installation includes documentation and examples. GNU Radio is an > >> easy-to-use, open-source, DSP toolbox that comes with GNU Radio > >> Companion, a graphical development tool. OpenBTS is an open-source > >> GSM air-interface implementation, which can be used with the USRP > >> product family to assemble a fully functional cellular base station. > >> > >> The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio > >> from the Ettus Research 'apt' repositories. This allows users to > >> update the software without manually downloading, building, and > >> installing the source code. > >> > >> This drive is compatible with USB 2.0 ports, but the system will take > >> longer to boot, load programs, and respond to user interaction. > >> > >> Now, developing with the USRP product family is as easy as plugging in > >> the LiveUSB SDR Environment and booting up! > >> > >> You can buy a USB 3 Flash Drive with the environment on it here: > >> > >>https://www.ettus.com/product/details/LiveUSB > >> > >> Matt Ettus > >> > >> ___ > >> USRP-announce mailing list > >> usrp-annou...@lists.ettus.com > >> http://lists.ettus.com/mailman/listinfo/usrp-announce_lists.ettus.com > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the UHD API for Python Programming
For get_time_now(), would I need to swig multi_usrp.hpp? On Fri, Jun 22, 2012 at 12:19 PM, Josh Blum wrote: > > > On 06/22/2012 07:33 AM, Alexander Olihovik wrote: > > Hi all, > > I'm having some trouble using the C++ UHD API for writing Python code. > > I understand that the code has been SWIG'd from C++ to Python. > > > > > > Specifically, the C++ code I want to convert to Python is: > > --- > > uhd::stream_cmd_t > > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); > > stream_cmd.num_samps = samps_to_recv; > > stream_cmd.stream_now = false; > > stream_cmd.time_spec = time_to_recv; > > usrp->issue_stream_cmd(stream_cmd); > > > > Stream command is not swigged because the control of streaming is part > of gnuradio's scheduler. So start() and stop() get automatically called > by the scheduler. For convenience this is a set_command_time() to > control stream_cmd.time_spec. > > Basically, gnuradio is handling the streaming for you. Think block-based > streaming model. > > > uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1); > > usrp->set_command_time(cmd_time); > > usrp->set_rx_freq(1.03e9, 0/*ch0*/); > > usrp->set_rx_freq(1.03e9, 1/*ch1*/); > > usrp->set_clear_time(); > > This part is swigged. > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- *Alex Olihovik University of Virginia 2013 BS Electrical Engineering BS Computer Engineering ano...@virginia.edu* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the UHD API for Python Programming
There's already a "get_time_now" method swigged in the
gr_uhd_usrp_{source,sink} block, along with a "get_time_last_pps" method if you
need to synchronize to an absolute time.
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Alexander Olihovik
Sent: Friday, June 22, 2012 1:18 PM
To: j...@ettus.com
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Using the UHD API for Python Programming
For get_time_now(), would I need to swig multi_usrp.hpp?
On Fri, Jun 22, 2012 at 12:19 PM, Josh Blum
mailto:j...@ettus.com>> wrote:
On 06/22/2012 07:33 AM, Alexander Olihovik wrote:
> Hi all,
> I'm having some trouble using the C++ UHD API for writing Python code.
> I understand that the code has been SWIG'd from C++ to Python.
>
>
> Specifically, the C++ code I want to convert to Python is:
> ---
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
> stream_cmd.num_samps = samps_to_recv;
> stream_cmd.stream_now = false;
> stream_cmd.time_spec = time_to_recv;
> usrp->issue_stream_cmd(stream_cmd);
>
Stream command is not swigged because the control of streaming is part
of gnuradio's scheduler. So start() and stop() get automatically called
by the scheduler. For convenience this is a set_command_time() to
control stream_cmd.time_spec.
Basically, gnuradio is handling the streaming for you. Think block-based
streaming model.
> uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
> usrp->set_command_time(cmd_time);
> usrp->set_rx_freq(1.03e9, 0/*ch0*/);
> usrp->set_rx_freq(1.03e9, 1/*ch1*/);
> usrp->set_clear_time();
This part is swigged.
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Alex Olihovik
University of Virginia 2013
BS Electrical Engineering
BS Computer Engineering
ano...@virginia.edu
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the UHD API for Python Programming
On 06/22/2012 10:18 AM, Alexander Olihovik wrote: > For get_time_now(), would I need to swig multi_usrp.hpp? Everything you see in these headers should be available in python: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include -josh > > On Fri, Jun 22, 2012 at 12:19 PM, Josh Blum wrote: > >> >> >> On 06/22/2012 07:33 AM, Alexander Olihovik wrote: >>> Hi all, >>> I'm having some trouble using the C++ UHD API for writing Python code. >>> I understand that the code has been SWIG'd from C++ to Python. >>> >>> >>> Specifically, the C++ code I want to convert to Python is: >>> --- >>> uhd::stream_cmd_t >>> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); >>> stream_cmd.num_samps = samps_to_recv; >>> stream_cmd.stream_now = false; >>> stream_cmd.time_spec = time_to_recv; >>> usrp->issue_stream_cmd(stream_cmd); >>> >> >> Stream command is not swigged because the control of streaming is part >> of gnuradio's scheduler. So start() and stop() get automatically called >> by the scheduler. For convenience this is a set_command_time() to >> control stream_cmd.time_spec. >> >> Basically, gnuradio is handling the streaming for you. Think block-based >> streaming model. >> >>> uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1); >>> usrp->set_command_time(cmd_time); >>> usrp->set_rx_freq(1.03e9, 0/*ch0*/); >>> usrp->set_rx_freq(1.03e9, 1/*ch1*/); >>> usrp->set_clear_time(); >> >> This part is swigged. >> >> -josh >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-announce] Announcing the LiveUSB SDR Environment
Rafael - The apt repos are the same repos we provide for any Ubuntu installation. http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux OpenBTS is built for UHD devices. If you need to use the deprecated libusrp library, you can use the tools on the drive to re-build OpenBTS for your transceiver setup. Cheers, Ben On Fri, Jun 22, 2012 at 7:55 AM, Rafael Diniz wrote: > Hi Matt, > Could you pass us the apt repository address? > > Will the included OpenBTS versio work with a single RFX900 and a USRP1? > > Best regards, > Rafael Diniz > > > Yes, the link is on the order page. > > > > Matt > > > > On Tue, Jun 19, 2012 at 8:55 PM, S'dir wrote: > >> Hi Matt, > >> > >> Would like to know if there is an iso image file which we can write to > >> CD/USB. > >> > >> Thanks & Regds, > >> Sudhir. > >> > >> On Tue, Jun 19, 2012 at 2:27 AM, Matt Ettus wrote: > >>> > >>> Ettus Research has released the LiveUSB SDR Environment - a 16 GB > >>> bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10, > >>> UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated > >>> documentation. The SDR Environment enables users to get up and running > >>> with the USRP product family quickly and easily, and lets users > >>> familiarize themselves with the included software before installing it > >>> on their own. Additionally, the portability of the LiveUSB file > >>> system can be used to deploy standard configurations in classrooms, > >>> R&D labs, or other USRP installations. > >>> > >>> https://www.ettus.com/product/details/LiveUSB > >>> > >>> Features: > >>> * Ubuntu 11.10, 64-bit > >>> * Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, > >>> OpenBTS > >>> * Documentation Included on Drive > >>> * 16 GB > >>> * USB 3.0 Read/Write Speeds - fast boot times and RF record/playback > >>> capability > >>> * USB 2.0 Fallback > >>> * Persistent File system - save files, configurations, and other > >>> customizations > >>> * Portability - take your projects with you and boot on any PC > >>> > >>> The LiveUSB includes the most recent release of UHD, GNU Radio, and > >>> OpenBTS. UHD is compatible with all USRP devices, and allows > >>> applications to be easily ported across different USRP models. The > >>> UHD installation includes documentation and examples. GNU Radio is an > >>> easy-to-use, open-source, DSP toolbox that comes with GNU Radio > >>> Companion, a graphical development tool. OpenBTS is an open-source > >>> GSM air-interface implementation, which can be used with the USRP > >>> product family to assemble a fully functional cellular base station. > >>> > >>> The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio > >>> from the Ettus Research 'apt' repositories. This allows users to > >>> update the software without manually downloading, building, and > >>> installing the source code. > >>> > >>> This drive is compatible with USB 2.0 ports, but the system will take > >>> longer to boot, load programs, and respond to user interaction. > >>> > >>> Now, developing with the USRP product family is as easy as plugging in > >>> the LiveUSB SDR Environment and booting up! > >>> > >>> You can buy a USB 3 Flash Drive with the environment on it here: > >>> > >>>https://www.ettus.com/product/details/LiveUSB > >>> > >>> Matt Ettus > >>> > >>> ___ > >>> USRP-announce mailing list > >>> usrp-annou...@lists.ettus.com > >>> http://lists.ettus.com/mailman/listinfo/usrp-announce_lists.ettus.com > >> > >> > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the UHD API for Python Programming
So to tune two USRP N210s connected by a MIMO cable, I should set the command time to be some time spec, and then re-tune both channels to the same frequency, thus giving them the same phase offset? i.e. My code is looking more like: self.cmd_time = self.uhd_usrp_source_0.uhd.time_spec_t(.1) self.uhd_usrp_source_0.set_command_time(self.cmd_time) self.uhd_usrp_source_0.set_center_freq(freq, 0) self.uhd_usrp_source_0.set_center_freq(freq, 1) self.uhd_usrp_source_0.clear_command_time() The phases are still off... Is my method incorrect? On Fri, Jun 22, 2012 at 1:36 PM, Josh Blum wrote: > > > On 06/22/2012 10:18 AM, Alexander Olihovik wrote: > > For get_time_now(), would I need to swig multi_usrp.hpp? > > Everything you see in these headers should be available in python: > http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include > > -josh > > > > > On Fri, Jun 22, 2012 at 12:19 PM, Josh Blum wrote: > > > >> > >> > >> On 06/22/2012 07:33 AM, Alexander Olihovik wrote: > >>> Hi all, > >>> I'm having some trouble using the C++ UHD API for writing Python code. > >>> I understand that the code has been SWIG'd from C++ to Python. > >>> > >>> > >>> Specifically, the C++ code I want to convert to Python is: > >>> --- > >>> uhd::stream_cmd_t > >>> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); > >>> stream_cmd.num_samps = samps_to_recv; > >>> stream_cmd.stream_now = false; > >>> stream_cmd.time_spec = time_to_recv; > >>> usrp->issue_stream_cmd(stream_cmd); > >>> > >> > >> Stream command is not swigged because the control of streaming is part > >> of gnuradio's scheduler. So start() and stop() get automatically called > >> by the scheduler. For convenience this is a set_command_time() to > >> control stream_cmd.time_spec. > >> > >> Basically, gnuradio is handling the streaming for you. Think block-based > >> streaming model. > >> > >>> uhd::time_spec_t cmd_time = usrp->get_time_now() + > uhd::time_spec_t(0.1); > >>> usrp->set_command_time(cmd_time); > >>> usrp->set_rx_freq(1.03e9, 0/*ch0*/); > >>> usrp->set_rx_freq(1.03e9, 1/*ch1*/); > >>> usrp->set_clear_time(); > >> > >> This part is swigged. > >> > >> -josh > >> > >> ___ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > > > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the UHD API for Python Programming
On 06/22/2012 12:19 PM, Alexander Olihovik wrote: > So to tune two USRP N210s connected by a MIMO cable, I should set the > command time to be some time spec, and then re-tune both channels to the > same frequency, thus giving them the same phase offset? > > i.e. My code is looking more like: make sure you you tell the board to get its reference of clock and time source from the mimo cable > self.cmd_time = self.uhd_usrp_source_0.uhd.time_spec_t(.1) careful, make sure that cmd time is a time in the future > self.uhd_usrp_source_0.set_command_time(self.cmd_time) > self.uhd_usrp_source_0.set_center_freq(freq, 0) > self.uhd_usrp_source_0.set_center_freq(freq, 1) > self.uhd_usrp_source_0.clear_command_time() > > > The phases are still off... Is my method incorrect? > Synchronization of device time is separate from synchronizing the phase of the RF frontend. This may be helpful, with code examples for both: http://files.ettus.com/uhd_docs/manual/html/sync.html -Josh > On Fri, Jun 22, 2012 at 1:36 PM, Josh Blum wrote: > >> >> >> On 06/22/2012 10:18 AM, Alexander Olihovik wrote: >>> For get_time_now(), would I need to swig multi_usrp.hpp? >> >> Everything you see in these headers should be available in python: >> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include >> >> -josh >> >>> >>> On Fri, Jun 22, 2012 at 12:19 PM, Josh Blum wrote: >>> On 06/22/2012 07:33 AM, Alexander Olihovik wrote: > Hi all, > I'm having some trouble using the C++ UHD API for writing Python code. > I understand that the code has been SWIG'd from C++ to Python. > > > Specifically, the C++ code I want to convert to Python is: > --- > uhd::stream_cmd_t > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); > stream_cmd.num_samps = samps_to_recv; > stream_cmd.stream_now = false; > stream_cmd.time_spec = time_to_recv; > usrp->issue_stream_cmd(stream_cmd); > Stream command is not swigged because the control of streaming is part of gnuradio's scheduler. So start() and stop() get automatically called by the scheduler. For convenience this is a set_command_time() to control stream_cmd.time_spec. Basically, gnuradio is handling the streaming for you. Think block-based streaming model. > uhd::time_spec_t cmd_time = usrp->get_time_now() + >> uhd::time_spec_t(0.1); > usrp->set_command_time(cmd_time); > usrp->set_rx_freq(1.03e9, 0/*ch0*/); > usrp->set_rx_freq(1.03e9, 1/*ch1*/); > usrp->set_clear_time(); This part is swigged. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Limit on file_sources in GRC ?
Ubuntu 12.04 LTS, GNU Radio 3.6.1git-2-g2c7ea132 (on i7). I have a simple GRC flow with a couple of file sources - these are FIFOs. I have a separate application which will simulate various antenna configurations and it attempts to open both of these FIFOs in O_WRONLY|O_NONBLOCK . As the FIFO's are Write, the other end needs to be 'reading' in order that I don't get "No such device or address". I accomplish this by starting the GRC flow.The separate application attempts to open the FIFO's if unsuccessful 10 times. With either of the source files, only, enabled in GRC, I can get that FIFO open first time from the application but cannot get them both to open. Is there a limit on the # of file sources in GRC which is leading to this behaviour? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Limit on file_sources in GRC ?
Ubuntu 12.04 LTS, GNU Radio 3.6.1git-2-g2c7ea132 (on i7). I have a simple GRC flow with a couple of file sources - these are FIFOs. I have a separate application which will simulate various antenna configurations and it attempts to open both of these FIFOs in O_WRONLY|O_NONBLOCK . As the FIFO's are Write, the other end needs to be 'reading' in order that I don't get "No such device or address". I accomplish this by starting the GRC flow.The separate application attempts to open the FIFO's if unsuccessful 10 times. With either of the source files, only, enabled in GRC, I can get that FIFO open first time from the application but cannot get them both to open. Is there a limit on the # of file sources in GRC which is leading to this behaviour? Kind Regards, John The problem isn't, per se, Gnu Radio. The semantics of opening for write are such that there *must* be a reader available. Not so with opening for read, provided that you've opened NONBLOCK.Opening for read will block until there's a writer if it isn't opened NONBLOCK. So the problem is that you can't guarantee which *order* things will happen in -- that is, your opening for write may not correspond to the reader that Gnu Radio has opened (and is waiting to proceed). I'd say keep trying to open all of your writer FIFOs at once, and figure out which one(s) have succeeded. Pause a little between each iteration. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Limit on file_sources in GRC ?
On 23/06/12 14:00, Marcus D. Leech wrote: Ubuntu 12.04 LTS, GNU Radio 3.6.1git-2-g2c7ea132 (on i7). I have a simple GRC flow with a couple of file sources - these are FIFOs. I have a separate application which will simulate various antenna configurations and it attempts to open both of these FIFOs in O_WRONLY|O_NONBLOCK . As the FIFO's are Write, the other end needs to be 'reading' in order that I don't get "No such device or address". I accomplish this by starting the GRC flow.The separate application attempts to open the FIFO's if unsuccessful 10 times. With either of the source files, only, enabled in GRC, I can get that FIFO open first time from the application but cannot get them both to open. Is there a limit on the # of file sources in GRC which is leading to this behaviour? Kind Regards, John The problem isn't, per se, Gnu Radio. The semantics of opening for write are such that there *must* be a reader available. Not so with opening for read, provided that you've opened NONBLOCK. Opening for read will block until there's a writer if it isn't opened NONBLOCK. So the problem is that you can't guarantee which *order* things will happen in -- that is, your opening for write may not correspond to the reader that Gnu Radio has opened (and is waiting to proceed). I'd say keep trying to open all of your writer FIFOs at once, and figure out which one(s) have succeeded. Pause a little between each iteration. Thanks Marcus - will give that a try. I was hoping I didn't need to send data to the first FIFO opened so that the second one would/could succeed so this is good news; 1 TPB helps, I guess. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
