Re: [Discuss-gnuradio] USRP N210 Benchmarks.

[Nick Foster]

On Thu, Nov 24, 2011 at 5:59 AM, Paul M. Bendixen
<address@hidden> 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 <address@hidden>
>>
>>
>> On Tue, Nov 22, 2011 at 3:54 PM, Justyn Bell <address@hidden> 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 <address@hidden>
>>> wrote:
>>>>
>>>>
>>>> 2011/10/27 Marcus D. Leech <address@hidden>
>>>>>
>>>>> 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
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>>
>>>
>>> --
>>> Justyn Bell
>>
>>
>>
>> --
>> Justyn Bell
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> * - - */* -/* * -/* - * */- * * */*/- */- * */* */- * * -/*/- */* - - *- */-
> - */- -/* -/* */* - * */* - * - * -/- * - */- - -/- -//
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>