On Thu, Nov 24, 2011 at 5:59 AM, Paul M. Bendixen <paulbendi...@gmail.com> wrote: > Hi again > Thank you very much, we expect our thesis will be available from some time > next year, we will add it to the academic section. > > The work we have done so far have pointed us to the daughterboard mixer. > All mixers have problems causing harmonics, and our research so far has > shown us that this is the big problem. > The work with gain adjusting the I Q channels in the drivers give us an idea > we might be right ;)
Can you give more details? If you can, please post your measurements which lead to this conclusion. > > We have spent a good while describing what frequencies the osclilator on the > daughterboard can supply. > When in auto mode, the UHD driver will try to select a frequency that is > offset, so that an actual direct up/down conversion does not take place. > This is what is normally known as the "Superheterodyne radio". However, > because of the division of labour between the mixer in the FPGA and the > mixer on the daughterboard, the IF frequency selected is often too close to > the daughterboard mixer frequency. > > This results in quite a bit of nasty spikes around the desired signal. > There are two ways of testing this: > 1: the "scientific") > Try sending out a single frequency, a flowgraph of [complex cosine] -> [UHD > Sink] was good enough for us. > Check out what spurious frequencies are created. You will typically see the > wanted signal (f_c +/- f_s), a bit of the _actual_ carrier (f_c) and mirrors > of different description. (eg f_c +/- 2*f_s ; f_c -/+ f_s). > Increasing the signal frequency(f_s) will reveal which is the oscilator(f_c) > and which is the mirror. > > Page 19 of the AD8349 (mixer for the RFX2400) showed part of this > explanation. > > 2: the "mechanics version") > Try other frequencies, maybe you will get lucky ;) > > One other method might be to write all or parts of the application in C++, > that way you should be able to select a mixer frequency far away from the > one you need (the N210 FPGA mixer can provide +/- 50MHz offset, i believe > the USRP1 can supply +/- 32MHz). > This way you should be able to reduce the spurious emissions. You can use the advanced tuning parameters in Python as well. No need for C++ if you don't want it. You can pick whatever LO offset frequency you like. http://files.ettus.com/uhd_docs/manual/html/general.html > > The problem using this approach is that you will send the spurious emissions > into other parts of the band (the problem with having a narrow signal in a > wide-band application). You will have this issue with essentially any direct-conversion transceiver which has an open (or reasonably open) front end. --n > > Best > Paul > > 2011/11/23 Justyn Bell <jbell...@gmail.com> >> >> >> On Tue, Nov 22, 2011 at 3:54 PM, Justyn Bell <jbell...@gmail.com> wrote: >>> >>> Hey guys, sorry for the extremely late response. Although identifying >>> and solving USRP problems is great, our focus lies in the project at hand. >>> >>> That being said, the responses on here were great. We tried scaling the >>> input signal magnitude and it actually worked very well. The perplexing >>> thing, however, is that the more we scale the magnitude, the better the >>> observable spectrum got. There was no point in which scaling the magnitude >>> didn't show at least a little improvement on the spectrum. I have attached >>> the spectrum of our actual P25 waveform with scaling. Also included in that >>> figure (yellow) is a signal captured by the USRP that was transmitted using >>> an EF Johnson handset with a P25 waveform installed. Clearly the EF >>> Johnson's spectrum looks the best, and although we didn't try scaling our >>> data further than by .0625, the signal decreases in strength. At some point >>> the signal must be too weak to transmit without both compromising the SNR >>> and the "granularity" or resolution of the original signal (if that's the >>> appropriate word to use). >>> >>> The biggest thing I am considering is this: we are using a 12.5kHz >>> channel on a daughterboard whose range is between 50MHz to 2.2GHz. Is such >>> a narrowband signal on such a wide band board problematic? >>> >>> Although the spectrum looks great when scaled, when we actually test our >>> waveform from USRP to USRP we still get bit errors. Again, it's hard to say >>> how many because we are utilizing a waveform that is equipped with a >>> software vocoder, encryption (small bit errors mean huge losses in packets >>> we receive) and forward error correction (should eliminate small bit >>> errors). You can see how it is difficult to track down bit errors, but my >>> personal opinion is that with forward error correction and the boxes sitting >>> no more than 4 feet away from each other, there are enough errors to ruin >>> our encrypted messages, and that's just too much. >>> >>>> We would very much like to use the very descriptive images you have >>>> provided in our work, if that's okay with you. >>> >>> This is completely fine with all of us here, and thanks again for great >>> responses. With the availability of so many USRPs (did I mention we have 2 >>> USRP1s with the RFX daughterboards in them?) we can at least narrow things >>> down a bit. >>> >>> >>> >>> >>> >>> On Fri, Oct 28, 2011 at 5:08 AM, Marcus D. Leech <mle...@ripnet.com> >>> wrote: >>>> >>>> >>>> 2011/10/27 Marcus D. Leech <mle...@ripnet.com> >>>>> >>>>> Well, that sounds like the lazy solution, intermodulation products are >>>>> bad, so just throwing the transmitter power away is not what I'd prefer. >>>>> >>>>> >>>>> But what it points to is an *analog* issue, entirely independant of the >>>>> CORDIC (which, as I observe, isn't likely involved in the test cases >>>>> at hand here). >>>>> >>>>> Analog gain elements (including DACs) have operating regions over which >>>>> they're linear, and operating regions over which they're not >>>>> linear. If you drive any amplifier near its maximum operating point, >>>>> it will start to become non-linear to one degree or another. I'll >>>>> let Matt or one of the other engineering folks at Ettus comment >>>>> further, but I personally am totally unsurprised when things start to >>>>> become non-linear near the nominal maximum operating point. >>>>> >>>>> >>>>> Is there any way of finding out what the resolution is? We haven't been >>>>> able to track it down for the RFX2400 board, >>>>> but this sounds like a nice way to test if it _is_ the CORDIC. >>>>> >>>>> Look at the tune_result_t from tuning: >>>>> >>>>> >>>>> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__result__t.html >>>>> >>>>> If the actual_dsp_freq is 0, then the CORDIC wasn't involved. >>>>> >>>>> I tuned to an even number of MHz, which on all of the synthesizers >>>>> *should* yield 0 CORDIC frequency. >>>>> >>>>> But maybe Josh can add a feature to 'uhd_usrp_probe' to display the PLL >>>>> resolution (although in some cases, >>>>> it may change with target frequency range, I think). >>>> >>>> Thank yo very much for this, It is really usefull, and it furthermore >>>> confirms what we have observed. >>>> At 2.4GHz there is no problems, when we go 300 kHz up, we start seeing >>>> the problems. (see images attached) >>>> This is further collaborated, with the fact that we can find "good" >>>> frequencies up through the entire band. >>>> >>>> Keep in mind also that spur and phase-noise performance of a PLL >>>> synthesizer will tend to >>>> change with different tunings. Said performance on spot frequencies >>>> can be improved by >>>> engaging in an optimization exercise involving not only PLL register >>>> settings, but changing >>>> the analog loop filter on the PLL as well. >>>> >>>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> -- >>> Justyn Bell >> >> >> >> -- >> Justyn Bell >> >> _______________________________________________ >> 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
