Re: [Discuss-gnuradio] Max Output Power from the LFTX
Hi Khalid, I had a similar issue with an LFTX that I had been working with for about two years. I actually had two boards running on separate USRP2's and both were working fine for quite a while, but I recently noticed that one had a drastically lower output range. I ended up replacing the LFTX and all is working well now, so I'm assuming it was a hardware issue that came up at some point. I didn't take the time to look for the problem, but I figured I'd share this info since what you're seeing might be a hardware issue rather than something you can resolve with settings. -Mike On Tue, Jan 6, 2015 at 12:59 PM, khalid.el-darymli khalid.el-dary...@mun.ca wrote: Output power is determined largely by baseband signal magnitude in that case. Yes, I understand. And I noticed that for baseband signal with an amplitude * 1, * the pass-band signal gets clipped off. So I assume that an amplitude of 1 for the baseband signal should deliver the maximum output power (for the pass-band signal). My question was, what is the maximum power one can get for the pass-band signal output from LFTX? In your earlier reply, you said it is around +7dBm, am I getting this right? In my case, for a baseband amplitude of around 1, I am only getting *-28.13dBm*, much less than what you said, I am not sure,* why?* Thanks, Khalid On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech mle...@ripnet.com wrote: Thanks Marcus for your reply. Probably somewhere in the neighborhood of +7dBm, maybe a little more. The LF/BASIC series have *no* gain in either path, so you're just looked at buffered ADC ouput. So, ~ *+7dBm* is the max output power I supposed to get from the LFTX daughterboard? How do I get that? Since I am only getting -28.13 dBm, does that mean I have some issue with my LFTX daughterboard? Khalid Output power is determined largely by baseband signal magnitude in that case. Message: 2 Date: Tue, 6 Jan 2015 10:13:45 -0330 From: khalid.el-darymli khalid.el-dary...@mun.ca To: Discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Max Output Power from the LFTX daughterboard Message-ID: CACdmG=zCHATiwrtv=wBVLwG0_ 5GQr0y=wksequrcajrtuv5...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hi, What is the maximum output power from the LFTX daughterboard when used with the USRP N200? According to this datasheet [1], the N200 with the WBX daughterbaord provide an output power of 15 dBm. However, when using the LFTX daughterboard, I am getting a much less output power. [1] http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf In GNU Radio with the USRP N200, we use a sinusoid with a frequency of 150 kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a center frequency of 5 MHz. When the output of LFTX is plugged into a scope terminated with a 50-ohm terminator, the scope reads 24.8 mV (peak-to-peak). This is around -28.13 dBm. Is this the max power one can get out of the LFTX daughterboard? Thanks. Best regards, Khalid -- next part -- An HTML attachment was scrubbed... URL: http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150106/37846ff4/attachment.html -- Message: 3 Date: Tue, 06 Jan 2015 08:48:08 -0500 From: Marcus D. Leech mle...@ripnet.com To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Max Output Power from the LFTX daughterboard Message-ID: 54abe798.5060...@ripnet.com Content-Type: text/plain; charset=UTF-8; format=flowed On 01/06/2015 08:43 AM, khalid.el-darymli wrote: Hi, What is the maximum output power from the LFTX daughterboard when used with the USRP N200? According to this datasheet [1], the N200 with the WBX daughterbaord provide an output power of 15 dBm. However, when using the LFTX daughterboard, I am getting a much less output power. [1] http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf In GNU Radio with the USRP N200, we use a sinusoid with a frequency of 150 kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a center frequency of 5 MHz. When the output of LFTX is plugged into a scope terminated with a 50-ohm terminator, the scope reads 24.8 mV (peak-to-peak). This is around -28.13 dBm. Is this the max power one can get out of the LFTX daughterboard? Thanks. Best regards, Khalid Probably somewhere in the neighborhood of +7dBm, maybe a little more. The LF/BASIC series have *no* gain in either path, so you're just looked at buffered ADC ouput. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ Discuss-gnuradio mailing list
Re: [Discuss-gnuradio] QT GUI Segmentation Fault
Just a follow up on this - I was able to resolve the issue with the following modifications in the volk_config file: before: volk_32fc_32f_multiply_32fc a_avx generic changed to: volk_32fc_32f_multiply_32fc generic generic before: volk_32fc_deinterleave_64f_x2 a_avx u_avx changed to: volk_32fc_deinterleave_64f_x2 generic u_avx While I'm happy to have it working again, I don't exactly know what this modification actually does. If anyone with knowledge of the volk library can give me a quick bit of info about what these modifications are actually doing and / or why this would resolve the segfault issue, it would ease my mind a bit. Thanks, -Mike On Thu, Oct 30, 2014 at 11:13 AM, Michael Rahaim mrah...@bu.edu wrote: Hi all, I recently installed GNURadio on two laptops (installation via PYBOMBs) and everything has been running fine for a few weeks; but I'm suddenly running into issues with QT GUI on one of the laptops. I wasn't sure what the issue was originally, but after narrowing it down I'm able to see the problem with a simple flow graph: signal source - throttle - QT GUI Sink Starting with a blank slate in GRC and building the flow graph works fine on one device; but the same flow graph on the second laptop opens and closes immediately with return code -11. If I run the python code outside of GRC, I get the segmentation fault. I was looking for a solution and I came across bug 645 ( http://gnuradio.org/redmine/issues/645) that was resolved in 3.7.3, but these laptops have 3.7.6 (git-133-gd814810) installed. I noticed that the bug report mentions the avx volk kernel as the issue and both of my machines indicate that they're using volk machine avx_64_mmx. I also ran volk_profile and changed volk_32fc_32f_multiply_32fc a_avx generic to volk_32fc_32f_multiply_32fc generic generic as indicated in the bug report, but I still see the problem. To be honest, I don't really know how the volk library works and I'm not sure what else I should try changing. If anybody has suggestions, it would be greatly appreciated. Thanks in advance, -Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QT GUI Segmentation Fault
Hi all, I recently installed GNURadio on two laptops (installation via PYBOMBs) and everything has been running fine for a few weeks; but I'm suddenly running into issues with QT GUI on one of the laptops. I wasn't sure what the issue was originally, but after narrowing it down I'm able to see the problem with a simple flow graph: signal source - throttle - QT GUI Sink Starting with a blank slate in GRC and building the flow graph works fine on one device; but the same flow graph on the second laptop opens and closes immediately with return code -11. If I run the python code outside of GRC, I get the segmentation fault. I was looking for a solution and I came across bug 645 ( http://gnuradio.org/redmine/issues/645) that was resolved in 3.7.3, but these laptops have 3.7.6 (git-133-gd814810) installed. I noticed that the bug report mentions the avx volk kernel as the issue and both of my machines indicate that they're using volk machine avx_64_mmx. I also ran volk_profile and changed volk_32fc_32f_multiply_32fc a_avx generic to volk_32fc_32f_multiply_32fc generic generic as indicated in the bug report, but I still see the problem. To be honest, I don't really know how the volk library works and I'm not sure what else I should try changing. If anybody has suggestions, it would be greatly appreciated. Thanks in advance, -Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT GUI Segmentation Fault
Hi Johnathan, Thanks for the reply. I'm using Ubuntu 14.04 on a Dell XPS laptop with 8 cores. Results of the grep call are below: model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz I noticed that there are 12 other uses of a_avx in volk_config. Is it likely that using any of the kernels with a_avx will cause a similar issue? -Mike On Fri, Oct 31, 2014 at 2:19 PM, Johnathan Corgan johnat...@corganlabs.com wrote: On 10/30/2014 02:07 PM, Michael Rahaim wrote: While I'm happy to have it working again, I don't exactly know what this modification actually does. If anyone with knowledge of the volk library can give me a quick bit of info about what these modifications are actually doing and / or why this would resolve the segfault issue, it would ease my mind a bit. What you did was instruct VOLK to use a non-SIMD implementation of these two functions. It appears that for whatever reason the AVX versions of those kernels are having problems when running on your specific CPU. Can you give us the information from running: $ grep 'model name' /proc/cpuinfo What OS and version are you using? Are you running in a virtualized environment like VMware or KVM? -- Johnathan Corgan, Corgan Labs SDR/DSP Training and Consulting Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT GUI Segmentation Fault
Hi Nathan, Thanks for the info. In case you didn't see my previous reply, the processors are all Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz -Mike On Fri, Oct 31, 2014 at 3:32 PM, West, Nathan n...@ostatemail.okstate.edu wrote: On Thu, Oct 30, 2014 at 4:07 PM, Michael Rahaim mrah...@bu.edu wrote: Just a follow up on this - I was able to resolve the issue with the following modifications in the volk_config file: before: volk_32fc_32f_multiply_32fc a_avx generic changed to: volk_32fc_32f_multiply_32fc generic generic before: volk_32fc_deinterleave_64f_x2 a_avx u_avx changed to: volk_32fc_deinterleave_64f_x2 generic u_avx While I'm happy to have it working again, I don't exactly know what this modification actually does. If anyone with knowledge of the volk library can give me a quick bit of info about what these modifications are actually doing and / or why this would resolve the segfault issue, it would ease my mind a bit. Thanks, -Mike Hi Mike, So each VOLK kernel has several internal implementations that are architecture specific (SSE, AVX, NEON, etc). A call to the VOLK library looks like volk_32fc_32f_multiply_32fc(output_buffer, input_buffer0, input_buffer1, number_of_points). Internally VOLK has a dispatcher that uses the implementation that is best for your machine. The best implementation is determined by running volk_profile which runs all of the implementations available and write the fastest one to volk_config. At run-time VOLK reads this file to know which version of each kernel to actually run. Can you tell me your processor model name and flags? A copy of /proc/cpuinfo (just one of the processors) would be useful. Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio in Python Tutorial - installing python block without C++
Hi Martin, Thanks for the response. I'll make sure to work with the newer version going forward. I see that the tutorial home page says 3.7.4 is required, but I just checked the guided tutorial in python ( http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python) and it mentions 3.7.0 or later as a prereq. Thanks again, -Mike On Wed, Oct 22, 2014 at 5:40 AM, Martin Braun martin.br...@ettus.com wrote: Michael, we do point out in our tutorials that you require GNU Radio 3.7.4 or later to run these tutorials. The possibility of writing Python-only OOTs is the main reason for this. However, you *probably* don't need to upgrade if you don't like. One way to do this is to clone gr-tutorial, and remove all the source files, then start adding them again as you go through the exercises. Cheers, M On 10/21/2014 05:53 PM, Michael Rahaim wrote: Hi all, I've been going through the tutorials with a fresh install of GNURadio (Version 3.7.2.1) through Ubuntu's package manager (Ubuntu 14.04) and I've run into a few issues when attempting to install a python block (without any C++, as indicated in the tutorial: http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python#Installing-Python-Blocks ). I think I resolved the first issue below, but any pointers for resolving the second error would be greatly appreciated: 1-) Running cmake threw an error CMAKE error: cannot determine link language for target gnuradio-tutorial -As mentioned in the bug report #522, I was able to eliminate the error by removing the lib folder and commenting out the line add_subdirectory(lib) from CMakeLists.txt 2-) Running make now gives the error when attempting to link the tutorial module: Linking CXX shared module _tutorial_swig.so /usr/bin/ld: cannot find -lgnuradio-tutorial collect2: error: ld returned 1 exit status -Is there something else that needs to be edited before running cmake since there isn't any C++ code? Thanks in advance, -Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio in Python Tutorial - installing python block without C++
Hi all, I've been going through the tutorials with a fresh install of GNURadio (Version 3.7.2.1) through Ubuntu's package manager (Ubuntu 14.04) and I've run into a few issues when attempting to install a python block (without any C++, as indicated in the tutorial: http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python#Installing-Python-Blocks). I think I resolved the first issue below, but any pointers for resolving the second error would be greatly appreciated: 1-) Running cmake threw an error CMAKE error: cannot determine link language for target gnuradio-tutorial -As mentioned in the bug report #522, I was able to eliminate the error by removing the lib folder and commenting out the line add_subdirectory(lib) from CMakeLists.txt 2-) Running make now gives the error when attempting to link the tutorial module: Linking CXX shared module _tutorial_swig.so /usr/bin/ld: cannot find -lgnuradio-tutorial collect2: error: ld returned 1 exit status -Is there something else that needs to be edited before running cmake since there isn't any C++ code? Thanks in advance, -Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QT GUI frequency plot scale
Hi all, I'm going through some of the GNU Radio tutorials and I noticed that the frequency axis for the QT GUI frequency sink is incorrect for real valued signals (e.g., sample rate of 10k shows -2.5k to 2.5k). I found a bug report (#541) from last year with the issue resolved in 3.7.0, but I'm working with version 3.7.2.1. I didn't notice any other bug reports regarding this issue. Note: The frequency plot in QT GUI sink is scaled correctly. Also, updating the sampling rate while the flow graph is running corrects the scale. Regards, Mike Rahaim PhD Candidate Boston University, Boston, MA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio / Software Radio conceptual question
Thanks for the quick replies. I can see how putting the SDR in a block directly before the DAC or after the ADC is a PHY implementation, and how this is the case when using embedded devices such as the E series USRPs and the embedded SDR components in a base station. My confusion is when gnuradio is operating in an OS where the sole purpose isn’t the comms link (i.e., running on my PC rather than on an embedded linux micro). In the case of the N series USRPs, my understanding is that the signal chain wraps whatever is implemented in gnuradio (PHY, MAC, etc) within network and Ethernet packets to send to the USRP, the USRP unwraps this and places the samples on the physical channel and vice versa at the receiver. To me, the wrapping and passing of digital samples seems to put a stack within the stack. The ends of the chain are unaware of the internal message passing and act as if the samples were directly passed to the DAC and ADC, which is why I see it as an emulation of the PHY. Perhaps this is strictly a case of my definitions being incorrect (and I definitely realize that network layer models are models rather than standards), but please confirm if my sense of what is occurring in the signal chain is correct. Thanks again, -Mike On Tue, Jun 17, 2014 at 5:31 AM, Martin Braun martin.br...@ettus.com wrote: On 17.06.2014 04:24, Michael Rahaim wrote: I have a relatively high level question regarding gnuradio and software radio in general. Is it a fair generalization to say that gnuradio is operating at the application layer and is essentially emulating a physical layer implementation (or the implementation of other lower layer protocols)? For example, if I have a link between two USRPs (more specifically, N series USRPs), the digitally sampled received data comes in on the ethernet NIC and moves up the stack to the software radio application. The signal processing that would typically be done in lower layers is then handled by the application. In most cases, GNU Radio handles pretty much what comes out of the A/D converter (well, not quite, there's some decimation and filtering in there. But for the sake of this argument, this is irrelevant). So, we have this: ADC - GNU Radio - DAC To say GNU Radio operates at application layer would therefore be not good description of what it does; it doesn't emulate a PHY, it *is* the PHY for all intents and purposes. This is the software radio principle: Using A/D converters, we bring the software very close to the antenna. This is not an academic view on things. While most wireless devices (and I guess that means mobile phones) are what you could call hardware radio, i.e. they have dedicated circuits to do the PHY, many other applications such as base stations are actually driven by software. So when you say data moves up the stack, it's not going up the stack in terms of ISO/OSI layers. The means of getting the sample data (which is the raw signal, even before the PHY layer) to the software are just slightly more elaborate than having the PHY chip connected directly to the ADC. GNU Radio was specifically designed to implement PHYs, it can also implement MACs. Above that, you would probably use something else. The second part of my question is, given a flow graph in gnuradio, what sort of steps would be necessary to push it back down the stack or implement in a chipset such that it can be used as an interface in a typical network stack? Is this something that anyone using gnuradio has considered or should I assume the next step would involve re-implementation? I'm not sure what you're trying to do here. Maybe what you're trying to do is what Balint and John have done with their gr-mac module, which allows you to create a TCP/IP connection over your own user-defined PHY? NOTE: This is by no means for a commercial product, but rather for demonstration. My research has led me to use gnuradio for some proof of concept implementations and I'm curious how much additional effort would be required to port the work to a practical device - for example, implementation on a smart phone. (you can read this as will it cause me to postpone graduation a few weeks? months? years?) GNU Radio works on some embedded devices, which might be what you're interested in. If you have no experience in embedded development, it can take you months to years to figure out, but if you're a smart guy you might be able to get some results sooner than that. Note that I'm not talking about smartphones here, but rather commercially available embedded SDR devices, such as the Ettus E100. Martin ___ 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] GNU Radio / Software Radio conceptual question
Hi all, I have a relatively high level question regarding gnuradio and software radio in general. Is it a fair generalization to say that gnuradio is operating at the application layer and is essentially emulating a physical layer implementation (or the implementation of other lower layer protocols)? For example, if I have a link between two USRPs (more specifically, N series USRPs), the digitally sampled received data comes in on the ethernet NIC and moves up the stack to the software radio application. The signal processing that would typically be done in lower layers is then handled by the application. The second part of my question is, given a flow graph in gnuradio, what sort of steps would be necessary to push it back down the stack or implement in a chipset such that it can be used as an interface in a typical network stack? Is this something that anyone using gnuradio has considered or should I assume the next step would involve re-implementation? NOTE: This is by no means for a commercial product, but rather for demonstration. My research has led me to use gnuradio for some proof of concept implementations and I'm curious how much additional effort would be required to port the work to a practical device - for example, implementation on a smart phone. (you can read this as will it cause me to postpone graduation a few weeks? months? years?) Thanks in advance - any input is greatly appreciated. Regards, Michael Rahaim PhD Candidate Boston University, Boston, MA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
