Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?
On Mon, Nov 29, 2010 at 5:59 PM, Vladutzzz stoianovici_v...@yahoo.com wrote: What would be the best way to work with a 32 MHz band resulting from USRP2? I guess, since the minimum decimation rate is 4 (resulting in a 25 MHz signal band), some kind of interpolation will be required or maybe resampling?! Any ideas on how to proceed? Thanks in advance! Vlad. I'm not entirely sure what you meant by interpolating or resampling, but in case you were talking about what I think you were talking about, that's not going to work. Sure, you can come in at 25 Msps and resample to 32 Msps, but you won't be getting any more information out of the signal by doing that. You'll still only have the information in the original 25 MHz bandwidth, just now sampled at a higher rate (which doesn't make any difference or, frankly, any sense). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?
I am interested in this 2 USRPs approach since I don't have the experience and the knowledge to start messing about inside the FPGA firmware code and have an extra USRP2. How would this go? I tried looking up some info about this topic but currently gnuradio.com seems to be down. I've read some bits and pieces on a few forums. Most of the info is about having one USRP2 module as a transmitter and the other as a receiver. I want them both to be receivers(actually half a receiver) and to complete each other by receiving half of the 32 MHz band (so each would receive 16 MHz). How would the USRPs be connected to the same computer? How will the two 16 MHz bands be attached together to form the 32 MHz one (some kind of 2:1 multiplexing - I'm just guessing here)? I am aware of the great load exerted upon the system resources, but I'm trying to make this work anyway. Thanks. Vlad. Marcus D. Leech wrote: On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote: You could use 2 USRPs and chop it down the middle? Reconstruct on the computer? Yup, although see my previous comments about host-side resources required for such wide bandwidths. -- Marcus Leech 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 -- View this message in context: http://old.nabble.com/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sample rate vs. symbol time issue E100 Flexible Clocking (more info please)
On 11/29/2010 01:00 PM, bob beckwith wrote: I'm currently confronted with a sample rate vs. symbol time issue. I noticed that the E100 announcement mentioned a flexible clocking feature to deal with exactly this type of thing. I've been looking on the Ettus site for more information, but haven't been able to locate any. Is there any more info to be had here? Unfortunately, we have not really documented this yet. There are a lot of possibilities, so I will attempt to explain them here. There are 2 different modes. We'll call them VCO mode and VCXO mode. You select which mode you are using with 2 jumpers on the board. In both modes you can lock either to an external reference or to the onboard 10 MHz TCXO (which has about 1-2 ppm accuracy). The external reference can be just about any frequency you like, but is typically 10 MHz. In both modes, the maximum master clock rate is 64 MHz. In VCXO mode, the master clock comes from an on-board VCXO (voltage-controlled crystal oscillator). In this mode the master clock frequency for the system is equal to the frequency of the VCXO (or an integer division thereof). The E100 comes with a 61.44 MHz VCXO (a good frequency for UMTS), but you can replace it with another frequency easily since the footprint is an industry standard 5x7 VCXO package. In VCO mode, the master clock comes from the VCO inside the AD9522-4 clock generator chip. Without getting into too much detail, this allows you to get a master clock of just about any frequency you would like below 64 MHz. The limitation is that some frequency choices will have better phase noise than others. In general, frequencies that are a multiple of 250 kHz will have very good phase noise. For others you'll have to do the math to figure out if there are good factors you can use. If you have questions about specific frequencies I can tell you if they will work well. Otherwise you can look at the AD9522-4 data sheet. If you need a frequency which does not work well in VCO mode, your best bet is to use a VCXO at that frequency. For example, 61.44 MHz does not work well in VCO mode, and that is why we supply the 61.44 MHz VCXO. Also, will the N210 incorporate this feature? No, the N210 clocking uses a VCXO at 100 MHz. You can replace that VCXO with some other frequencies, but that involves soldering. We are looking at putting a resampler in the FPGA, but that is some time off. And on a different but related front, sample rate wise it looks like the Crystek CVHD-950-122.880 would be a good candidate for use as a replacement oscillator on the USRP2. Has anyone had any luck with this part? Any timing issues I should be aware of? It looks as though the clock generator chip shouldn't have a problem with it. That VCXO should be fine, but you may have trouble meeting FPGA timing on the USRP2, unless you divide it by 2. It will be a little easier on the N210. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?
On 11/30/2010 07:04 PM, Vladutzzz wrote: I am interested in this 2 USRPs approach since I don't have the experience and the knowledge to start messing about inside the FPGA firmware code and have an extra USRP2. How would this go? I tried looking up some info about this topic. I've read some bits and pieces on a few forums. Most of the info is about having one USRP2 module as a transmitter and the other as a receiver. I want them both to be receivers(actually half a receiver) and to complete each other by receiving half of the 32 MHz band (so each would receive 16 MHz). How would the USRPs be connected to the same computer? (MIMO cable?) How will the two 16 MHz bands be attached together to form the 32 MHz one (some kind of 2:1 multiplexing - I'm just guessing here)? I am aware of the great load exerted upon the system resources, but I'm trying to make this work anyway. Thanks. Vlad. Assuming that you have a big-arsed machine to do this with, here goes: Assumptions o phase-coherence between the two isn't an issue (if you're just doing power measurements, it won't be) o you have a very-studly computer o you have two good 1GiGe interfaces Start out with two single-usrp sources, address them as appropriate for your two USRP2s. 16MHz isn't an available bandwidth out of the USRP2, so use 16.7MHz, and band-limit it to exactly 16MHz with an FIR bandpass filter. Your two USRP2s will each be tuned to a frequency that is 16MHz away from each other. Once you have your two band-limited complex signals, detect them, using a complex-to-mag-squared on each of them. Then put the two signals into an adder, and low-pass filter with a single-pole IIR or FIR low-pass filter. Decimate to taste after filtering. -- Marcus Leech 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
[Discuss-gnuradio] Re:Test-bed application: how to control GUI app and gr_vector_source
Hi Andis Dembovskis: i tried to run your script, but the program stoped and get following error: done_part_1 audio_alsa_sink[hw:0,0]: snd_pcm_hw_params failed: Descriptor de archivo en mal estado Traceback (most recent call last): File programafallido.py, line 56, in module app.tb.start() File /usr/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1455, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self) RuntimeError: check topology failed on audio_alsa_sink(1) using ninputs=1, noutputs=0 do you know how to solve the problem? thanks in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] software-defined GNSS receiver people in Asia
Dear All, I apologize for bugging people on this mailing list for this but I do not know an alternative way. I am looking for people located in Asia doing GNSS stuff with GNU Radio or other SDR softwares and interested in sharing some Asian GNSSs (e.g. QZSS) data or implementation. In return I can provide, if interested, some GALILEO E1/E5 full constellation signal. Regards Fabrizio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Windows Build environment -- Cygwin or MinGW?
I'd like to get started building GNURadio for Windows, using the USRP 1, with the goal of writing some custom blocks. Do people prefer Cygwin or MinGW style installations? Off the cuff, Cygwin looks more straightforward. Any opinions? Thanks in advance Kevin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] python/digital examples and UHD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2010 03:47 PM, Tom Rondeau wrote: Thanks for your reply Tom, Have you used the version 2 digital code, yet (benchmark_tx2, benchmark_rx2, usrp_receive_path2, etc.)? One of the things I did was include better resampling so that you can get any bit rate you want. You still have to go through the process of selecting the USRP's sample rate that's closest to your desired rate, and then the resampling takes care of the rest. Well in fact that's what I was looking at. I called this the 'automagical' frequency selection in my last mail ;-) It appears to me you do this by trying all the tuples of (bitrate, samples_per_symbol,...) and select the one fitting 'best'. So please don't throw stones at me for asking this question, but from my understanding the required desired_samplerate = bitrate x samples_per_symbol / bits_per_symbol (1) What I do with the UHD driver is ask for a sample rate. It will then set its sample rate to whatever the closest rate it can do. You can the read back the actual sample rate of the USRP with get_samp_rate(). I then use this value to determine the difference between my desired sample rate and the actual sample rate, which I then plug into the arbitrary resampler. So what you suggest is basically: 1. set_samp_rate(desired_samplerate) as in (1) 2. tmp = get_samp_rate() 3. and then resample in gnuradio according to tmp / desired_samplerate or did I get something wrong? Please don't get me wrong because I ask a lot of questions :-) I don't ask you guys to do any of my work (like a thesis or the likes). Just in my opinion having the examples working is really important, because that's where new people start to look at when trying to figure out how stuff works. And nothing is more frustrating than not even managing to get the examples running. Best regards and happy hacking, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJM9L5tAAoJEOjnDXL6I0uZtNwP/1JDIggYhvBRw6bJQmQzUjKU mDKrYyqIdFbLDv0+aC62gTn0g+OVpa11yP585pZcF9tZ5A9ZwIqSEpo6iEPXH883 q6+A3GmogTAqtaydf7seG3PkdV/HXZcAkBRtd0QgjMykKbIOG2hlDTJZsv8Ru0Iz /dOa6ERrxHQSrYY1DLW/e5dMrwBp8SMGdIT3RlwpuKvQyZmA9xj8rcqxNyvfHuNf 3KT5AFCQQbKrmGXiwb9z+09rFTHWga4hdLbfkX+L4ANz/j2eUDxomLgSVcx1vOEb 0Qqn1MJu2vBRceIdyiAItl3gnocWZ62EQMnvIcoDY9F7Mi9sBCWVV18CWVwPv2SU P+4o5wRvpV5b7nVn6U0Yi47w0/Wfz5UsYbiGMc/scrpSa0wHuYv7BXsjlOOANrmd RAYz0Xvk6aIq4P4RuuqeIx1AWfw0tLcQaO7BAAvanZqf6qf+HqP+oMmCQZgWzlhL hgDuL/7YdpUN66c8xSXivCfFZpf/FOkoKMhF1N7BQ1EM349BrgbPdL3VO0I/jEs/ f7nsMML7FkhJdOF5IH/1QgEl+fGGMNvEmqBqfm3w/pYtUkwX4KDnc6GrHimYrk72 QnFuv2ZWURnyNsvp7pYnH27Bu7ssyYa6DZP+Iu047Ev7iK0oMuqaQaWxDibSSL4c vMqE5g//R0SsNBcTtiZe =x5g+ -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
