discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Why do I have a sampling rate limit of 33.333 Msp


From: LD Zhang
Subject: Re: [Discuss-gnuradio] Why do I have a sampling rate limit of 33.333 Msps?
Date: Tue, 2 Oct 2012 23:00:51 -0700

Hi Nick,

Thanks for your helpful comments. I have followed up on this train of thought on specifying a frequency for the USRP. I guess the advantage is one can achieve the same level of over-sampling with lower sampling rate with this technique when one shifts closer to the frequency of interest. I gave it a try in the USRP and have the following observations:

1. The spectrum center essentially shifts to the specified frequency. No band pass filtering seems to be applied at all. My only concern is that this lack of band pass filtering may hinder dynamic range in certain cases but not a problem for now.

2. I have kind of a logistic question. I am running the GRC file which directs the output to a file sink. Since I am doing different parameter studies of the system performance, I need to generate different files with different operating parameters. I don't know how to automatically dump parameters like samp rate, samp duration, center freq, BW, gain, etc., to the recorded file so that analysis can be somewhat automated. Maybe this is a question that should be asked under a different subject heading.

Thanks,

LD


On Tue, Oct 2, 2012 at 4:32 PM, Nick Foster <address@hidden> wrote:
On Tue, Oct 2, 2012 at 4:25 PM, LD Zhang <address@hidden> wrote:
I would like to explore the system performance from 10 to 100 Msps at an interval of 10 MHz. I know that 20 Msps is probably sufficient. But it would be good to survey the performance at different rates.

Since my interest is not the entire band but multiple signal at discrete frequencies, one possibility is that one sample at say up to 100 MHz internal to the USRP, but then pass the signal through a set of filter banks, and then digital down convert so that signals can be much lower frequencies. Then decimation is truly an option without losing SNR. The end product is a lower rate data set which is OK for Ethernet transport. Is this a good approach? Is there anything wrong in this thinking? Or is this too difficult for the USRP? Is there a better approach? Suggestions are appreciated.

That's a great idea. It's also what the N210 is doing internally. The ADC samples at a fixed 100Msps, and a digital downconverter followed by a decimator (including filtering) selects a portion of that spectrum for transport over the Ethernet bus. When you ask the N210 for a sample rate, it decimates and filters appropriately for that sample rate. When using LFRX, the frequency you pick in UHD is the digital downconverter frequency.

N210 has two independent DSP chains, so if you like, you can get two parallel streams from LFRX, operating at different sample rates and different DDC frequencies.

--n

 
LD


On Tue, Oct 2, 2012 at 4:10 PM, Nick Foster <address@hidden> wrote:
How fast do you need to sample? How many samples do you need?

--n

On Tue, Oct 2, 2012 at 4:00 PM, LD Zhang <address@hidden> wrote:
Is there a way to get around this limit? I suppose you have to have on-board memory to hold data temporarily. Unfortunately the N210 isn't like the E100 which has the memory?

LD


On Tue, Oct 2, 2012 at 3:50 PM, Nick Foster <address@hidden> wrote:
The N210 samples at a fixed rate of 100Msps. However, the gigabit Ethernet transport limits the instantaneous bandwidth over the transport to 25Msps in 16 bit sampling mode, or 50Msps in 8 bit sampling mode.

--n

On Tue, Oct 2, 2012 at 3:47 PM, LD Zhang <address@hidden> wrote:
Hello,

I expect my N210 to have a sampling rate up to 100 Msps. Instead I do not seem to go above 33.3333 MHz. Why? I don't see why the LFRX board should be a limitation.

Thanks,

LD Zhang

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio








reply via email to

[Prev in Thread] Current Thread [Next in Thread]