[Discuss-gnuradio] Can I use uhd_fft or gnu-radio to display the spectrum with adjustable frequency resolution
I am trying to use the uhd_fft or gnu-radio scope in a way that it can show a real-time spectrum but with adjustable resolution. The uhd_fft spectrum resolution appears to be fixed and not changeable. The gnu-radio scope block only puts out time series but not real-time spectrum. What is my way out of this situation? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Acceptable sampling rate and LO frequency for USRP LFRX
Hi, I have been using GRC and N210 to test my data acquisition scheme. My previous scheme worked well with probably standard sampling rate (10Msps) and LO at DC. When I switched to a non-standard sampling rate (1.2 Msps) and non-standard LO (1.105 MHz), all hell seems to break loose. One message appears to be helpful, says: Hardware does not support requested sampling rate, request 1.200.. Msps, actual 1.2048. Msps. I suspect my requested LO of 1.105 MHz also may not be met, but there is no message saying that. My question is: how do my find out the LFRX supported sampling rate and LO frequency? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Acceptable sampling rate and LO frequency for USRP LFRX
Thanks. Does the LO frequency also have to integer fraction of 100 MHz? From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org [mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of Marcus D. Leech Sent: Monday, July 29, 2013 11:52 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Acceptable sampling rate and LO frequency for USRP LFRX On 07/29/2013 02:47 PM, LD Zhang wrote: Hi, I have been using GRC and N210 to test my data acquisition scheme. My previous scheme worked well with probably standard sampling rate (10Msps) and LO at DC. When I switched to a non-standard sampling rate (1.2 Msps) and non-standard LO (1.105 MHz), all hell seems to break loose. One message appears to be helpful, says: Hardware does not support requested sampling rate, request 1.200.. Msps, actual 1.2048. Msps. I suspect my requested LO of 1.105 MHz also may not be met, but there is no message saying that. My question is: how do my find out the LFRX supported sampling rate and LO frequency? Thanks, LD The daughtercards don't know anything about sample rate. The available sample rates are determined by the motherboard hardware. In the case of the N210, the selected sample rate must be a proper integer fraction of the fixed ADC sample rate, which is 100Msps. -- 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
[Discuss-gnuradio] Question on using UHD Source Block to transmit accurate PM signal
Hi, I would like to use the N210 LFTX daughterboard to transmit bi-phase modulated signal. The phase switching need to be done accurately in a real-time sense, that is, the switching times has to be as accurate as possible, which means it should be controlled by the master clock of the N210. From Gnuradio, I see the UHD source block. But it doesn't take any input. My question really is: Gnuradio does things on the host computer, but the right thing to do is to do the real-time phase modulation on the LFTX daughterboard, to ensure hardware-controlled timing performance. I don't see a clear way to do this from the gnuradio interface. Are there any code examples or examples similar to the hardware-control aspect? Maybe people have done some python code that performs this kind of board-level manipulation that is controlled by the master clock? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A possible bug in the UHD source block?
Hi, I am doing testing with UHD source block set to a frequency at the center of my band of interest. Previous testing with LO set to DC works very well. The spectrum at the band of interest looks nice and flat. The new configuration with the new LO and a lower sampling rate (just to cover the band of interest) does not work as well as the default configuration. I see the same signal not showing up at the expected frequencies and the spectrum looks aliased. Is it possible that the UHD source block has a bug in this configuration? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing
Fantastic! Let us know if there are docs/links and code examples now. Or maybe we will wait till the August presentation? -Original Message- From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Tuesday, July 16, 2013 2:30 PM To: LD Zhang Cc: Nathan West; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing On Thu, Jul 11, 2013 at 7:17 PM, LD Zhang ldz10...@gmail.com wrote: Great, these discussions actually help a lot, I am going to initially design it to be a factor of 10 less than the theoretical limit. There is another question: in the case of no floating point operations at all, there must be a limit of how fast the data can stream through the Gnuradio environment. So is the limit like 10 Msps, or like 50 Msps? A 1 Msps data stream fed through 10 parallel ports is like 10 Msps data stream, correct? Thanks, LD Being able to calculate the cost of an SDR application running on a GPP would be fantastic, but it would only ever be an approximation. Instead, we've introduced the Performance Counters and a Performance Monitor application with GNU Radio 3.7.0 that simply measures the amount of time a block takes during a call to work. The paper that I'll be presenting at the SRIF workshop in August introduces this concept. I've also just written some documentation that will go into the manual soon that describes them better. The point of this tool is to see how well your application is running and to identify which blocks might be using too much CPU time to be singled out for optimization. It could also potentially be used to develop an understanding of how each block might work on your machine, which you could then use to extrapolate how much your system could process. Tom -Original Message- From: Nathan West [mailto:nathan.w...@okstate.edu] Sent: Thursday, July 11, 2013 3:35 PM To: LD Zhang Cc: Nathan West; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing On Thu, Jul 11, 2013 at 6:13 PM, LD Zhang ldz10...@gmail.com wrote: Hi, Please my comment below: You can probably get a rough estimate of the lower limit of your processors ability to do something like an FIR filter with some simple calculations: A 10-point FIR filter needs to do 10 multiplies and 9 additions. Blissfully ignoring branching that's 19 instructions for each output. So let's say we've got a simple FIR filter that outputs the same sample rate as it inputs. Using the table in here: http://en.wikipedia.org/wiki/Instructions_per_second it looks like modern CPUs clocked around 1GHz should expect between 2-5 IPS / (1/clock speed). Pick your favorite (I'm guessing you're on older hardware so let's go with 2). 2 * 1GHz = 2000 MIPs. So you can process 1M samples through a very poorly implemented 10-tap FIR filter. That in itself is also a pretty poor estimate. I see Marcus just replied as well and as he said, the best way to *know* is just to try it out on your hardware; there's no substitute for that. I am confused: 10-tap FIR according to the above is 19 IPs, so 1M samples correspond to 19 MIPS, much below the 2000 MIPS limit? Am I missing something? LD Hmm, I guess you're right. It's not too important because the actual estimate wouldn't be close to anything close to what you would see. The point is there is no easy answer (other than just running something to see if it works), but you might be able to come up with a rough estimate if you really need to and your application is really simple. You should probably ignore my lousy attempt :-P. I came up with it on the fly... There's also the issue of how long it takes those instructions to execute. -Nathan ___ 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] sustainable gnuradio MFLOPS for streaming processing
Hi Folks, The number of sustainable gnuradio processing speed - I guess in terms of MFLOPS - is important for designing application. Suppose I have a FIR filter with a number of taps operating on a streaming sample of x Msps, this would translate to a certain number of required MFLOPS. And this number needs to be below the sustainable gnuradio MFLOPS limit. Hence my question is say on a 1GHz processor, what is the gnuradio MFLOPS limit running on this processor? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing
Hi, Please my comment below: You can probably get a rough estimate of the lower limit of your processors ability to do something like an FIR filter with some simple calculations: A 10-point FIR filter needs to do 10 multiplies and 9 additions. Blissfully ignoring branching that's 19 instructions for each output. So let's say we've got a simple FIR filter that outputs the same sample rate as it inputs. Using the table in here: http://en.wikipedia.org/wiki/Instructions_per_second it looks like modern CPUs clocked around 1GHz should expect between 2-5 IPS / (1/clock speed). Pick your favorite (I'm guessing you're on older hardware so let's go with 2). 2 * 1GHz = 2000 MIPs. So you can process 1M samples through a very poorly implemented 10-tap FIR filter. That in itself is also a pretty poor estimate. I see Marcus just replied as well and as he said, the best way to *know* is just to try it out on your hardware; there's no substitute for that. I am confused: 10-tap FIR according to the above is 19 IPs, so 1M samples correspond to 19 MIPS, much below the 2000 MIPS limit? Am I missing something? LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing
Great, these discussions actually help a lot, I am going to initially design it to be a factor of 10 less than the theoretical limit. There is another question: in the case of no floating point operations at all, there must be a limit of how fast the data can stream through the Gnuradio environment. So is the limit like 10 Msps, or like 50 Msps? A 1 Msps data stream fed through 10 parallel ports is like 10 Msps data stream, correct? Thanks, LD -Original Message- From: Nathan West [mailto:nathan.w...@okstate.edu] Sent: Thursday, July 11, 2013 3:35 PM To: LD Zhang Cc: Nathan West; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] sustainable gnuradio MFLOPS for streaming processing On Thu, Jul 11, 2013 at 6:13 PM, LD Zhang ldz10...@gmail.com wrote: Hi, Please my comment below: You can probably get a rough estimate of the lower limit of your processors ability to do something like an FIR filter with some simple calculations: A 10-point FIR filter needs to do 10 multiplies and 9 additions. Blissfully ignoring branching that's 19 instructions for each output. So let's say we've got a simple FIR filter that outputs the same sample rate as it inputs. Using the table in here: http://en.wikipedia.org/wiki/Instructions_per_second it looks like modern CPUs clocked around 1GHz should expect between 2-5 IPS / (1/clock speed). Pick your favorite (I'm guessing you're on older hardware so let's go with 2). 2 * 1GHz = 2000 MIPs. So you can process 1M samples through a very poorly implemented 10-tap FIR filter. That in itself is also a pretty poor estimate. I see Marcus just replied as well and as he said, the best way to *know* is just to try it out on your hardware; there's no substitute for that. I am confused: 10-tap FIR according to the above is 19 IPs, so 1M samples correspond to 19 MIPS, much below the 2000 MIPS limit? Am I missing something? LD Hmm, I guess you're right. It's not too important because the actual estimate wouldn't be close to anything close to what you would see. The point is there is no easy answer (other than just running something to see if it works), but you might be able to come up with a rough estimate if you really need to and your application is really simple. You should probably ignore my lousy attempt :-P. I came up with it on the fly... There's also the issue of how long it takes those instructions to execute. -Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.7.0 available for download
Is it true that the blks2 is gotten rid of in 3.7? I have gotten used to some code that uses blks2 and some documentation. Will those online documentation/code examples also be updated with version 3.7? We are getting a new USRP, should I stick with 3.6 or go to 3.7? Thanks, LD -Original Message- From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org [mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of Johnathan Corgan Sent: Wednesday, July 03, 2013 12:03 PM To: Discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] GNU Radio release 3.7.0 available for download GNU Radio release 3.7.0 is available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.7.0.tar.gz MD5 sum: c2856ee14b415a64abf5dc9af0f5374c gnuradio-3.7.0.tar.gz This is a major new release of GNU Radio, culminating a year and a half of side-by-side development with the new features added to the GNU Radio 3.6 API. With the significant restructuring that was occurring as part of the 3.7 development, at times this seemed like rebuilding a race car engine while still driving it. All the appropriate bug fixes applied in the 3.6.0 - 3.6.5.1 series of releases were incorporated into 3.7.0 and are not re-listed here. Otherwise, this release has all the features added to 3.6 and the new ones listed below that could only be done in the 3.7 API. The GNU Radio SDR framework/runtime gained many new capabilities in 3.6, and our project focus now during the 3.7 development series will be to use these new capabilities to improve GNU Radio DSP block libraries and example applications. The detailed release notes follow. Contributors: Ben Reynwar b...@reynwar.net Gerald Baier gerald.ba...@student.kit.edu Jaroslav Škarvada jskar...@redhat.com Jeff Long j...@longhouse.net Johnathan Corgan johnat...@corganlabs.com Josh Blum j...@joshknows.com Mark Plett mark.pl...@jhuapl.edu Martin Braun martin.br...@kit.edu Michael Dickens m...@alum.mit.edu Nicholas Corgan nick.cor...@ettus.com Nick Foster n...@ettus.com Nick McCarthy namcc...@gmail.com Philip Balister phi...@balister.org Sreeraj Rajendran rsree...@gmail.com Tim Newman tim.new...@gmail.com Tim O'Shea tim.oshea...@gmail.com Tom Rondeau trond...@vt.edu Volker Schroer dl1...@gmx.de Code Structure Changes (Johnathan Corgan, Tom Rondeau) The GNU Radio source code was restructured and flattened. All top-level components now use the same structure for consistency and ease of use. All blocks were moved out of gnuradio-core, which has been renamed to gnuradio-runtime. The blocks are now in their appropriate top-level components and reimplemented with the new 3.7 API style. The new API makes use of C++ namespaces and the virtual private implementation class pattern to better hide GNU Radio internals from user code. Details about this can be found here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7 A Google doc showing all items that were moved from one place to another in the new style is here: http://ow.ly/mDpey Blocks not listed were already in their own components. Many blocks were removed. All columns marked with ‘-’ means that column is not applicable to that block or class. Any column (except those marked as Remove) that are blank means that we might be able to improve upon it, which normally indicates using VOLK or improving documentation. A Google doc showing the new component and Doxygen categories for all components is here: http://ow.ly/mDplO Important new features: ControlPort (Tom Rondeau, Tim O’Shea) ControlPort is a new interface for standardizing remote procedure calls in GNU Radio: * Remote control and visualization. * Use of ControlPort to debug without requiring extra debug streams. * Abstracted interface, but currently using ICE (www.zeroc.com). * No additional CPU usage while no monitoring is occurring. * Can connect multiple remotes to same GNU Radio application. * Can also have single ControlPort app control multiple GR apps. Each block creates interfaces to control data members, by defining ‘get’ and ‘set’ interface to query and update values of block variables. Preference files control the state of ControlPort in section [ControlPort] of gnuradio-runtime.conf. ControlPort comes with a generic utility to allow you to see all interfaces of a flowgraph: * gr-ctrlport-monitor ip address -p port Within a flowgraph, one can also use ControlPort probes to pass vectors of data to a ControlPort client, including complex IQ data. One useful probe calculates the power spectral density of a block output for remote display. See the ControlPort page in the GNU Radio manual for more information: http://gnuradio.org/doc/doxygen/page_ctrlport.html Performance Measurement Tools Performance Counters were first built into GNU Radio in 3.6.5, but could only be accessed locally. Now, all Performance Counters can be exported over ControlPort. Performance Counters must be compiled
[Discuss-gnuradio] Troubled by the pfb channelizer center frequency location
Dear Group, I am learning to do the pfb channelizer using the now famous example on the documentation page at: http://gnuradio.org/doc/doxygen/page_pfb.html The example is at the end of the page, where a 9-subchannels are pulled out of the original 9 kHz bandwidth signal. The original signals' tones are at [freqs = [-4070, -3050, -2030, -1010, 10, 1020, 2040, 3060, 4080] The original signal bandwidth should be from -4500 to 4500 Hz. According to my understanding the first channel signal should be centered at -70 Hz, since the 9 channels' centers should be at [-4000, -3000, ..., 3000, 4000]. But the output plot from the example shows that the first tone is at slightly greater than 0 Hz frequency. I don't know what is going on here? LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Troubled by the pfb channelizer center frequency location
I guess I got it! The default channel map is such that the first channel is the UN-fftshifted frequency location which is at 10 Hz (the 5th one on the list)! Whoo! It would be nice to tell a newcomer about this. LD From: LD Zhang [mailto:ldz10...@gmail.com] Sent: Wednesday, May 15, 2013 4:16 PM To: discuss-gnuradio Discussion Group Subject: Troubled by the pfb channelizer center frequency location Dear Group, I am learning to do the pfb channelizer using the now famous example on the documentation page at: http://gnuradio.org/doc/doxygen/page_pfb.html The example is at the end of the page, where a 9-subchannels are pulled out of the original 9 kHz bandwidth signal. The original signals' tones are at [freqs = [-4070, -3050, -2030, -1010, 10, 1020, 2040, 3060, 4080] The original signal bandwidth should be from -4500 to 4500 Hz. According to my understanding the first channel signal should be centered at -70 Hz, since the 9 channels' centers should be at [-4000, -3000, ..., 3000, 4000]. But the output plot from the example shows that the first tone is at slightly greater than 0 Hz frequency. I don't know what is going on here? LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] where is gnuradio-examples/python/pfb?
Hi, I am reading the polyphase filterbank documentation. It points to a directory where examples are contained: *gnuradio-examples/python/pfb. *In my installation I have the following directories and files: -rw-rw-r-- 1 ldz ldz 4041 Sep 18 2012 README-win32-mingw-short.txt -rw-rw-r-- 1 ldz ldz 10237 Sep 18 2012 README.hacking -rw-rw-r-- 1 ldz ldz 1695 Sep 18 2012 README.building-boost -rw-rw-r-- 1 ldz ldz 4846 Sep 18 2012 README -rw-rw-r-- 1 ldz ldz 35147 Sep 18 2012 COPYING -rw-rw-r-- 1 ldz ldz 9527 Sep 18 2012 CMakeLists.txt -rw-rw-r-- 1 ldz ldz 1155 Sep 18 2012 AUTHORS drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 cmake drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 docs drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gnuradio-core drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 dtools drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-atsc drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-comedi drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-audio drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-digital drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-fft drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-fcd drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-filter drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-noaa drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-howto-write-a-block drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-pager drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-qtgui drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 gr-trellis drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-shd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-utils drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-uhd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-video-sdl drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-vocoder drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 gr-wavelet drwxrwxr-x 4 ldz ldz 4096 Sep 18 2012 gr-wxgui drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gruel drwxrwxr-x 11 ldz ldz 4096 Sep 18 2012 grc drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 volk drwxrwxr-x 27 ldz ldz 4096 Sep 18 2012 build I don't see a gnuradio-examples directory either above or below this level. Other searches in other directories have yielded nothing. Is this a on-line location or a directory in the installation? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb?
Thanks I found it as in gr-filter/examples/python/pfb.py. I also found something in gnuradio-core/src/examples/pfb directory. Have to excuse my ignorance here since I haven't really worked that much with python approach. Have mostly stayed in GRC flow graph and used the generator to get the python code. Once I have the generated python code, then I can do simple edits to improve here and there. So I am not quite used to reading the code as is. My question is: Is there a way to re-display the pfb.py back onto the GRC graphical window? If not, what do I need to do in order to bring it back to GRC? Is what I am trying here making sense at all? Thanks a lot, LD -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Tuesday, May 14, 2013 1:47 PM To: LD Zhang Cc: discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb? Thanks for letting us know the documentation is out of date. You should find filterbank examples in gr-filter/examples. On Tue, May 14, 2013 at 12:28 PM, LD Zhang ldz10...@gmail.com wrote: Hi, I am reading the polyphase filterbank documentation. It points to a directory where examples are contained: gnuradio-examples/python/pfb. In my installation I have the following directories and files: -rw-rw-r-- 1 ldz ldz 4041 Sep 18 2012 README-win32-mingw-short.txt -rw-rw-r-- 1 ldz ldz 10237 Sep 18 2012 README.hacking -rw-rw-r-- 1 ldz ldz 1695 Sep 18 2012 README.building-boost -rw-rw-r-- 1 ldz ldz 4846 Sep 18 2012 README -rw-rw-r-- 1 ldz ldz 35147 Sep 18 2012 COPYING -rw-rw-r-- 1 ldz ldz 9527 Sep 18 2012 CMakeLists.txt -rw-rw-r-- 1 ldz ldz 1155 Sep 18 2012 AUTHORS drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 cmake drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 docs drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gnuradio-core drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 dtools drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-atsc drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-comedi drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-audio drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-digital drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-fft drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-fcd drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-filter drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-noaa drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-howto-write-a-block drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-pager drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-qtgui drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 gr-trellis drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-shd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-utils drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-uhd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-video-sdl drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-vocoder drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 gr-wavelet drwxrwxr-x 4 ldz ldz 4096 Sep 18 2012 gr-wxgui drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gruel drwxrwxr-x 11 ldz ldz 4096 Sep 18 2012 grc drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 volk drwxrwxr-x 27 ldz ldz 4096 Sep 18 2012 build I don't see a gnuradio-examples directory either above or below this level. Other searches in other directories have yielded nothing. Is this a on-line location or a directory in the installation? Thanks, LD ___ 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] where is gnuradio-examples/python/pfb?
Is it equivalent to use the pfb_channelizer_ccf block in the GRC though? Does the GRC approach suffer reduced capability vs. the python approach? LD -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Tuesday, May 14, 2013 2:30 PM To: LD Zhang Cc: discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb? No, there's no way to produce a GRC file from a python file. On Tue, May 14, 2013 at 2:20 PM, LD Zhang ldz10...@gmail.com wrote: Thanks I found it as in gr-filter/examples/python/pfb.py. I also found something in gnuradio-core/src/examples/pfb directory. Have to excuse my ignorance here since I haven't really worked that much with python approach. Have mostly stayed in GRC flow graph and used the generator to get the python code. Once I have the generated python code, then I can do simple edits to improve here and there. So I am not quite used to reading the code as is. My question is: Is there a way to re-display the pfb.py back onto the GRC graphical window? If not, what do I need to do in order to bring it back to GRC? Is what I am trying here making sense at all? Thanks a lot, LD -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Tuesday, May 14, 2013 1:47 PM To: LD Zhang Cc: discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb? Thanks for letting us know the documentation is out of date. You should find filterbank examples in gr-filter/examples. On Tue, May 14, 2013 at 12:28 PM, LD Zhang ldz10...@gmail.com wrote: Hi, I am reading the polyphase filterbank documentation. It points to a directory where examples are contained: gnuradio-examples/python/pfb. In my installation I have the following directories and files: -rw-rw-r-- 1 ldz ldz 4041 Sep 18 2012 README-win32-mingw-short.txt -rw-rw-r-- 1 ldz ldz 10237 Sep 18 2012 README.hacking -rw-rw-r-- 1 ldz ldz 1695 Sep 18 2012 README.building-boost -rw-rw-r-- 1 ldz ldz 4846 Sep 18 2012 README -rw-rw-r-- 1 ldz ldz 35147 Sep 18 2012 COPYING -rw-rw-r-- 1 ldz ldz 9527 Sep 18 2012 CMakeLists.txt -rw-rw-r-- 1 ldz ldz 1155 Sep 18 2012 AUTHORS drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 cmake drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 docs drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gnuradio-core drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 dtools drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-atsc drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-comedi drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-audio drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-digital drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-fft drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-fcd drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-filter drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-noaa drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-howto-write-a-block drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-pager drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-qtgui drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 gr-trellis drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-shd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-utils drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-uhd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-video-sdl drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-vocoder drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 gr-wavelet drwxrwxr-x 4 ldz ldz 4096 Sep 18 2012 gr-wxgui drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gruel drwxrwxr-x 11 ldz ldz 4096 Sep 18 2012 grc drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 volk drwxrwxr-x 27 ldz ldz 4096 Sep 18 2012 build I don't see a gnuradio-examples directory either above or below this level. Other searches in other directories have yielded nothing. Is this a on-line location or a directory in the installation? Thanks, LD ___ 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] where is gnuradio-examples/python/pfb?
I find the example at the online page http://gnuradio.org/doc/doxygen/page_pfb.html very helpful (code at the end of the page). It runs and generates nice plots. Still trying to get used to it. But the code at gr-filter/python/pfb.py does not run. It appears to be a module? How do I run it or use it? Also what does gr-filter/python/qa_pfb_channelizer.py do? Some of this trace to pfb_channelizer_ccf.cc code? What does blks2 relate to this and other examples? Thanks for explaining, LD On Tue, May 14, 2013 at 3:10 PM, Ben Reynwar b...@reynwar.net wrote: Ah, sorry, I misunderstood your question. Yes, the GRC block pfb_channelizer_ccf is equivalent to the block in gr-filter/python/pfb.py, and, in fact, will use this block in the generated python. On Tue, May 14, 2013 at 2:35 PM, LD Zhang ldz10...@gmail.com wrote: Is it equivalent to use the pfb_channelizer_ccf block in the GRC though? Does the GRC approach suffer reduced capability vs. the python approach? LD -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Tuesday, May 14, 2013 2:30 PM To: LD Zhang Cc: discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb? No, there's no way to produce a GRC file from a python file. On Tue, May 14, 2013 at 2:20 PM, LD Zhang ldz10...@gmail.com wrote: Thanks I found it as in gr-filter/examples/python/pfb.py. I also found something in gnuradio-core/src/examples/pfb directory. Have to excuse my ignorance here since I haven't really worked that much with python approach. Have mostly stayed in GRC flow graph and used the generator to get the python code. Once I have the generated python code, then I can do simple edits to improve here and there. So I am not quite used to reading the code as is. My question is: Is there a way to re-display the pfb.py back onto the GRC graphical window? If not, what do I need to do in order to bring it back to GRC? Is what I am trying here making sense at all? Thanks a lot, LD -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Tuesday, May 14, 2013 1:47 PM To: LD Zhang Cc: discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb? Thanks for letting us know the documentation is out of date. You should find filterbank examples in gr-filter/examples. On Tue, May 14, 2013 at 12:28 PM, LD Zhang ldz10...@gmail.com wrote: Hi, I am reading the polyphase filterbank documentation. It points to a directory where examples are contained: gnuradio-examples/python/pfb. In my installation I have the following directories and files: -rw-rw-r-- 1 ldz ldz 4041 Sep 18 2012 README-win32-mingw-short.txt -rw-rw-r-- 1 ldz ldz 10237 Sep 18 2012 README.hacking -rw-rw-r-- 1 ldz ldz 1695 Sep 18 2012 README.building-boost -rw-rw-r-- 1 ldz ldz 4846 Sep 18 2012 README -rw-rw-r-- 1 ldz ldz 35147 Sep 18 2012 COPYING -rw-rw-r-- 1 ldz ldz 9527 Sep 18 2012 CMakeLists.txt -rw-rw-r-- 1 ldz ldz 1155 Sep 18 2012 AUTHORS drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 cmake drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 docs drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gnuradio-core drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 dtools drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-atsc drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-comedi drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-audio drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-digital drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-fft drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-fcd drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-filter drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-noaa drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-howto-write-a-block drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-pager drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-qtgui drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 gr-trellis drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-shd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-utils drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-uhd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-video-sdl drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-vocoder drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 gr-wavelet drwxrwxr-x 4 ldz ldz 4096 Sep 18 2012 gr-wxgui drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gruel drwxrwxr-x 11 ldz ldz 4096 Sep 18 2012 grc drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 volk drwxrwxr-x 27 ldz ldz 4096 Sep 18 2012 build I don't see a gnuradio-examples directory either above or below this level. Other searches in other directories have yielded nothing. Is this a on-line location or a directory in the installation? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing
[Discuss-gnuradio] A question on gnuradio capacity of handling real time data streaming and signal processing with USRP N210 + gnuradio on host linux computer
Dear Group, I have a need to do real time or near real time tracking (most likely phase-lock loop) of multiple narrow-band carriers/tones in a 1MHz band of signal input using USRP N210 and gnuradio running on a reasonable linux host. Say the carriers/tones are embedded in the band from -500 kHz to +500 kHz. If I want to lock on to 20 carriers in that band using gnuradio PLLs, will this choke up the computer? If there is a problem, I also would like to think how to reduce data rates. But I don't know whether multiple LO's are an option. Thanks for reading, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A question on gnuradio capacity of handling real time data streaming and signal processing with USRP N210 + gnuradio on host linux computer
Thanks I will try a simple one and report back. LD From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org [mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of Marcus D. Leech Sent: Monday, May 13, 2013 4:46 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] A question on gnuradio capacity of handling real time data streaming and signal processing with USRP N210 + gnuradio on host linux computer Dear Group, I have a need to do real time or near real time tracking (most likely phase-lock loop) of multiple narrow-band carriers/tones in a 1MHz band of signal input using USRP N210 and gnuradio running on a reasonable linux host. Say the carriers/tones are embedded in the band from -500 kHz to +500 kHz. If I want to lock on to 20 carriers in that band using gnuradio PLLs, will this choke up the computer? If there is a problem, I also would like to think how to reduce data rates. But I don't know whether multiple LO's are an option. Thanks for reading, LD The best thing to do is to put together a simulation, and see if your computer is up to the task or not. Something that we don't have a really good handle on in Gnu Radio is some estimates for the computational complexity of individual blocks in a flow graph. If we did, one could do some simple arithmetic: add up all the complexities of all the blocks on your fast path (by this I mean blocks that must necessarily operate at the input sample rate) multiply that by the sample rate That gives you an idea of the numbers of MFLOPS/GFLOPS required to support your application. -- 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] A question on gnuradio capacity of handling real time data streaming and signal processing with USRP N210 + gnuradio on host linux computer
I am still learning from on line examples on how to do this in the gnuradio flow graph for testing out the ideas. There seems to be two kinds of approaches to deal with the potential problem of data stream processing choke up: 1. Use a filterbank with many outputs. But for each output use a digital downconversion (DDC) block so that the data rates can go way down. Do say 5 streams at a time. Use throttle, or delay (if there is any), or skip head block to delay the processing the rest of the streams (besides the 5). 2. Still use the same filterbank but with no DDC. Phase lock on the first 5 carriers and delay/throttle/skip the rest. When done with the first 5, record the phase and terminate execution. Then move on the rest, so on and so forth. I would like to check if these ideas sound correct. Also since I am a beginner in GRC, I am curious to hear for a seasoned developer which of the two above looks easier to do. Thanks, LD From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org [mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of Marcus D. Leech Sent: Monday, May 13, 2013 4:46 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] A question on gnuradio capacity of handling real time data streaming and signal processing with USRP N210 + gnuradio on host linux computer Dear Group, I have a need to do real time or near real time tracking (most likely phase-lock loop) of multiple narrow-band carriers/tones in a 1MHz band of signal input using USRP N210 and gnuradio running on a reasonable linux host. Say the carriers/tones are embedded in the band from -500 kHz to +500 kHz. If I want to lock on to 20 carriers in that band using gnuradio PLLs, will this choke up the computer? If there is a problem, I also would like to think how to reduce data rates. But I don't know whether multiple LO's are an option. Thanks for reading, LD The best thing to do is to put together a simulation, and see if your computer is up to the task or not. Something that we don't have a really good handle on in Gnu Radio is some estimates for the computational complexity of individual blocks in a flow graph. If we did, one could do some simple arithmetic: add up all the complexities of all the blocks on your fast path (by this I mean blocks that must necessarily operate at the input sample rate) multiply that by the sample rate That gives you an idea of the numbers of MFLOPS/GFLOPS required to support your application. -- 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
[Discuss-gnuradio] A Question on Polyphase Channelizer - PFB block
Hi, I am experimenting with a way to do multi-channel filtering of a wideband signal to put out multiple narrower bands. The PFB block appears to be the one that can do it. There is very little documentation on it. Online documents indicate this as version gnuradio 3.6.4 C++ API. I am running gnuradio 3.6.2. Am I OK running 3.6.2? Do I have to upgrade to 3.6.4? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2?
Dear Community, I have a question: I want to run multiple (as many as possible) PLLs that track the phase of multiple carriers in my band using the USRP N210. How many can I have running in real time simultaneously? If I use the phase from these loops, are there unknown (gotcha) phase offsets between/among them? Thanks for reading, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2?
Thanks for your prompt answer. I have a 1MHz band of signals from which I would like to extract say 30 carriers. Is it possible to set up say 30 PLLs in the flow graph and each will extract its own phase (and locked frequency), and there are no additional phase offsets between/among the different PLLs? What I mean by phase offsets is that the different PLLs preserve the original phase relationships in the original 1MHz band of data stream. Is it difficult or easy? Thanks much, LD From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org [mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of Marcus D. Leech Sent: Wednesday, May 08, 2013 3:27 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2? Dear Community, I have a question: I want to run multiple (as many as possible) PLLs that track the phase of multiple carriers in my band using the USRP N210. How many can I have running in real time simultaneously? If I use the phase from these loops, are there unknown (gotcha) phase offsets between/among them? Thanks for reading, LD Could you clarify your question? Do you mean software PLLs in a Gnu Radio flow-graph? As many as you want until your computer runs out of steam. -- 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] How many multiple/simultaneous PLLs can I have running on USRP2?
I guess there may be an issue that since different PLLs will lock up at different time, so there are unknown amount of initial phase offsets for each PLLs. Would love to know if there are any ways around that. LD From: LD Zhang [mailto:ldz10...@gmail.com] Sent: Wednesday, May 08, 2013 3:32 PM To: 'Marcus D. Leech'; 'discuss-gnuradio@gnu.org' Subject: RE: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2? Thanks for your prompt answer. I have a 1MHz band of signals from which I would like to extract say 30 carriers. Is it possible to set up say 30 PLLs in the flow graph and each will extract its own phase (and locked frequency), and there are no additional phase offsets between/among the different PLLs? What I mean by phase offsets is that the different PLLs preserve the original phase relationships in the original 1MHz band of data stream. Is it difficult or easy? Thanks much, LD From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org [mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of Marcus D. Leech Sent: Wednesday, May 08, 2013 3:27 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2? Dear Community, I have a question: I want to run multiple (as many as possible) PLLs that track the phase of multiple carriers in my band using the USRP N210. How many can I have running in real time simultaneously? If I use the phase from these loops, are there unknown (gotcha) phase offsets between/among them? Thanks for reading, LD Could you clarify your question? Do you mean software PLLs in a Gnu Radio flow-graph? As many as you want until your computer runs out of steam. -- 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] How many multiple/simultaneous PLLs can I have running on USRP2?
So maybe the PLL is not a good solution between it will have an unknown amount of initial phase offsets by the time it locks. Since the relative phase between different carriers is the essential information sought after, maybe the better way is to construct very narrowband filters. Now very narrowband can mean a lot of taps, hence a lot of resources consumed. Here is where I don't know the limitation of resources. If I want to set up a filter of say 4 Hz bandwidth for a signal at 1MHz, and if you have a lot of these signals at different frequencies, what would be the best way to extract these? Maybe the way to go is to have the LO at 1MHz, so the many signals being looked at are +/- many hundreds of kHz. How many taps would it require to extract a signal at say 300 kHz with the 4Hz bandwidth? Can the USRP do 200 taps for each of the 30 carriers (I am just asking without exact calculation here)? Thanks, LD From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Wednesday, May 08, 2013 3:39 PM To: LD Zhang Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2? I guess there may be an issue that since different PLLs will lock up at different time, so there are unknown amount of initial phase offsets for each PLLs. Would love to know if there are any ways around that. LD Well, presumably, you'd be using a PFB filterbank or something to create the multiple streams, and then use PLL demodulators to extract bits from those. The PFB filterbank should have uniform group delay across all streams, as far as I know. -- 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] How many multiple/simultaneous PLLs can I have running on USRP2?
Or am I wrong that the resource is in the computer and not in the USRP? LD From: LD Zhang [mailto:ldz10...@gmail.com] Sent: Wednesday, May 08, 2013 3:51 PM To: 'Marcus D. Leech' Cc: 'discuss-gnuradio@gnu.org' Subject: RE: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2? So maybe the PLL is not a good solution between it will have an unknown amount of initial phase offsets by the time it locks. Since the relative phase between different carriers is the essential information sought after, maybe the better way is to construct very narrowband filters. Now very narrowband can mean a lot of taps, hence a lot of resources consumed. Here is where I don't know the limitation of resources. If I want to set up a filter of say 4 Hz bandwidth for a signal at 1MHz, and if you have a lot of these signals at different frequencies, what would be the best way to extract these? Maybe the way to go is to have the LO at 1MHz, so the many signals being looked at are +/- many hundreds of kHz. How many taps would it require to extract a signal at say 300 kHz with the 4Hz bandwidth? Can the USRP do 200 taps for each of the 30 carriers (I am just asking without exact calculation here)? Thanks, LD From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Wednesday, May 08, 2013 3:39 PM To: LD Zhang Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2? I guess there may be an issue that since different PLLs will lock up at different time, so there are unknown amount of initial phase offsets for each PLLs. Would love to know if there are any ways around that. LD Well, presumably, you'd be using a PFB filterbank or something to create the multiple streams, and then use PLL demodulators to extract bits from those. The PFB filterbank should have uniform group delay across all streams, as far as I know. -- 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] How many multiple/simultaneous PLLs can I have running on USRP2?
Sorry for the confusion. I have been using USRP in a rather micky-mouse way. For the longest time, I was just capturing data on host computer disk and do brute force processing in MATLAB. It's time for me to think about speed up. And the first thing is to consider the USRP processing capability. The PLL may still be the right solution if the PLL faithfully replicates the original signal, which I think it should. But having the gnu-radio doing the PLL, I am not sure there is much of a speed gain. Maybe there are intelligent ways of organizing this so that it can be sped up? Maybe the Gnuradio is faster than Matlab. But these days the matlab has been awful fast, not much slower than C. Still my matlab is not organized as nicely as the gnuradio. Right now I don't have any streamlined processing. The suggestion on using the PFB filterbanks and PLLs in parallel and streaming operation may have significant speed up? Your opinion is appreciated. LD From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Wednesday, May 08, 2013 4:03 PM To: LD Zhang; Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How many multiple/simultaneous PLLs can I have running on USRP2? Or am I wrong that the resource is in the computer and not in the USRP? LD It's all in the computer, unless you do an FPGA-based implementation. Gnu Radio blocks run on the host machine, not the USRP hardware. I admit to being a little bit surprised that you don't know that already, given how long you've been posting things to this list, and using USRP hardware. -- 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
[Discuss-gnuradio] How to ensure 2 USRP to have the same internal FPGA configuration when measuring the same signal?
Hi Folks, I have managed to use 2 different USRP N210's to measure the same signal with the same sampling rate (both center at 0 Hz DC) at approximately the same time (timing is an issue but irrelevant for this discussion). Examination of signal intensity does confirm the above to be true. However, when I compare individual tones between the 2 units, I see the phase differences between the tones jump around a lot. And they seem to cluster at +90/-90 locations. This is very puzzling and troublesome. I guess internally the USRP configures the FPGA in a way that is not visible. Is there a way that I con force the 2 USRP to configure the FPGA in the same identical configuration when taking data? Thanks for your inputs and help. LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
Hi Folks, Sorry for trying to resurrect this topic thought to be settled at one time. My earlier impression was somehow incorrect. Let me summarize the situation: basically one wants to gather data at approximately the same time for 2 USRPs. Using the 2 host computers sync'd to NTP, this appears to be feasible in principle. If they differ by 1 or 2 ms, I don't care and it's within tolerance of the particular application. So the quickest thing to do was to modify the top_block.py generated from GRC as follows: self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time())) self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(time.time() + 0.5)) which basically set the USRP to system time and schedule the data gather start at 0.5 seconds away from the current time. A first test appeared to OK, roughly. But subsequent test shows that the start gather time differ between the 2 units by quite a bit, maybe 20-100 ms, or so. So looks like this approach does not work (So it looks Marcus was right when he said that one has to some dancing around to make sure it works, though I am curious what that dancing around is.). At this point, there appears to be 2 other approaches: 1. drop the GRC approach and try to use the rx_samples_to_file command. The order of command I see would be as: first: do an equivalent set_time_now command, although I am still searching for the exact syntax. second: according to what I read from an earlier topic, it seems that one has to make sure both the rx_samples_to_file.cpp and the rx_timed_samples.cpp need to be set a time_spec at the part of the code where the stream_cmd_t is set up. It appears that the rx_timed_samples.cpp is already set up correctly but not rx_samples_to_file.cpp? If so, how do I change the rx_samples_to_file.cpp? Also, once I am done changing, how do I rebuild the code suite? third: I suppose one do a rx_samples_to_file command with the right options - time in the future, etc. But this does seem to be doing the same thing as I was doing before. I don't see how this approach fixes the problem. Please provide suggestions for solving this problem. 2. A safer bet might be to try to get the timestamps of the data. This would require modifying the code that contains the metadata structure, which I currently don't know how to do. Also I have a question: suppose the code is modified correctly and metadata structure is properly retained. How can this metadata be saved either into a separate file or together with the captured sample streams in the same file? Maybe there are other approaches, I am still on a path that avoids using the PPS. Your help is appreciated. Thanks, LD On Mon, Jan 7, 2013 at 3:14 PM, Marcus D. Leech mle...@ripnet.com wrote: On 01/07/2013 04:46 PM, LD Zhang wrote: Thanks to Josh and Marcus for their comments. The set_time_now command works! After I put it in, the earlier observed 0.5 sec offset between the 2 USRP became ~0.1 second. So there is still work to do. I guess my options are: 1. Make the set_start_time command to work. My question is how I can make it work in python. I hand edited the set_time_now command to embed in the initialization part of the top_block.py code generated from GRC (which has worked). Do I just hand edit the set_start_time just following that command? Now the problem is that after set_time_now, the USRP time is sync'd to the system time. But what is the argument I should give to set_start_time? If you're running this on two different computers, and using the local system clock, it'll be hard to make both USRPs really agree on what time it is. Even if the two hosts are synchronized with NTP, you'll have to do a fair bit of dancing about to make sure that they both, more-or-less, do the set_time_now() with the same value, and at the same time. This is why for precision synchronized samples, people use a GPSDO with a 1PPS output (to allow set_time_next_pps() ), and a 10Mhz refclock (so that the clocks on the two-or-more USRPs all step together at the same rate and phase). -- 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-gnuradiohttps://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] How do I capture of the time of USRP N210 samples with host computer system time?
Hi, Please see my comment below: On Wed, Jan 16, 2013 at 2:30 PM, Josh Blum j...@ettus.com wrote: On 01/16/2013 03:37 PM, LD Zhang wrote: Hi Folks, Sorry for trying to resurrect this topic thought to be settled at one time. My earlier impression was somehow incorrect. Let me summarize the situation: basically one wants to gather data at approximately the same time for 2 USRPs. Using the 2 host computers sync'd to NTP, this appears to be feasible in principle. If they differ by 1 or 2 ms, I don't care and it's within tolerance of the particular application. So the quickest thing to do was to modify the top_block.py generated from GRC as follows: self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time())) self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(time.time() + 0.5)) How are you communicating the same start time to each device in your setup? Suppose there were two devices, would it not be more like this: self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time())) self.uhd_usrp_source_1.set_time_now(uhd.time_spec_t(time.time())) #start stream time common for all N devices start_time = uhd.time_spec_t(time.time() + 0.5) self.uhd_usrp_source_0.set_start_time(start_time) self.uhd_usrp_source_1.set_start_time(start_time) -josh The 2 USRP is each connected to a different computer. Each computer is sync'd in time via NTP update. Since NTP time is accurate to ~ 1ms, I consider the 2 computers sync'd right after the NTP update. There is network communication (socket signal) between the 2 computer so that they note their system time immediately after the socket signal and schedule (round forward to a future integer 10 second point) to perform the same action (data gathering) at the same time in the future. That is, each schedule an amount of time and each watch its clock, when it gets to that scheduled point, it immediately launches the top_block.py script in which the same set_time_now and set_start_time command are performed. There is no _0 and _1 distinction because each is operating independently. I am still scratching my head on what happens inside the USRP in grabbing the first sample in a continuous data stream. Maybe the better solution here is to grab the metadata structure which gives the timestamp of the first sample? Since I have never messed with USRP cpp code before, I want to be careful in what I am doing. I would like to find out what cpp file to modify, how to modify it, and how to rebuild afterwards. Thanks very much, LD ___ 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] How do I capture of the time of USRP N210 samples with host computer system time?
Hi, Please see my response below: How are you communicating the same start time to each device in your setup? Suppose there were two devices, would it not be more like this: self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time())) self.uhd_usrp_source_1.set_time_now(uhd.time_spec_t(time.time())) #start stream time common for all N devices start_time = uhd.time_spec_t(time.time() + 0.5) self.uhd_usrp_source_0.set_start_time(start_time) self.uhd_usrp_source_1.set_start_time(start_time) -josh The 2 USRP is each connected to a different computer. Each computer is sync'd in time via NTP update. Since NTP time is accurate to ~ 1ms, I consider the 2 computers sync'd right after the NTP update. There is network communication (socket signal) between the 2 computer so that they note their system time immediately after the socket signal and schedule (round forward to a future integer 10 second point) to perform the same action (data gathering) at the same time in the future. That is, each schedule an amount of time and each watch its clock, when it gets to that scheduled point, it immediately launches the top_block.py script in which the same set_time_now and set_start_time command are performed. There is no _0 and _1 distinction because each is operating independently. I am The code snippet was just supposed to help demonstrate. You need to share the *same* start time for both flow graphs for this to work. The fact that you are using different start times and scheduling the execution of the flow graph and creation of device objects is introducing all this extra variability. -josh My understanding is that the approximately *same* start time is enforced at the 2 computer that have just been sync'd to NTP, because the top_block.py is executed at the approximately (~ 1 ms accuracy) the same time. And inside top_block.py the same code is applied to the 2 units. So I would expect approximately the same start time is used. Maybe not. Maybe the better way to do this is to get away from the top_block.py script and start using the rx_samples_to_file command, and get the metadata structure info and correct for the difference in the metadata timestamp. My question is what are the files to modify and how I save the metadata, whether in a separate file or in the same file as the sampled data. Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
Hi, This is a very useful input and it may very well explain the situation (some one has also suggested that NTP is not the right protocol for 1-2 ms accuracy. This is a separate problem from what we are discussing here) and the variability. There has been a growing dissatisfaction with the GRC generated python approach and I would like to move to the rx_sample_to_file command approach and start modifying the associated cpp files. Would you say that the performance will be more stable with the latter approach? However, I don't how to do the command line method. I suppose there would be many arguments given to the rx_sample_to_file command to make it do what I want. But the help menu info on this command is very limited, does not touch on needs with set_time_now and set_start_time parameters in the data gathering process. Basically I suppose if I can do the rx_sample_to_file command and correctly impose the set_time_now and set_start_time option, there should be much less variability than the python approach. Does this look right? Thanks, LD There's a profoundly-variable and jittery amount of time that it takes to start a Python interpreter and get things going between any two serial invocations on the *same machine*, let alone on two different machines. They may well agree on what time it is (to a first order approximations) when they both say go, but after that, I can easily imagine the behaviour to be not entirely deterministic. -- 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] How do I capture of the time of USRP N210 samples with host computer system time?
Hi, Please see my comments below: -Original Message- From: Josh Blum [mailto:j...@joshknows.com] On Behalf Of Josh Blum Sent: Wednesday, January 16, 2013 5:19 PM To: LD Zhang Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time? By executing the flowgraphs at the same time, instead of actually using the same time, you adding the variability of how long it takes to open python, construct blocks, and construct the usrp object (which is quite long). better way to do this is to get away from the top_block.py script and start using the rx_samples_to_file command, and get the metadata structure info and correct for the difference in the metadata timestamp. My question is what are the files to modify and how I save the metadata, whether in a separate file or in the same file as the sampled data. The rx_samples_to_file example does not write out the metadata to file. But it can be modified. But don't you think its harder to do it this way? have two unaligned streams, process the start time, remove some samples for the offset in time. When you could just have two streams at the same time? -josh By now I think all parties agree that going thru python adds a lot of variability to the approach. However, if the two flowgraphs can be made to USE THE SAME TIME, the variability should be gone. Right now the problem is that the following identical set of commands are executed at 2 different computers (both sync'd to NTP but at different site): 1. self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time())) 2. self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(time.time() + 0.5)) I believe the basic uncertainty is that the time of executing set_time_now is somewhat uncertain within 2 totally independent computer's python script, even though the time of executing the python script is well behaved. If I understand Josh correctly, he is suggesting to actually use the same time. I understand this to be doing something between command 1 and 2 above. They then become: 1. self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time())) 1.a - figure out what time it is now, say use: time_now = ???command??? 1.b - round forward to schedule at a future common time: suppose time_now = xxx54.6 seconds, time_future =round((time_now+10)/10)*10 = xxx60.0 seconds. 2. self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(time_future)) Does this look right? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
Thanks to Josh and Marcus for their comments. The set_time_now command works! After I put it in, the earlier observed 0.5 sec offset between the 2 USRP became ~0.1 second. So there is still work to do. I guess my options are: 1. Make the set_start_time command to work. My question is how I can make it work in python. I hand edited the set_time_now command to embed in the initialization part of the top_block.py code generated from GRC (which has worked). Do I just hand edit the set_start_time just following that command? Now the problem is that after set_time_now, the USRP time is sync'd to the system time. But what is the argument I should give to set_start_time? 2. The other option is to get the metadata out for the samples collected. From what I read, it looks like one cannot do it in GRC, but have to edit the cpp source code. Is there an example somewhere of how this is done? Thanks very much, LD -Original Message- From: LD Zhang [mailto:ldz10...@gmail.com] Sent: Friday, January 04, 2013 5:38 PM To: 'Marcus D. Leech'; 'Discuss-gnuradio@gnu.org' Subject: RE: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time? Great! Thanks. I tried to import time and it works. Now I just have to see if this is sufficient for my sample gather timing or I still have to get the timestamp of the first sample using metadata and such. LD -Original Message- From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Friday, January 04, 2013 4:15 PM To: LD Zhang; Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time? On 01/04/2013 07:03 PM, LD Zhang wrote: Hello, I tried the following command in python: python: usrp_source.set_time_now(uhd.time_spec_t(time.time()) It doesn't seem to work. Looks like the time.time() is wrong? Looked up an earlier example: set_time_now(uhd::time_spec_t(0.0), 0) The syntax looks different. But this may be doing something different from my intention which is to sync the USRP time to the host system time. I am still searching for the right syntax for this command. Any help is appreciated. LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You'll have to put an: import time In your python -- 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] How do I capture of the time of USRP N210 samples with host computer system time?
When I used set_start_time(uhd.time_spec(time.time() + 0.5))) for both USRP units (after set_time_now), this seems to have worked. At least by visual examination the 2 units are taking data at approximately the same time. Yeah, yeah, yeah, I know, this is never exactly accurate and one need to do PPS for accurate and robust operation for long stretch of time. But actually for this phase of development we are making a point intentionally not to use the PPS reference and relying on the USRP clock over shorter stretch of time. I know that because of this we also have to do ntp sync for the 2 host computers for the USRPs more frequently which makes the code a little uglier. In the long run, we will adopt the use of a PPS. Thanks, LD -Original Message- From: Josh Blum [mailto:j...@joshknows.com] On Behalf Of Josh Blum Sent: Monday, January 07, 2013 3:09 PM To: Discuss-gnuradio@gnu.org Cc: LD Zhang Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time? On 01/07/2013 04:46 PM, LD Zhang wrote: Thanks to Josh and Marcus for their comments. The set_time_now command works! After I put it in, the earlier observed 0.5 sec offset between the 2 USRP became ~0.1 second. So there is still work to do. I guess my options are: 1. Make the set_start_time command to work. My question is how I can make it work in python. I hand edited the set_time_now command to embed in the initialization part of the top_block.py code generated from GRC (which has worked). Do I just hand edit the set_start_time just following that command? Now the problem is that after set_time_now, the USRP time is sync'd to the system time. But what is the argument I should give to set_start_time? Just a time in the near future that you can reasonably schedule in advance of starting the flow graph. Like: uhd.time_spec(time.time() + 0.5)) 2. The other option is to get the metadata out for the samples collected. From what I read, it looks like one cannot do it in GRC, but have to edit the cpp source code. Is there an example somewhere of how this is done? you can write a custom block in c++ or python to deal with tags The most complete guide is here, but it requires installing grextras. I think you can do this w/ more recent native gnuradio, but there isnt a guide yet https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide#wiki-stre am-tags -josh Thanks very much, LD -Original Message- From: LD Zhang [mailto:ldz10...@gmail.com] Sent: Friday, January 04, 2013 5:38 PM To: 'Marcus D. Leech'; 'Discuss-gnuradio@gnu.org' Subject: RE: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time? Great! Thanks. I tried to import time and it works. Now I just have to see if this is sufficient for my sample gather timing or I still have to get the timestamp of the first sample using metadata and such. LD -Original Message- From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Friday, January 04, 2013 4:15 PM To: LD Zhang; Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time? On 01/04/2013 07:03 PM, LD Zhang wrote: Hello, I tried the following command in python: python: usrp_source.set_time_now(uhd.time_spec_t(time.time()) It doesn't seem to work. Looks like the time.time() is wrong? Looked up an earlier example: set_time_now(uhd::time_spec_t(0.0), 0) The syntax looks different. But this may be doing something different from my intention which is to sync the USRP time to the host system time. I am still searching for the right syntax for this command. Any help is appreciated. LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You'll have to put an: import time In your python -- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
Great! Thanks Josh for the answers to my last email. Please see my comments and questions below. If you want to use the PC clock, I recommend calling set time now with the current PC time before scheduling streaming. This will make the USRP tick counter roughly match the PC clock. python: usrp_source.set_time_now(uhd.time_spec_t(time.time()) c++ usrp_source-set_time_now(uhd::time_spec_t(secs, micros, long(1e6)); This way, your only time-ambiguity is the variance in ethernet control packets and the difference in time between the different PCs. That should satisfy referenced to PC's time anyway... I will try it in Python to set the USRP time. My generated top_block.py is doing as: self.uhd_usrp_source_0.set_... I suppose I will just do: self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time()) There is however a question of how often one needs to set the USRP time. It would depend on how fast the USRP clock drifts with respect to host computer system time. I remember a number of 2 ppm accuracy of the TCXO frequency reference. How does this translate to rate of clock drift (in say micro-seconds drift per hour)? -- The next step would be to schedule when a stream begins for each device so they send RX samples to the host at the same time (according to the USRP anyway). I think the USRP source block supports setting the time, and streaming at a specific time, but there isnt a way to do this at the GRC level. So you might need some hand coded python added to the generated flowgraph, if you are using GRC. OK, I want to do this. But what is the command to do in python? Something like: self.uhd_usrp_source_0.rx_sample_time??? Or .schedule_time??? I do need to pass the sample gather start time as a variable to the top_block.py script. How do I do that (I am a matlaber who is still clumsy with python)? Thanks and Regards, LD ___ 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] How do I capture of the time of USRP N210 samples with host computer system time?
Hi Josh, Thanks for replying. I have some thoughts on using the set_start_time. Please see my comments and questions below: = There is a set_start_time() call. setting this will effect what time the streaming begins when the flow graph starts Once the set_time_now command is performed. I consider the USRP have the same (or approximately the same) time as the host computer, correct? The set_start_time() call looks nice, but it requires a time passed to it. I currently don't know how to dynamically call the set_start_time() command with a variable of system time in hour:min:sec.microsecond format. I found a discussion a while ago on some problems with the set_start_time. Someone was complaining that the time-out window in the cpp code is too short so a future scheduled time did not work. Thinking about what I need to achieve, the set_start_time command is certainly good to make to work. But maybe I have an easier task here. Since the time is already sync'd, and presuming that I can get the time tag of the first sample, it is OK if the start time is off a bit(as long as it doesn't jump around by more than 0.1 seconds each time I perform the same function), all I need is to know the time of the start sample referenced to the host system time. So I say all I need right now is to get the time tag of the beginning sample and that would suffice, just to make it easier. Also, as an alternative, there is access to the issue_stream_cmd(). You can leave the flow graph running and issue commands to turn streaming on and off, schedule bursts, etc... I will try to make the previous approach to work before I mess with this one. LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
You pass it a uhd.time_spec. SInce you are using the PC's time, there is already something you may find convenient: uhd.time_spec.get_system_time() Can you do this in python script that I have, or how you do this in python? If not in python, then the easier thing for me to do may still be trying to get the time of captured start sample of the data. Please advise. Thanks, For your reference, I am pasting the python code I have: class top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self, test_1) ## # Variables ## self.samp_rate = samp_rate = 1000 ## # Blocks ## self.uhd_usrp_source_0 = uhd.usrp_source( device_addr=, stream_args=uhd.stream_args( cpu_format=fc32, channels=range(1), ), ) self.uhd_usrp_source_0.set_subdev_spec(A:B, 0) self.uhd_usrp_source_0.set_samp_rate(samp_rate) self.uhd_usrp_source_0.set_center_freq(0, 0) self.uhd_usrp_source_0.set_gain(0, 0) self.gr_skiphead_0 = gr.skiphead(gr.sizeof_gr_complex*1, 10240) self.gr_head_0 = gr.head(gr.sizeof_gr_complex*1, 1000) self.gr_file_sink_0 = gr.file_sink(gr.sizeof_gr_complex*1, sample_sink.dat) self.gr_file_sink_0.set_unbuffered(True) ## # Connections ## self.connect((self.gr_head_0, 0), (self.gr_file_sink_0, 0)) self.connect((self.uhd_usrp_source_0, 0), (self.gr_skiphead_0, 0)) self.connect((self.gr_skiphead_0, 0), (self.gr_head_0, 0)) def get_samp_rate(self): return self.samp_rate def set_samp_rate(self, samp_rate): self.samp_rate = samp_rate self.uhd_usrp_source_0.set_samp_rate(self.samp_rate) if __name__ == '__main__': parser = OptionParser(option_class=eng_option, usage=%prog: [options]) (options, args) = parser.parse_args() tb = top_block() tb.run() ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
Great! Thanks. I tried to import time and it works. Now I just have to see if this is sufficient for my sample gather timing or I still have to get the timestamp of the first sample using metadata and such. LD -Original Message- From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Friday, January 04, 2013 4:15 PM To: LD Zhang; Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time? On 01/04/2013 07:03 PM, LD Zhang wrote: Hello, I tried the following command in python: python: usrp_source.set_time_now(uhd.time_spec_t(time.time()) It doesn't seem to work. Looks like the time.time() is wrong? Looked up an earlier example: set_time_now(uhd::time_spec_t(0.0), 0) The syntax looks different. But this may be doing something different from my intention which is to sync the USRP time to the host system time. I am still searching for the right syntax for this command. Any help is appreciated. LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You'll have to put an: import time In your python -- 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
[Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
Hi Folks, We are testing 2 USRP N210 units with data gathering (using GRC source and file sink). The command from the host to the N210 is sent at the approximately simultaneous time (referenced to system NTP time). However, the samples gathered from the 2 units appear to differ by as much as 0.4-0.5 seconds! The intention is to gather data at the 2 units at approximately the same time as the pre-programmed system time commands. The gathering is done with the top_block.py code generated from GRC. What happens inside the USRP appears to be beyond my control here. So the natural thing to do here is to time-stamp the samples with host computer system time. I hope that we don't have to use an external reference for the USRP. Isn't there an internal USRP clock that is continuously counting. If we can get the USRP clock counts to tie together the samples counts and the host computer system time, we would be in good shape. Is this a good idea? Your thoughts and help are appreciated. LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?
Hello, Thanks for the note below. I am reading an older email exchange between Josh Blum and a guest. Josh mentioned that there is a downstream block (in GRC I guess) that can use the timestamp tag to decide which samples are to be stored. Also there appears to be metadata utility to use. Maybe these magic functions such as stream tags (or) and get_time_last_pps to get the job done. So far I have used none of these utilities. My goal here is trying to avoid using the PPS if possible. Since the data gathering is done infrequently, I tend to think that the PPS can be avoided. I am trying not to use the PPS at least for this phase of the development. Yes for the next phase with enhanced capabilities, the external reference need will resurrect again. But it is better not to use the PPS right now, unless I am wrong here and need re-education of the USRP. The mimo cable is not an option since the 2 units are not co-located. So is it possible to do the downstream block and metadata stream tags in GRC (currently using UHD source block and file sink block)? Thanks very much, LD From: John Malsbury [mailto:john.malsb...@ettus.com] Sent: Thursday, January 03, 2013 11:24 PM To: LD Zhang Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time? You can get the synchronize two USRPs with an external reference or a USRP MIMO https://www.ettus.com/product/details/MIMO-CBL cable, and specifying the time to start streaming for both. -John On Thu, Jan 3, 2013 at 11:18 PM, LD Zhang ldz10...@gmail.com wrote: Hi Folks, We are testing 2 USRP N210 units with data gathering (using GRC source and file sink). The command from the host to the N210 is sent at the approximately simultaneous time (referenced to system NTP time). However, the samples gathered from the 2 units appear to differ by as much as 0.4-0.5 seconds! The intention is to gather data at the 2 units at approximately the same time as the pre-programmed system time commands. The gathering is done with the top_block.py code generated from GRC. What happens inside the USRP appears to be beyond my control here. So the natural thing to do here is to time-stamp the samples with host computer system time. I hope that we don't have to use an external reference for the USRP. Isn't there an internal USRP clock that is continuously counting. If we can get the USRP clock counts to tie together the samples counts and the host computer system time, we would be in good shape. Is this a good idea? Your thoughts and help are appreciated. LD Zhang ___ 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] Why do I have a sampling rate limit of 33.333 Msps?
Hi Nick, Thanks for your helpful comments. I have followed up on this train of thought on specifying a frequency for the USRP. I guess the advantage is one can achieve the same level of over-sampling with lower sampling rate with this technique when one shifts closer to the frequency of interest. I gave it a try in the USRP and have the following observations: 1. The spectrum center essentially shifts to the specified frequency. No band pass filtering seems to be applied at all. My only concern is that this lack of band pass filtering may hinder dynamic range in certain cases but not a problem for now. 2. I have kind of a logistic question. I am running the GRC file which directs the output to a file sink. Since I am doing different parameter studies of the system performance, I need to generate different files with different operating parameters. I don't know how to automatically dump parameters like samp rate, samp duration, center freq, BW, gain, etc., to the recorded file so that analysis can be somewhat automated. Maybe this is a question that should be asked under a different subject heading. Thanks, LD On Tue, Oct 2, 2012 at 4:32 PM, Nick Foster n...@ettus.com wrote: On Tue, Oct 2, 2012 at 4:25 PM, LD Zhang ldz10...@gmail.com wrote: I would like to explore the system performance from 10 to 100 Msps at an interval of 10 MHz. I know that 20 Msps is probably sufficient. But it would be good to survey the performance at different rates. Since my interest is not the entire band but multiple signal at discrete frequencies, one possibility is that one sample at say up to 100 MHz internal to the USRP, but then pass the signal through a set of filter banks, and then digital down convert so that signals can be much lower frequencies. Then decimation is truly an option without losing SNR. The end product is a lower rate data set which is OK for Ethernet transport. Is this a good approach? Is there anything wrong in this thinking? Or is this too difficult for the USRP? Is there a better approach? Suggestions are appreciated. That's a great idea. It's also what the N210 is doing internally. The ADC samples at a fixed 100Msps, and a digital downconverter followed by a decimator (including filtering) selects a portion of that spectrum for transport over the Ethernet bus. When you ask the N210 for a sample rate, it decimates and filters appropriately for that sample rate. When using LFRX, the frequency you pick in UHD is the digital downconverter frequency. N210 has two independent DSP chains, so if you like, you can get two parallel streams from LFRX, operating at different sample rates and different DDC frequencies. --n LD On Tue, Oct 2, 2012 at 4:10 PM, Nick Foster n...@ettus.com wrote: How fast do you need to sample? How many samples do you need? --n On Tue, Oct 2, 2012 at 4:00 PM, LD Zhang ldz10...@gmail.com wrote: Is there a way to get around this limit? I suppose you have to have on-board memory to hold data temporarily. Unfortunately the N210 isn't like the E100 which has the memory? LD On Tue, Oct 2, 2012 at 3:50 PM, Nick Foster n...@ettus.com wrote: The N210 samples at a fixed rate of 100Msps. However, the gigabit Ethernet transport limits the instantaneous bandwidth over the transport to 25Msps in 16 bit sampling mode, or 50Msps in 8 bit sampling mode. --n On Tue, Oct 2, 2012 at 3:47 PM, LD Zhang ldz10...@gmail.com wrote: Hello, I expect my N210 to have a sampling rate up to 100 Msps. Instead I do not seem to go above 33. MHz. Why? I don't see why the LFRX board should be a limitation. Thanks, LD Zhang ___ 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] Why do I have a sampling rate limit of 33.333 Msps?
Hello, I expect my N210 to have a sampling rate up to 100 Msps. Instead I do not seem to go above 33. MHz. Why? I don't see why the LFRX board should be a limitation. Thanks, LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why do I have a sampling rate limit of 33.333 Msps?
Is there a way to get around this limit? I suppose you have to have on-board memory to hold data temporarily. Unfortunately the N210 isn't like the E100 which has the memory? LD On Tue, Oct 2, 2012 at 3:50 PM, Nick Foster n...@ettus.com wrote: The N210 samples at a fixed rate of 100Msps. However, the gigabit Ethernet transport limits the instantaneous bandwidth over the transport to 25Msps in 16 bit sampling mode, or 50Msps in 8 bit sampling mode. --n On Tue, Oct 2, 2012 at 3:47 PM, LD Zhang ldz10...@gmail.com wrote: Hello, I expect my N210 to have a sampling rate up to 100 Msps. Instead I do not seem to go above 33. MHz. Why? I don't see why the LFRX board should be a limitation. Thanks, LD Zhang ___ 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] A Question on WX GUI FFT Sink
I tried to find in the QT GUI Widgets category an item that does FFT. But don't find one. I wonder what is meant by the QT GUI FFT display? Thanks, LD On Fri, Sep 28, 2012 at 3:39 PM, Josh Blum j...@ettus.com wrote: On 09/28/2012 02:15 PM, LD Zhang wrote: Hello, I have a simple GRC demo where the USRP source goes to a WX GUI FFT sink and WX GUI Scope sink. They appear to be a good tools for sanity checks. One feature I don't find however but I think should be quite necessary is when one needs to examine a portion of the FFT spectrum more closely. But I don't find an option where one can specify the start and stop frequency for the FFT spectrum display. Am I missing something? WX FFT sink cant do this. But... FWIW, the QT gui FFT display sink does have a zoom feature. -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] A Question on WX GUI FFT Sink
Well I should have been more patient before I sent out the last email. It turns out for the functionality I want (flexible zoom in display of the fft spectrum) the block is called simply QT GUI sink, if I am not mistaken. When I tried, there is the error message: --- Traceback (most recent call last): File /home/ldz/usrp_tests/top_block.py, line 75, in module tb = top_block() File /home/ldz/usrp_tests/top_block.py, line 58, in __init__ self.top_layout.addWidget(self._qtgui_sink_x_0_win) File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line 94, in __getattr__ return getattr(self._tb, name) AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout' - I took a look in the top_block.py in my test directory. But I don't understand the problem. I have not yet become accustomed to the python environment. Please off suggestions. Thanks. LD On Fri, Sep 28, 2012 at 3:39 PM, Josh Blum j...@ettus.com wrote: On 09/28/2012 02:15 PM, LD Zhang wrote: Hello, I have a simple GRC demo where the USRP source goes to a WX GUI FFT sink and WX GUI Scope sink. They appear to be a good tools for sanity checks. One feature I don't find however but I think should be quite necessary is when one needs to examine a portion of the FFT spectrum more closely. But I don't find an option where one can specify the start and stop frequency for the FFT spectrum display. Am I missing something? WX FFT sink cant do this. But... FWIW, the QT gui FFT display sink does have a zoom feature. -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] Does USRP ADC have internal noise (out-of-band) dither?
Dear Group, I need to clarify a very basic feature of the USRP ADC. The question is: Does the ADC have internal noise dither when sampling? I looked at the TI ADS62P45 data sheet but did not find explicit mention of the noise dither. On the other hand, if you read those app notes from Analog Device Walt Kester, the noise dither is such a prominent feature that it is almost essential to have it in the A-to-D process. From the spectrum I gathered so far, I cannot tell. I would think TI should be good on this basic point. Could someone clarify? Many Thanks, LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A Question on WX GUI FFT Sink
Hello, I have a simple GRC demo where the USRP source goes to a WX GUI FFT sink and WX GUI Scope sink. They appear to be a good tools for sanity checks. One feature I don't find however but I think should be quite necessary is when one needs to examine a portion of the FFT spectrum more closely. But I don't find an option where one can specify the start and stop frequency for the FFT spectrum display. Am I missing something? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to capture the Rx data using uhd_rx_cfile and agree with the uhd_fft Scope mode data
I looked and ran the attached GRC file. It does work. I have a question on whether the slider gain is applied before or after the ADC? LD On Fri, Sep 28, 2012 at 3:28 PM, Josh Blum j...@ettus.com wrote: On 09/27/2012 02:42 PM, LD Zhang wrote: Yes. I can understand the LFRX does not have any adjustable gain. But what comes out of the USRP source should be samples already digitized. Surely there is gain to be adjusted before the ADC. According what I see, it is from 0 to 6dB (in voltage?). I don't see how this can be inserted into the USRP source block. You are correct. The N210 has a 6db digital gain. Attached is a GRC flowgraph that loopsback TX and RX with Basic daguhterboards. You can see the digital gain slider in action. The gain parameter in the GRC block is a amalgamation of ADC and RF frontend gain elements. The API also allows for individual control, but this level of control is not available in the GRC gain parameter. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Control the file size from the file sink output
Dear GRC'ers I am just starting to play with GRC. One thing I am playing with is the file sink. It appears there is no way to control the file size from its output. This can be dangerous but the continuous sampling at high rate can quickly fill up the disk and cause possible disasters. I am surprised to find that there is no hook in the file sink block for file/sample size limitation. I would like to see what the community suggests for dealing with this problem. Another way might be to turn on the running of the project code for a certain number of seconds and shuts off. Maybe there is a block that can do that. I have not been able to find one yet. Any suggestions are welcome. Thanks, LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to capture the Rx data using uhd_rx_cfile and agree with the uhd_fft Scope mode data
Yes. I can understand the LFRX does not have any adjustable gain. But what comes out of the USRP source should be samples already digitized. Surely there is gain to be adjusted before the ADC. According what I see, it is from 0 to 6dB (in voltage?). I don't see how this can be inserted into the USRP source block. Also I have some related questions: 1. the float numbers out of the USRP source block appear to be in volts. There is no indication of what units it is in. 2. Is there any way of specifying bandpass filters before the ADC? This would probably be independent of the LFRX, but something on the motherboard before the ADC? I do see an option in the USRP block that seem to do this. However this bandpass may be after the ADC? Thanks, LD On Wed, Sep 26, 2012 at 11:55 AM, Josh Blum j...@ettus.com wrote: On 09/26/2012 01:36 AM, LD Zhang wrote: Hi, I did try and made a GRC example of using a USRP Source and a fft sink, scope sink, and a file sink to test out the idea. When looking at the scope sink, the data is about +/- 2x10^-4. I changed the gain of the USRP source block to 20 dB. But nothing happened to the signal amplitude. How is this possible? You mentioned LFRX? There are no configurable gain elements for the LFRX daughterboard. If this helps, the various gain ranges are listed for various daughterboard frontends here: http://files.ettus.com/uhd_docs/manual/html/dboards.html#basic-rx-and-lfrx -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to capture the Rx data using uhd_rx_cfile and agree with the uhd_fft Scope mode data
Hello community, I am trying to use the uhd_rx_cfile command to capture some rx samples in the hope of recovering what I see as streaming samples in the uhd_fft Scope mode display. Since I am really new to GR+USRP, I have a couple of difficulties: 1. The uhd_rx_cfile command help menu does not provide a BW option 2. When using the uhd_rx_cfile command and specifying a frequency, it seems to record a sinusoid, again possibly a bw issue. However, I am not quite sure whether I am looking at the same signal port input. I intend to look at LFRX daughter board port B input. 3. I have not been able to reproduce what I saw in the uhd_fft Scope mode streaming data. Without any gain, I am seeing streaming data at a level of +/- 200 units, which may be reasonable noise. How do I capture the same data into a file. Since my difficulty with uhd_rx_cfile command, hence this question. I have also experimented with the rx_samples_to_file command with worse experience. I could go directly to GRC GUI directly and try to learn to do everything there. But I think there is value in being able to do this simple thing from the command line. Your help and suggestions are appreciated. LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to capture the Rx data using uhd_rx_cfile and agree with the uhd_fft Scope mode data
Hi, I did try and made a GRC example of using a USRP Source and a fft sink, scope sink, and a file sink to test out the idea. When looking at the scope sink, the data is about +/- 2x10^-4. I changed the gain of the USRP source block to 20 dB. But nothing happened to the signal amplitude. How is this possible? Please see the attached GRC if you want to see what I am doing. Thanks. LD I could go directly to GRC GUI directly and try to learn to do everything there. But I think there is value in being able to do this simple thing from the command line. Your help and suggestions are appreciated. I will second this motion. All of the hooks are available in the USRP source block, most of which can be changed at runtime with a simple variable widget. Its nice to change setting at runtime to see the effect. Also, you can easily attach a file sink and a scope sink and an fft sink. That way you know that you have captured to file the same thing you are observing. Also, be careful with the format of the file data. Its a binary array of std::complexfloat, not float, not double, etc... -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio test_fft_scope_file_sinks.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Why is my USRP N210 front panel LED E light blinking rapidly all the time?
Hello, As a new user I have just made the uhd_fft.py to display something. I use the LFRX daughter board for initial testing. I have a concern with the front panel LED E light. While the uhd_fft.py is working, both the LED C and E lights are on solidly which is expected. When shutting off the uhd_fft.py, the two lights went off also. But the LED E light starts to first slowly blink and then to pick up speed in blinking. The E light being the ref lock, I am guessing the rx board doesn't like not having a ref? It got really annoying watching the fast blinking light. I fear that this might not be good for the overall health of the system. The only to cure this seem to be power cycle, which is not preferred. What should I do to prevent this or to ensure that everything is working correctly and there is no system complaints? Thanks, LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] N210 FPGA image not compatible with the host uhd code build?
Hello community, There seems to be software compatibility issue between the host (ubuntu 12.04) uhd build and USRP N210 FPGA image. The Runtime errors are captured as: -- $ uhd_usrp_probe linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-224-gc2e197c0 -- Opening a USRP2/N-Series device... Error: RuntimeError: Please update the firmware and FPGA images for your device. See the application notes for USRP2/N-Series for instructions. Expected FPGA compatibility number 10, but got 9: The FPGA build is not compatible with the host code build. Please run: sudo /usr/local/share/uhd/utils/uhd_images_downloader.py /usr/local/share/uhd/utils/usrp_n2xx_net_burner.py \ --fpga=/usr/local/share/uhd/images/usrp_n210_r4_fpga.bin \ --fw=/usr/local/share/uhd/images/usrp_n210_fw.bin \ --addr=192.168.10.2 So I did perform the above command shown in the output message. After downloading the image, the system claims that the FPGA write image was successful. But when I tried the uhd_usrp_probe command again, it still has the same error message, as if the updating did nothing to change the situation. I did notice that when downloading the image, it was from: Downloading images from: http://files.ettus.com/binaries/master_images/archive/uhd-images_003.004.003-205-g4896bf78.zip But the message from the probe command returns the uhd image version as follows: $ uhd_usrp_probe linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-224-gc2e197c0 Is it possible that the downloaded fpga images is outdated, and a correct version that matches the label 224 would work? Where is the correct FPGA image to download? Thanks, LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] N210 FPGA image not compatible with the host uhd code build?
Yes it was my fault. Power cycle did the trick. LD Hmm, not sure. Make sure you are 1) There are two commands there. The downloader and the burner. Make sure both are executed. 2) You will need to power cycle the USRP after the burn If that is failing, let me know but... it looks like you have installed the master branch. So the compatible images can be manually grabbed from here: http://files.ettus.com/binaries/master_images/ -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] build and install UHD+GNUradio on Ubuntu
Hello, I am really new to USRP and just starting to install the GnuRadio. From the ettus website it says the easiest way to compile UHD +GNUradio is using the build-gnuradio script. I tried running it, but the very first thing (line 46 or 47) it starts to complain is on the syntax. Here is an excerpt towards the part of the error below: ... ... mod_udev- add UDEV rule for USRP1 mod_sysctl - modify SYSCTL for larger net buffers build-gnuradio: 46: build-gnuradio: Syntax error: } unexpected I did not change anything in the script. What am I doing wrong? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
