Hi Nick Thank you for looking into this.
2011/11/26 Nick Foster <n...@ettus.com> > 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 did a couple of measurements just around the 2,4 GHz mark. The reason we thought it might be the daughterboard mixer is that the problem arose whether we used a 2,4003 GHz carrier and a "zero" cosine or a 2,4GHz carrier and a 300kHz cosine. Since the mixer stage in the DAC is not activated (that we can see, is this a future possibility?) the (~only) next stage is the daughterboard mixer. The included picture is a 2,401GHz carrier, no cosine frequency into a N210_r3 using an RFX2400, 42dB attenuator on a cable to a Rhode&Swartz Spectrum analyser. If you compare the peaks to the datasheet, you will see they are almost identical (bear in mind that the datasheet uses LSB and we use USB). This is in the very part where IQ imbalance is presented. Employing the auto calibration might help reduce the peaks. (when the RFX2400 gets support) > > > > 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 > > OK, thank you, if we have the time before deadline, we will check this out. We have been using the GRC exclusively. > > > 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. > Exactly. As I mentioned in the second paragraph ;) Our best bet as I see it, is to use a quasi-superhetrodyne approach, where possible. Best Paul -- * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */- - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
<<attachment: BT_2401MHz_500KHz_samprate.png>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
