[Discuss-gnuradio] Sinks in GRC
How can I use/import 'ra_stripchartsink' and 'ra_fftsink' in GRC ? They are not available in available sinks in GRC. Regards, Umair Naeem MSc Communication Engineering Chalmers University ot Technology, Sweden. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc
It is for UMTS based standard LTE (20MHz bandwidth) which has 30.72Msps and this is beyond USRP2's instantaneous bandwidth (25MHz). I am simulating LTE (10MHz bandwidth) where I can halve the sampling rate of 15.36Msps. Reading the earlier mail threads and responses from Matt I understand that it is better to handle the sample rate converters at the software level rather than doing at the FPGA level in the USRP2 code. LTE is based on OFDM and is not using any spectral shaping filter, instead the samples generated for OFDM symbols at the above rate are directly read/write into DAC/ADC. I could successfully do the above by performing downlink and uplink using interpolation factor 16 which boils down to 6.25Msps but when I used the interpolation factor 6 (or 8) it gives the overflowing errors. I am using Quadcore PC (2.6GHz), can you suggest any other high end PC that can handle the above processing? Regards Krishna S --- On Fri, 9/4/10, John Orlando j...@epiq-solutions.com wrote: From: John Orlando j...@epiq-solutions.com Subject: Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc To: Johnathan Corgan jcor...@corganenterprises.com Cc: Krishna S krishna2...@yahoo.com, gnu discuss-gnuradio@gnu.org Date: Friday, 9 April, 2010, 4:15 PM snip If what you really mean is that you have a host PC generated sample stream at 15.36 Msps and need to transmit it with the USRP2, then yes, you'd set the USRP2 FPGA interpolation to 6, then fractionally resample from 15.36 Msps to 16 Msps on the host. Depending on what the last DSP processing stage in your application is, you may be able to fold this resampling into the prior stage. For example, if the last step in your signal processing chain is a spectral shaping filter, like a root-raised-cosine filter, then you can reimplement this using a polyphase resampler and use the output filter taps there. This would combine the filter and resampling operation in one block and eliminate the need for a very high CPU resampling block. Where does the figure of 15.36 Msps come from? Just a guess, but that sounds like 4x the UMTS chip rate (which is 3.84 Mchips/sec). If this is the case, there is an RRC filter at the last DSP stage typically, so your suggestion for folding this re-sampling in is spot-on. -- Regards, John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sinks in GRC
On Thu, Apr 15, 2010 at 4:34 AM, Umair Naeem ar...@student.chalmers.se wrote: How can I use/import 'ra_stripchartsink' and 'ra_fftsink' in GRC ? They are not available in available sinks in GRC. If you have a working gnuradio module that you would like to add to GRC you can create an XML file that tells GRC how to use the block. I'm not familiar with the radio astronomy code, but you will have to make sure that the blocks are 'block diagram safe', in that they do not require special callbacks. Read the instructions at this link to get a better idea of what needs to be done: http://gnuradio.org/redmine/wiki/1/GNURadioCompanion#Adding-Custom-Blocks Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A simple analogue question.
If I have two signals entering a receiver, both with a power of 0 dBm, what would be the total input power seen by the receiver? Is it 3 dBm or 6 dBm? Anywhere between 6dBm and -174 + 10*log(measurement bandwidth) dBm, assuming a 50-Ohm system at room temperature. JD 'correlation' B. -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lartmaker.nl/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IQ imbalance...
On 04/11/2010 11:09 PM, Ian Holland wrote: Hi Matt Can you please confirm by input level you are referring to the input to the transceiver daughterboard? I am using the XCVR2450, for over-the-air reception. The input level (to the XCVR2450 at the receiver) would have been roughly: Tx Power (max. 20 dBm as per http://www.ettus.com/downloads/er_ds_transceiver_dbrds_v5b.pdf) + Tx Ant. Gain (3dBi) - Free Space Loss (at least 46dB for 2m separation and 2.4 GHz freq.) + Rx Ant. Gain (14 dBi) As far as I can tell based on the above (presuming the 20 dBm transmit power is based on max. gain setting for the Transmitting XCVR2450), the largest signal I could have at the Rx port after the Rx antenna is: 20 + 3 - 46 + 14 = -9 dBm So, if this is the case, I presume all was safe regardless of the chosen Rx gain setting for the receiving daughterboard. Yes, -9 dBm is safe. Can you please confirm if this would be the case, as I am encountering inconsistent behaviour with my equipment (such as the unrepeatable error mentioned earlier, and occasional fails to lock at 5 GHz without first trying to lock to a much lower frequency). I have not seen the problem locking without trying a lower frequency. What if you try 5 GHz twice in a row? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP FX2 24MHz crystal
On 04/14/2010 05:30 PM, Berndt Josef Wulf wrote: G'day, The FX2 chip has issues and this time I suspect a faulty crystal. I would like to replace it before going any further. The current crystal is a ECSD240E, but I can't find any information on it. Does anyone know the part number for a replacement crystal and a possible source? ECS-240-20-5PXDN and Digikey carries them. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] xcvr2450
On 04/14/2010 03:38 AM, Per Zetterberg wrote: Another question on xcvr2450: In the firmware I can see that the maximum linearity is not switched on. Can I do it ? Does it make sense ? You can experiment with all of those settings, and I would encourage you to do so in order to get the best performance for your application. The settings we have chosen seem to be a good compromise, but there are so many different uses that there is not one optimum set of settings. I think maximum linearity mode may cause slightly more current draw, but that won't be a problem. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio fresh Linux installation and usrp_benchmark_usb.py error
Hello, I've ubuntu 9.10 karmic koala 64bit and the latest gnu radio installed on a hp dv7-1020us and I get the same error that Fabrizio was getting. When I try to run the usrp_benchmark_usb.py I get the can't open usrp error. f...@frsn-nb:/usr/local/share/gnuradio/examples/usrp$ ./usrp_benchmark_usb.py Testing 2MB/sec... usrp_open_interface:usb_set_alt_interface: failed could not set alt intf 0/0: Connection timed out open_nth_cmd_interface: open_cmd_interface failed usrp: failed to load firmware /usr/local/share/usrp/rev2/std.ihx. Traceback (most recent call last): File ./usrp_benchmark_usb.py, line 106, in module main () File ./usrp_benchmark_usb.py, line 96, in main ok = run_test (rate, verbose) File ./usrp_benchmark_usb.py, line 63, in run_test usrp_tx = usrp.sink_s (0, tx_interp) File /usr/local/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py, line 2799, in sink_s return _usrp_swig.sink_s(*args, **kwargs) RuntimeError: can't open usrp If I try lsusrp I get also something similar to Fabrizio: f...@frsn-nb:/usr/local/share/gnuradio/examples/usrp$ lsusrp usrp_open_interface:usb_set_alt_interface: failed could not set alt intf 0/0: Connection timed out open_nth_cmd_interface: open_cmd_interface failed usrp: failed to load firmware /usr/local/share/usrp/rev2/std.ihx. usrp: failed to find usrp[1] usrp: failed to find usrp[2] usrp: failed to find usrp[3] usrp: failed to find usrp[4] usrp: failed to find usrp[5] usrp: failed to find usrp[6] usrp: failed to find usrp[7] I'm in the same group: f...@frsn-nb:/usr/local/share/gnuradio/examples/usrp$ id frsn uid=1000(frsn) gid=1000(frsn) grupos=1000(frsn),4(adm),20(dialout),24(cdrom),46(plugdev),106(lpadmin),121(admin),122(sambashare),1001(usrp) And I've also done the following: f...@frsn-nb:/usr/local/share/gnuradio/examples/usrp$ ls -lR /dev/bus/usb | grep usrp crw-rw 1 root usrp 189, 133 2010-04-15 14:39 006 I'm not using a virtual box, it's pure linux. Can anyone help? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uhd announcement
Hello List, I said that we would release some uhd code on the 15th of April (2010). So here it is... git clone git://ettus.sourcerepo.com/ettus/uhd.git The UHD source tree comes with firmware, fpga, and host code. For those of you who are not familiar. The UHD is the universal hardware driver for Ettus products. The goal of the UHD is to provide a host driver and api for current and future Ettus products. Also, users will be able to use the uhd driver standalone/without gnuradio. Further, a dual license option will be available for those who build against the uhd but cannot release their software products under the GPL. The uhd is in a pre-alpha state. Currently, it works with the usrp2 with the basic daughter boards. I am in the middle of finishing up support for the RFX boards, and then more to come. The host code is known to compile on linux with gcc and windows with msvc. See the host/readme file for requirements and build information. ### With the uhd, the usrp2 can talk over upd/ip, and therefore the usrp2 will have an ip address; this will default to 192.168.10.2. You will need to setup your network interface ip address, subnet mask, and broadcast address accordingly. You will be able to change your usrp2's ip address with the usrp2_burner and usrp2_recovery apps that comes with the uhd. Assuming your network interfaces are setup, run uhd_find_devices to discover all the usrp2 on your host machine. Note: You will need to load new fpga and firmware images onto the sd card. The images can be built from the uhd source tree with the xilinx tools (ise and edk). Pre-built images here, I will try to keep them up-to-date with the master: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/files ### The uhd streaming api allows data streams to be timestamped down to the precision of a clock tick (thanks to the vrt timestamp work). Also, new streaming modes are now possible with the uhd. Users can request continuous streaming (how gnuradio usrp2 works now) or users can request a specific number samples and at specific times. ### For gnuradio support, I have pushed a branch onto my gnuradio repository. Please checkout the uhd branch on git://gnuradio.org/jblum.git The gnuradio uhd branch provides a gr-uhd-source block and a gr-uhd-sink block complete with grc wrappers. The source and sink blocks work very much like the current usrp2 blocks. ### For those of you who have developed custom daughter cards for the usrp, you will not need to maintain a separate branch off of the uhd to support your product. Rather, you will be able to build dynamically-loadable modules compiled against the uhd daughterboard api. ### I welcome testers, contributors, feedback. Let me know if it builds on your system. Thanks! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd announcement
On Thu, Apr 15, 2010 at 5:11 PM, Josh Blum j...@joshknows.com wrote: Hello List, I said that we would release some uhd code on the 15th of April (2010). So here it is... git clone git://ettus.sourcerepo.com/ettus/uhd.git The UHD source tree comes with firmware, fpga, and host code. Very exciting! Thanks Josh! I'm off to build and test. Couple quick questions: * Are you still basing the fpga build around Xilinx 10.1? If so - any plans to move to/test with later versions? * Any ETA on support for the RFX and XCVR2450 boards? Thanks again, Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] switching between signal and reference source
I'm buliding a system that switches the RF input, several times per second, between the actual signal, and a stable reference source. On a USRP2, what kind of latency is there between the antenna input, and data arriving at the head of the signal processing chain? Small errors at the 'edge' of the switching time are acceptable, but I don't want to get into a situation where my *notion* of whether the input is connected to the source or the reference is horribly out of what. Can I use the GPIO stuff to give me better confidence of adequate synchronization between the actual data, and the state of the input? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] switching between signal and reference source
On Thu, Apr 15, 2010 at 16:52, Marcus D. Leech mle...@ripnet.com wrote: Can I use the GPIO stuff to give me better confidence of adequate synchronization between the actual data, and the state of the input? If you are willing to give up an LSB, you can turn on GPIO streaming with enable_gpio_streaming(). Then io_rx[15] will show up in the lsb of I, and io_rx[14] will show up in the lsb of Q. You need to use the usrp2.source_16sc source to get the raw samples, then gr_and_const to separate the digital bit from the rest of the sample. The io bits get stuffed as the samples come out of the DDC, so there is a fixed offset (you'll need to measure it) based on the group delay through the whole analog front-end and FPGA DDC. The delay is decimation dependent, but deterministic. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] switching between signal and reference source
On Thu, Apr 15, 2010 at 16:52, Marcus D. Leech mle...@ripnet.com wrote: If you are willing to give up an LSB, you can turn on GPIO streaming with enable_gpio_streaming(). Then io_rx[15] will show up in the lsb of I, and io_rx[14] will show up in the lsb of Q. You need to use the usrp2.source_16sc source to get the raw samples, then gr_and_const to separate the digital bit from the rest of the sample. The io bits get stuffed as the samples come out of the DDC, so there is a fixed offset (you'll need to measure it) based on the group delay through the whole analog front-end and FPGA DDC. The delay is decimation dependent, but deterministic. Johnathan OK, so Josh, how do you get access to usrp2.source_16sc from GRC? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] IQ imbalance...
Hi Matt Yes, -9 dBm is safe. Glad to know it was all safe re input levels. I have not seen the problem locking without trying a lower frequency. What if you try 5 GHz twice in a row? The problem with the not locking to 5G is very intermittent. A few times when it did occur, I tried your suggestion of trying 5G a second time: 2 out of 3 times, it locked the second time. The other time, it did not, but then trying 2.35G followed by 5G did then work. Regarding the other intermittent issue that appeared as IQ imbalance, I have swapped the USRP2/XCVR2450 pair used for transmit with the receive one, and haven't observed the issue since. It may still occasionally occur for the first pair, but this is a workaround for me. I am still confused as to why it occurred to begin with. Best Regards Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd announcement
Very exciting! Thanks Josh! I'm off to build and test. Couple quick questions: * Are you still basing the fpga build around Xilinx 10.1? If so - any plans to move to/test with later versions? We have no immediate plans because 10.1 is stable and working. Perhaps the next ISE service pack will fix some of the issues we have had (and after I get some more important UHD TODOs out of the way). * Any ETA on support for the RFX and XCVR2450 boards? I would like to get RFX working by the end of this week. I suppose the XCVR can be the next canditate. Unknown ETA... -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Summer Intern for Ettus Research
We are looking for a summer intern to work on GNU Radio and the USRP. Specifically, we need someone with embedded software and Xilinx FPGA experience. If you are interested, please email me off-list with your resume and a brief description of your experience with GNU Radio, USRPs, and FPGAs. Thanks, Matt Ettus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About Decimation and Interpolation
In GRC, i want to use the band pass filter, but i just donnot know there is some ralationship with Decimation and how can i determine how much the decimation is ,and in the USRP sink,how the interpolation ? thanks in advance!___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: re[Discuss-gnuradio] configuring with usrp2 src present
Hi, Replace all xxx.run with xxx.start() and put xxx.wait() followed by xxx.stop() to stop the flowgraph Best Regards, Firas - Original Message From: Andy_Long luckshiw...@yahoo.com.cn To: Discuss-gnuradio@gnu.org Sent: Thu, April 15, 2010 10:50:39 AM Subject: Re: re[Discuss-gnuradio] configuring with usrp2 src present Hello,Johnathan Did I have some misunderstanding about it? I still think the problem is from USRP2 rather than flow graph. For example, I made some tests to change the while loop such as: def main(): t = my_top_block() t.run() print t.c2mag.unmuted(): #show exceed threshold or not time.sleep(3) m = my_top_block() m.run() print m.c2mag.unmuted(): #show exceed threshold or not time.sleep(3) n = my_top_block() n.run() print n.c2mag.unmuted(): #show exceed threshold or not time.sleep(3) As same condition as before, after two correct outputs, the third one start to show the error. Thank you. regards, Andy Johnathan Corgan-2 wrote: On Wed, Apr 14, 2010 at 12:27, Andy_Long ymailto=mailto:luckshiw...@yahoo.com.cn; href=mailto:luckshiw...@yahoo.com.cn;luckshiw...@yahoo.com.cn wrote: I have faced the same problem. I try to received the limited samples from USRP2 by using headblock. It should return a -1 and the flow graph will stop, am I right? The flowgraph will not only stop, but will end its lifetime. Once run() has returned, the flowgraph is no longer usable, or as we like to say, further operations on it are undefined. In general, starting and stopping an individual flowgraph should occur at the same level of processing as application startup and shutdown. Anything else is usually a sign of incorrect design (though not always.) The run() method on a top block is really just a convenient way of telling GNU Radio your application has nothing else to do until the flowgraph exits. Can you describe what you are trying to do? Johnathan ___ Discuss-gnuradio mailing list href=mailto:Discuss-gnuradio@gnu.org;Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/reconfiguring-with-usrp2-src-present-tp27615622p28252256.html Sent from the GnuRadio mailing list archive at href=http://Nabble.com;Nabble.com. ___ Discuss-gnuradio mailing list href=mailto:Discuss-gnuradio@gnu.org;Discuss-gnuradio@gnu.org href=http://lists.gnu.org/mailman/listinfo/discuss-gnuradio; target=_blank http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
