discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked
Date: Tue, 31 Mar 2015 23:31:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

I must admit I don't know the exact reason, but the thing about the remaining DC offset is generally that it depends on many factors, including temperature, so it's very hard to calibrate once forever, whereas things like IQ imbalance tend to behave alike on both I and Q, so that temperature dependency is not as bad.

On 03/31/2015 11:25 PM, Anderson, Douglas J. wrote:
Marcus,

That makes sense, I hadn't thought of the DSP tuning issue, though I think it would be infinitely more useful to make the stream tagging logic aware of LO/DSP tuning and tag the first usable block in either case. Slightly more involved than I assumed though.

I was actually going to ask this on the Ettus list later but since you brought up DC offset: is there a technical reason that there is no uhd_rx_dc_offset cal script? Is is because the LO can be offset so it's considered unnecessary or would a cal script not work as well for the RX side as it does the TX side for some reason? I read through the tx_dc_offset cal script last week and was curious...

-Doug

From: address@hidden [address@hidden] on behalf of Marcus Müller [address@hidden]
Sent: Tuesday, March 31, 2015 2:15 PM
To: address@hidden
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

Hi Doug,

the rationale behind that is that these tags correspond to the stream metadata coming from the USRP, which tell the host when the tuning *operation* has taken place. Now, you're right, it's a problem to think you're tuned although your LO still hasn't settled, but since tunes could also be digital-path only, using the "earliest" time seems correct.

By the way, you might also want to try a different approach, based on timed commands: you can set a time for things like tune requests, thus making sure that the tuning happens at the exact point in time you want it to (and not influenced by the latency and load of your general purpose PC). You can then simply "take" the right samples without caring about tags at all, because you know when these should occur (i.e. which numbers these should have).

Greetings,
Marcus

PS: try turning off the DC offset correction, if you're on the N210, for fast-tuning applications. You'll have a bigger DC offset, but less "swinging" after each tune.
PS2: I don't know whether your overall frequency range allows this, but as long as you tune within your USRP/daughterboards physical bandwidth, you might just tune digitally and avoid LO retuning:
http://files.ettus.com/manual/page_general.html#general_tuning_process
On 03/31/2015 09:54 PM, Anderson, Douglas J. wrote:
Hi all,

I've been working on a flowgraph that controls sweeping a USRP by retuning and then dumping samples until catching the sample tagged with rx_freq of the correct value.

I was confused as to why I was still getting mountains of garbage samples (several hundred thousand at 10MS/s) after catching the rx_freq tag, until today I put "assert(usrp->get_sensor("lo_locked").to_bool())" after the block that identifies the correct rx_freq tag, and it popped immediately.

I'm wondering about the prudence of saying a sample is "at a certain frequency" before the LO has had a chance to settle.

I also realize that gr-uhd folks are trying to make the message interface more robust, and the rx_freq tag is an awesome idea, but what I really want to know is what is the first USABLE sample at my requested freq. If I still have to carry around a usrp_source pointer so that I can check the LO state, then the tags output by the usrp_source lose a lot of appeal.

Any chance of making rx_freq tag "the first usable sample", or is there a good reason for the way it works that I haven't considered?

-Doug


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



_______________________________________________
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]