Is updating fpga image by uhd_image_downloader.py helpful?

    Is there any way to re-write fpga image so that it can support? 

    Really appreciate if someone suggests me some solution to it.

Hi all I'm trying to use USRP X Series (2943/2954) in my project. I want to try 122.88MHz sampling rate, but ettus.com says that only 200MHz and 184.32MHz and the corresponding integer divisor. Is updating fpga image by uhd_image_downloader.py helpful? Is there any way to re-write fpga image so that it can support? Really appreciate if someone suggests me some solution to it. Best Regards, J.Jeffson

     Is updating fpga image by uhd_image_downloader.py helpful?

     Is there any way to re-write fpga image so that it can

     Really appreciate if someone suggests me some solution to it.

Hi J. Jeffson, to answer quickly: see below. On Fri, 2018-11-30 at 11:36 +0800, 蒋逸凡 via USRP-users wrote: > Hi all > I'm trying to use USRP X Series (2943/2954) in my project. I > want to try 122.88MHz sampling rate, but ettus.com says that only > 200MHz and 184.32MHz and the corresponding integer divisor. > exactly. > Is updating fpga image by uhd_image_downloader.py helpful? > no. > Is there any way to re-write fpga image so that it can > support? no. This is a restriction of the clocking architecture and analog components. > Really appreciate if someone suggests me some solution to it. Hm, if my head calculation doesn't betray me: 122.88 MHz = 2¹⁶ · 5⁴ · 3¹ Hz 200 MHz = 2 · 10⁸ Hz = 2⁹ · 5⁸ Hz Hence, 200 MHz / 122.88 MHz = 2⁻⁷·5⁴·3⁻¹ So you could build a rational resampler that interpolates by 2⁷·3 = 384 and decimates by 5⁴ = 625. That is not a nice filter! Don't know if I'd generally recommend an MCR of 184.32 MHz but, let's try: 184.32 MHz = 2¹⁵ · 5⁴ · 3² Hz Hence, 184.32 MHz / 122.88 MHz = 2⁻⁶ · 5⁴ · 3⁻² So you could build a rational resampler that interpolates by 2⁶·3² = 576 and decimates by 5⁴ = 625. So, that's even worse. So, I'd say, you're not going to implement this as a rational resampler. So, either find some sampling rate close enough for your system to work (for example, if your system can work with a 2% sample rate error, go for 120 MHz sampling rate, and things become much easier! Interpolate by 3, decimate by 5, done, you could implement that as an FPGA resampler yourself, if you find your computer isn't up to doing that conversion). Or, implement an arbitrary resampler. I can't really advise you on that based on the info you gave us: Arbitrary resamplers can become quite computationally intense, and ugly in error bounds, but can often be designed to fit your specific application's needs. So, what application requires a sampling rate of 122.88 MHz? Best regards, Marcus M > > Best Regards, > J.Jeffson > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

     Is updating fpga image by uhd_image_downloader.py helpful?

     Is there any way to re-write fpga image so that it can

     Really appreciate if someone suggests me some solution to it.

On Fri, Nov 30, 2018 at 11:29 AM Marcus Müller via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi J. Jeffson, > > to answer quickly: see below. > On Fri, 2018-11-30 at 11:36 +0800, 蒋逸凡 via USRP-users wrote: > > Hi all > > I'm trying to use USRP X Series (2943/2954) in my project. I > > want to try 122.88MHz sampling rate, but ettus.com says that only > > 200MHz and 184.32MHz and the corresponding integer divisor. > > > exactly. > > > Is updating fpga image by uhd_image_downloader.py helpful? > > > > no. > > > Is there any way to re-write fpga image so that it can > > support? > > no. This is a restriction of the clocking architecture and analog > components. > > > > Really appreciate if someone suggests me some solution to it. > > Hm, if my head calculation doesn't betray me: > 122.88 MHz = 2¹⁶ · 5⁴ · 3¹ Hz > 200 MHz = 2 · 10⁸ Hz > = 2⁹ · 5⁸ Hz > > Hence, 200 MHz / 122.88 MHz = 2⁻⁷·5⁴·3⁻¹ > > So you could build a rational resampler that interpolates by 2⁷·3 = 384 > and decimates by 5⁴ = 625. > > That is not a nice filter! > > Don't know if I'd generally recommend an MCR of 184.32 MHz but, let's > try: > > 184.32 MHz = 2¹⁵ · 5⁴ · 3² Hz > > Hence, 184.32 MHz / 122.88 MHz = 2⁻⁶ · 5⁴ · 3⁻² > So you could build a rational resampler that interpolates by 2⁶·3² = > 576 > and decimates by 5⁴ = 625. > > So, that's even worse. > Something seems off here. 184.32 * 2 / 3 = 122.88 That shouldn't be too terrible to do on the host system, or to potentially even build into an FPGA? Brian

Thanks very much for advice. My application is about sampling design for FFT about 5G SDR implementation, but I may still try arbitrary resampler. Best Regards J.Jeffson ---------------- ---------- Origin message ---------- >From："Brian Padalino" <bpadalino@gmail.com> >To：marcus.mueller@ettus.com >Subject：Re: [USRP-users] Is there any method for X310 to support 122.88M Sampling rate? >Date：2018-12-01 00:39:27On Fri, Nov 30, 2018 at 11:29 AM Marcus Müller via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi J. Jeffson, > > to answer quickly: see below. > On Fri, 2018-11-30 at 11:36 +0800, 蒋逸凡 via USRP-users wrote: > > Hi all > > I'm trying to use USRP X Series (2943/2954) in my project. I > > want to try 122.88MHz sampling rate, but ettus.com says that only > > 200MHz and 184.32MHz and the corresponding integer divisor. > > > exactly. > > > Is updating fpga image by uhd_image_downloader.py helpful? > > > > no. > > > Is there any way to re-write fpga image so that it can > > support? > > no. This is a restriction of the clocking architecture and analog > components. > > > > Really appreciate if someone suggests me some solution to it. > > Hm, if my head calculation doesn't betray me: > 122.88 MHz = 2¹⁶ · 5⁴ · 3¹ Hz > 200 MHz = 2 · 10⁸ Hz > = 2⁹ · 5⁸ Hz > > Hence, 200 MHz / 122.88 MHz = 2⁻⁷·5⁴·3⁻¹ > > So you could build a rational resampler that interpolates by 2⁷·3 = 384 > and decimates by 5⁴ = 625. > > That is not a nice filter! > > Don't know if I'd generally recommend an MCR of 184.32 MHz but, let's > try: > > 184.32 MHz = 2¹⁵ · 5⁴ · 3² Hz > > Hence, 184.32 MHz / 122.88 MHz = 2⁻⁶ · 5⁴ · 3⁻² > So you could build a rational resampler that interpolates by 2⁶·3² = > 576 > and decimates by 5⁴ = 625. > > So, that's even worse. > Something seems off here. 184.32 * 2 / 3 = 122.88 That shouldn't be too terrible to do on the host system, or to potentially even build into an FPGA? Brian