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 <[email protected]> wrote: > On Tue, Oct 2, 2012 at 4:25 PM, LD Zhang <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> [email protected] >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
