Re: [Discuss-gnuradio] USRP N210 Benchmarks.

[Paul M. Bendixen]

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 ;)

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.

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).

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

-- 
• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//