[Discuss-gnuradio] Receiver gain setting of XCVR2450 in UHD code
Hi Josh and List, In the data-sheet of the MAX2829 circuit two receiver gains are specified Receiver Front-End Gain-Control Settings and Receiver Baseband VGA Gain Settings. From the UHD API we only have one gain parameter. I have been searching in the UHD code to find where (and how) the split is done, but I can't find it.. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Receiver gain setting of XCVR2450 in UHD code
Am 20.08.2010 08:45, schrieb Per Zetterberg: Hi Josh and List, In the data-sheet of the MAX2829 circuit two receiver gains are specified Receiver Front-End Gain-Control Settings and Receiver Baseband VGA Gain Settings. From the UHD API we only have one gain parameter. I have been searching in the UHD code to find where (and how) the split is done, but I can't find it.. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Hi, in the old version the gain splitting was done in the firmware @ db_xcvr2450.c . I don't have a UHD version available right now to check if this is the case, too. But it might give you a point where to start. BR Christoph ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get dqpsk2 block?
Somehow managed to install git and get gnuradio source. Now I have a problem with source installation. sudo ./configure says: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gruel gcell gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-gcell gr-msdd6000 gr-audio-alsa gr-audio-jack gr-audio-oss gr-audio-osx gr-audio-portaudio gr-audio-windows gr-atsc gr-comedi gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc These components will not be built. I have no idea why. It will only install config and docs. Did anyone had such problem? Alex -- View this message in context: http://old.nabble.com/how-to-get-dqpsk2-block--tp29448241p29489572.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] how to get dqpsk2 block?
On Aug 20, 2010, at 12:56 AM, Thunder87 wrote: Somehow managed to install git and get gnuradio source. Now I have a problem with source installation. sudo ./configure says: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gruel gcell gnuradio-core [...] These components will not be built. You're probably missing at least one required library, so it's not building any of the important parts of the gnuradio code. Look at the config.log file that was created by running configure, and find the first critical component that it decided not to build (probably gruel, and you'll most likely find it by searching for the word building), then try to figure out why it didn't build it. I think it's ok for gcell to not be built on most systems, but other components like gruel or gnuradio-core are critical. Here's a snippet of my config.log file as an example: [...] configure:21465: checking for byteswap.h configure:21465: result: no configure:21548: result: Component gruel passed configuration checks; building. configure:21590: checking whether host_cpu is powerpc* configure:21599: result: no configure:21606: checking for spu-gcc configure:21634: result: noconfigure:21667: result: Not building component gcell. configure:21937: checking for cblas_sgemm [...] Notice that it decided to build gruel, and not to build gcell, and that it didn't build gcell because it couldn't find the spu-gcc compiler. In your config.log file, it'll say ...result: Not building component gruel., and the lines (lots of them, including dumps of the test programs that failed) are what you'll need to study to determine what's missing. Some of the failures are probably innocuous (like my missing byteswap.h file, I think), and just indicate the sorts of system-specific variances that the configure script is looking for. However, there'll probably be at least one failure to find a critical library or header file, and that'll be your first clue about what else you'll need to look for and install. You will probably need to repeat the process many times before all of the critical components will build. You might also need to pass more arguments to the configure script, if you determine that it's not finding something that you're sure is installed on your system. While you're working your way through finding all of your missing required libraries, it may be helpful to temporarily add flags such as --with-gruel or --with-gnuradio-core to the ./configure invocation to make the script abort immediately after deciding not to build the specified component, rather than continuing on and making a zillion more lines of output for you to sift through. For example, since the critical gruel component isn't building on your system, nothing that comes after it in the configuration script matters until you fix that, and the --with-gruel flag should tell it to give up immediately after deciding not to build gruel. By the way, you should only need to use sudo to run the final make install step. None of the configuration and compilation steps before that should require root privileges. Good luck! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Receiver gain setting of XCVR2450 in UHD code
Controlling gains individually from the api is on my TODO list. :-) Internally, they are all separated, but the set_xx_gain(...) calls into this gain_group object that sets the codec + dboard gains as a whole. See lib/utils/gain_group.cpp Also give uhd_usrp_probe a run to see the various controllable gain elements. -Josh On 08/20/2010 12:26 AM, Christoph Thein wrote: Am 20.08.2010 08:45, schrieb Per Zetterberg: Hi Josh and List, In the data-sheet of the MAX2829 circuit two receiver gains are specified Receiver Front-End Gain-Control Settings and Receiver Baseband VGA Gain Settings. From the UHD API we only have one gain parameter. I have been searching in the UHD code to find where (and how) the split is done, but I can't find it.. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Can USRP2 be used to provide power to the preamplifier?
Hello all, Currently, I have the following hardware setup: Receive Antenna -- Preamplifier -- RF In (USRP2 + DBSRX) I was wondering if I could use USRP2 to supply power (12- 14V) to the preamplifier? If yes, can someone tell me how? Thanks and best regards, Amee ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BURX 26MHz clock
Thanks John, This is how I understood it, but I suppose my real question is (not being a dsp expert), why would you want to do this? I assumed that being a 26MHz clock, this would be ideal for GSM rate signals? Cheers, Dave - Original Message From: John Orlando j...@epiq-solutions.com To: David Evans ldeev...@yahoo.com Cc: GNURadio discuss-gnuradio@gnu.org Sent: Thu, 19 August, 2010 18:39:30 Subject: Re: [Discuss-gnuradio] BURX 26MHz clock On Thu, Aug 19, 2010 at 12:17 PM, David Evans ldeev...@yahoo.com wrote: Hi, Probably a stupid question... By connecting the BURX's 26MHz clock to the USRP2's 100MHz ref. input, as described in the source, does this pull the mainboard clock to 26MHz, or does it just phase lock to it? i.e. if I collect samples with usrp2_rx_cfile, these will all be samples at 26MHz? On the USRP2, there isn't any way to provide an external clock source (at least not a straight-forward way...you can always unsolder the 100 MHz oscillator etc). So if you're interested in using the BURX's on-board 26 MHz TCVCXO, this would clock the BURX board only, leaving the A/D converters still running at 100 Msamples/sec. The USRP2 can phase lock to an external 10 MHz reference, and it is also possible (with firmware modifications to the aeMB code) to phase lock to a reference clock frequency other than 10 MHz (this has been a topic of discussion on the mailing list over the last week or so). So you can access the 26 MHz TCVCXO output of the BURX board through the U.FL connector, and route it to the SMA input on the USRP2 where the 10 MHz reference typically goes, which will phase lock the two clocks. But you will need to tweak the aeMB firware to make this happen. -- John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get dqpsk2 block?
On Fri, Aug 20, 2010 at 12:56:30AM -0700, Thunder87 wrote: Somehow managed to install git and get gnuradio source. Now I have a problem with source installation. sudo ./configure says: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: Do you have a C++ compiler installed? The answer to your question will be in the output from configure. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BURX 26MHz clock
On Fri, Aug 20, 2010 at 8:47 AM, David Evans ldeev...@yahoo.com wrote: Thanks John, This is how I understood it, but I suppose my real question is (not being a dsp expert), why would you want to do this? For a system with only a single USRP2 in it, there isn't much benefit to having phase lock between the BURX board's 26 MHz TCVCXO and the USRP2's 100 MHz oscillator. However, in a system with more than one USRP2, it is possible to have the 26 MHz TCVCXO from one BURX board feed additional BURX boards such that they all have a common phase-locked reference clock. This requires the appropriate amplification/distribution of the 26 MHz signal but it can be done. The primary benefit to using the BURX's 26 MHz TCVCXO is when using the USRP1, since you actually get the entire system clocked from a single clock source. This includes the A/D converters. In addition, the BURX board also provides the ability to warp the TCVCXO to adjust for clock error, and this correction translates to the sample rate as well which is what you want for most RF receivers. When we started the design of the BURX board, we had (mistakenly) assumed that we would be able to clock the USRP2 from our on-board oscillator, just like on the USRP1. There is always the option of un-soldering the 100 MHz reference and piping in our 26 MHz reference clock, but this is a non-trivial modification. I assumed that being a 26MHz clock, this would be ideal for GSM rate signals? Indeed, in either a USRP1 modified to accept an external clock, or a USRP2 that has undergone the non-trivial modification mentioned above, having the A/D converters run at a multiple of 13 MHz reduces the computational load on the host machine. -- John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Switching to next branch
OK, so my GIT fu is weak. HOw do I switch to the next branch so that I can pick up the gr-uhd stuff. Assuming that I have a current trunk spinning on my local disk, what do I do? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Switching to next branch
You have won an RTFM! http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki#Gnuradio-UHD -Josh On 08/20/2010 01:16 PM, Marcus D. Leech wrote: OK, so my GIT fu is weak. HOw do I switch to the next branch so that I can pick up the gr-uhd stuff. Assuming that I have a current trunk spinning on my local disk, what do I do? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can USRP2 be used to provide power to the preamplifier?
On Fri, Aug 20, 2010 at 2:52 AM, Amee Shah amee...@gmail.com wrote: Hello all, Currently, I have the following hardware setup: Receive Antenna -- Preamplifier -- RF In (USRP2 + DBSRX) I was wondering if I could use USRP2 to supply power (12- 14V) to the preamplifier? If yes, can someone tell me how? Are you trying to power via a DC bias on your feed line from preamp to DBSRX input? If so, you can use the built in bias-tee on J100. Since you are looking for higher than 6.3V, you will want to attach to J100 with your DC voltage between the Antenna Bias + terminal and the GND terminal of J100. If you were looking for a 12-14V source within the USRP2, there is only the 6.3V availble on the extra fan pins (J102 of USRP2) or on J101 of DBSRX. Have a look at the schematics here: http://code.ettus.com/redmine/ettus/projects/public/documents Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Comparison test results: new 2 series dqpsk blocks
On Thu, Aug 12, 2010 at 1:47 PM, ikjtel ikj12...@yahoo.com wrote: I've run a comparison test of - the old GR dqpsk block - the new one (dqpsk2) - the op25 cqpsk (Gardner/Costas) block The resulting constellation diagrams are viewable at http://www.lightlink.com/mhp/qpsk2/ The results are: Gardner is the winner, the old GR blocks take second, the new ones are last (intriguingly as shown in the symbol plot, things seem to start off nicely but then go awry)... The problem could be caused by dumb user error - D.U.E. (TM) or something fixable by simple parameter tweakage? The input file used in all three cases is a complex capture taken from a system using so-called LSM/CQPSK. Basically, that appears to mean something like: a) simulcast distortion is added; b) PI/4 DQPSK is used; c) pulse shaping is stretched so as to fit the bandwidth of the signal into a 12.5 KHz channel; d) a non-standard waveform is used which results in the signal passing through the origin (0,0) point, introducing a rather severe AM component. There are two further wrinkles in this particular case which should be noted: 1) the complex file was captured using a very poor man's USRP, *not* a real USRP [ see http://www.lightlink.com/mhp/iq/ ]. However the file formats are fully compatible. Further, a DBSRX capture exhibits all the same characteristics. 2) the receiving location is outside the designed coverage area of the system The results of all of this, plus the fact that the capture was made prior to verifying that the hardware even was functional for LSM, makes for a very difficult specimen (perfect for torture-testing RX codes)... Best Regards Max That's a very interesting result. Theoretically, it makes sense for the Gardner loop to perform better than the MM, but the polyphase filterbank approach will perform better than both. This suggests either an error in the parameters you chose or a bug in the code. When I'm fully setup with multiple USRPs to do over-the-air testing again, I'll investigate farther. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Peak detector block does not really work. It need to be fixed
On Thu, Aug 12, 2010 at 8:26 AM, Phong Do stadtwald...@yahoo.de wrote: Hello, I'm working now with peak_detector block and find out that some functions don't really work. I've used the following 2 blocks: - Peak Detector (gr_peak_detector): the parameter look ahead seems have no function. I gave look ahead many values but the peak value did not change. I've seen in the gr_peak_detector_xx.cc that the variable d_look_ahead is called but it is not used in the main program. So I think the developer has forgotten this function. - Peak Detector 2 (gr_peak_detector2): in this block look ahead is used, but sometimes the peak detector freezes (output signal stops running in scope sink). I've changed the cpp code a little bit and it does not freeze anymore. But I'm not sure if the detector will work correctly after that. Here is what I've changed: original code: return tmp - 1; changed code: return tmp; Can anyone of the development team have a look at the 2 cpp ? best regards Phong Do Keep in mind that the gr_peak_detector actually expects negative inputs. So if your signal goes from 0 to 100, adjust it so that it goes from -100 to 0. Of course, I say keep in mind even though we probably haven't provided any documentation in the code to that affect... Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Comparison test results: new 2 series dqpsk blocks
--- On Fri, 8/20/10, Tom Rondeau trondeau1...@gmail.com wrote: the polyphase filterbank approach will perform better than both. This suggests either an error in the parameters you chose or a bug in the code. Many thanks for the update. A third possibility (albeit perhaps more remote?) - the signal is PI/4 DQPSK... The Gardner/Costas code needed patching to compensate for that In any case I've got no particular attachment to the Gardner and would actually be very happy to see something that dusts it (and to offer any help in that effort)... Best Max ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Harmonics of the sampling freqeuncy
On Fri, Aug 20, 2010 at 9:03 AM, devin kelly dwwke...@gmail.com wrote: Hello, I'm doing a spectrum sensing project and I'm testing both the USRP 1 and USRP 2. So far, I've modified usrp_scectrum_sense.py to do use the USRP2 with the WBX Right now I'm doing this is what I'm doing with what gr_bin_statistics gives me (as discussed in a previous post) signalPower=0 const = -20*math.log10(tb.fft_size)-10*math.log(tb.power/tb.fft_size) for bin in m.data: signalPower += 20*math.log10(bin/tb.fft_size) + const I then save each of the signalPower variables to a file and plot them using matlab. The attached is what I get when I plot, this is the results of one sweep with the USRP2 and WBX. I have several questions about my results. 1) There are harmonics at multiples of the sampling frequency (100 MHz) which I have pointed arrows at. Has anyone encountered this before? Are there any solutions? Yes, we've seen the harmonics at multiples of the USRP2 clock rate (which is 100 MHz). I don't know of any solution to this issue but would be interested if anyone else has conquered it. We spent a good bit of time trying different options to remove these spurs as we were developing our BURX daughterboard, but ultimately they seem to be radiating from the USRP2. From our experiments, there is also a small component (~10 dB) that is coming in through GND as well, but the dominant source is radiated. Shielding on the WBX daughterboard may help (I believe I've seen copper tracks around the perimeter of both the Tx and Rx sections on the WBX that look like you could solder down a shield of some sort...assuming these stitch down to a GND layer, you may be able to provide an RF can around the RF portions of the circuits, and this could help reduce these received spurs). 2) This sweep was done with a constant gain (31) on the WBX. Should I be changing the gain as a function of the frequency I'm scanning? I ask because after 1.5 GHz power seems to decrease quickly. Yes, to maintain the optimal performance of the receiver, the gain should be changed based on the frequency of operation. For optimal noise figure, Ettus Research posted a series of plots of gain configuration vs. frequency that showed the optimal gain setting at each frequency of operation to also maximize IIP3. See: http://code.ettus.com/redmine/ettus/attachments/46/imd_and_nf_vs_gain.pdf for details at a handful of frequencies. 3) In this sweep I had a terminated all ports with 50 ohm terminators, so I would expect my sweep to be fairly flat. However, there peaks and troughs. Does anyone know how I could get a flatter response? You should be able to get a flatter gain throughout by more carefully selecting your gain settings. -- John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
