The standard DSP chain in the X3xx family only allows sample rates that
are an integer fraction of the master clock rate (200MHhz,
by default).

If you want to re-sample with such fine resolution, you'll have to do it
in host-side software, or do an implementation of a fractional resampler
in the FPGA.

On 2016-04-11 08:04, Vladimir via USRP-users wrote:

Links:

[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Thank you!

On Ettus site a support for 184.32 and 120 MHz is also declared for X300. This might help us to some degree. But set_master_clock_rate() seems to have no effect. How difficult is to build FPGA image with either of those hardcoded - is it like changing some const in firmware source or requires significant effort to get it running?

Vladimir

USRP-users mailing list

You can select one of the three possible master clock rates, 200MHz,
184.32MHz or 120MHz directly at initialization. A possible way to do so
is adding e.g "master_clock_rate=184.32e6" to the device address you use
with multi_usrp::make()

Note that you can't really use the 120MHz clock rate with the UBX-160;
the daughterboard has a 160MHz baseband with, and Nyquist frowns upon
sampling that with 120MS/s!

The real problem is that something like arbitrary resampling is usually
very demanding – if you do it on a CPU, then it's often done with an
adjustable interpolation polynomial, and eats a lot of cycles, and if
done in hardware, complicated multi-staged fractional resamplers might
be the answer, or living with reduced signal quality, switching between
two "relatively close" resampling ratios.

Now, one thing to realize: When sampling at 200MS/s, a sample rate
resolution of 1Hz is but 5ppb, so you'll need an insanely accurate
oscillator to even notice that. Usually, you don't resample for such
imperfections, at least not statically; you rather use a symbol timing
tracking loop in software, if you're building a communications system.

May I hence ask: Why do you need finely adjustable sampling rates for?

Best regards,
Marcus

On 11.04.2016 19:45, Vladimir via USRP-users wrote:

You can select one of the three possible master clock rates, 200MHz,
184.32MHz or 120MHz directly at initialization. A possible way to do so
is adding e.g "master_clock_rate=184.32e6" to the device address you use
with multi_usrp::make()

Note that you can't really use the 120MHz clock rate with the UBX-160;
the daughterboard has a 160MHz baseband with, and Nyquist frowns upon
sampling that with 120MS/s!

The real problem is that something like arbitrary resampling is usually
very demanding – if you do it on a CPU, then it's often done with an
adjustable interpolation polynomial, and eats a lot of cycles, and if
done in hardware, complicated multi-staged fractional resamplers might
be the answer, or living with reduced signal quality, switching between
two "relatively close" resampling ratios.

Now, one thing to realize: When sampling at 200MS/s, a sample rate
resolution of 1Hz is but 5ppb, so you'll need an insanely accurate
oscillator to even notice that. Usually, you don't resample for such
imperfections, at least not statically; you rather use a symbol timing
tracking loop in software, if you're building a communications system.

May I hence ask: Why do you need finely adjustable sampling rates? What
is your intended application?

Best regards,
Marcus

On 11.04.2016 19:45, Vladimir via USRP-users wrote:

Marcus,

Thank you for comprehensive answer! In fact, note, I didn't speak about 5 ppb accuracy :). I'm not so experienced in sdr field yet, it's why I missed an order of value - actually I should be talking about 1Hz at 2 MHz sampling rate, and it makes it 0.5 ppm. But all this happened from my inexperience - actually what I'm doing is trying to see a presence of LTE signal in the air, and having X300 I tried to get an open src utility LTE Cell Scanner to work with it. Actually, 184.32 MHz ideally fits this task, so problem is over now, it works just fine. The matter was that LTE Scanner (working with RTLSDR) sets up the sampling rate multiplied by some correction coeff wich is like 0.999998..., so I didn't realize at once how to get a working set up.

Speaking about parameters passed to make() - can I find the list of all them somewhere summarized? Couldn't find it. Can I cut some initialization time instructing it not to perform some searching procedures - for example, tell it not to search for GPSDO since it's not installed? Which parameters should I pass to make() to minimize startup time of this combo - X300+UBX?

Thanks!
Vladimir

184.32MHz or 120MHz directly at initialization. A possible way to do
so is adding e.g "master_clock_rate=184.32e6" to the device address
you use with multi_usrp::make()

UBX-160; the daughterboard has a 160MHz baseband with, and Nyquist
frowns upon sampling that with 120MS/s!

usually very demanding – if you do it on a CPU, then it's often done
with an adjustable interpolation polynomial, and eats a lot of
cycles, and if done in hardware, complicated multi-staged fractional
resamplers might be the answer, or living with reduced signal
quality, switching between two "relatively close" resampling ratios.

resolution of 1Hz is but 5ppb, so you'll need an insanely accurate
oscillator to even notice that. Usually, you don't resample for such
imperfections, at least not statically; you rather use a symbol
timing tracking loop in software, if you're building a
communications system.

for?

  USRP-users wrote:

  for X300. This might help us to some degree.
  But set_master_clock_rate() seems to have no effect. How difficult
  is to build FPGA image with either of those hardcoded - is it like
  changing some const in firmware source or requires significant
  effort to get it running?

    от  mleech@ripnet.com :

              sample rates that are an integer fraction of the
              master clock rate (200MHhz,

              you'll have to do it in host-side software, or do an
              implementation of a fractional resampler in the FPGA.

              fine tuned in X300 (eg 1 Hz resolution at 20 Msps
              point)? Is there any input point where we can provide
              some reference freq or directly Fs from an external
              source? Or, may be some custom FPGA version
              implementing arbitrary resampling or reprogramming dsp
              to the exact freq?

              best (easiest) way to implement it by our own means?

USRP-users mailing list

USRP-users mailing list

Joshua,
Thanks for your reply! It was my first thought too. But 1) ver 3.9.7 as I wrote builds w/o a glitch, and 2) looking at the error messages it's not obvious how libusb could help here. Those functions that it misses are compiler-generated helper-funcs for uhd::... class(es), so I doubt it will find them in libusb... May be I don't see something, but it would be good if someone from USRP team confirmed that libusb is absolutely required here (starting from v. 3.10.0.0).
Vladimir понедельник, 25 сентября 2017г., 20:28 +03:00 от Josh Sendall  jsendall@csir.co.za :

BTW, I indeed forgot to mention that we use X300 over 10G interface, of course without usb.
Vladimir понедельник, 25 сентября 2017г., 20:28 +03:00 от Josh Sendall  jsendall@csir.co.za :