discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Dropped data when changing frequency dynamically


From: Tom Golden
Subject: Re: [Discuss-gnuradio] Dropped data when changing frequency dynamically using an Ettus B200
Date: Tue, 20 Dec 2016 09:17:35 -0700

Thank you!  I'll give it a try.
BR,
-Tom


On Tue, Dec 20, 2016 at 8:37 AM, Marcus Müller <address@hidden> wrote:

Dear Tom,

the underlying problem is that everything in this world takes time – and so does the tuning process of the B200; if you change the frequency of the oscillator that is used to convert your signal from baseband to RF passband, or in the other direction, that process simply isn't instantaneous, and the control loops that make the LO stable will need some time to settle. Additionally, for large tunes, the B200 needs to do an autocalibration after tuning – leading to a rather long time until proper signal is available again.

However, not all is lost! Assuming your Doppler bandwidth isn't really enormous and also assuming you're not doing full 56 MHz handwidth at once, you can instruct the USRP sink/source to only tune digitally:

The USRP has a two-step tuning process: On one hand, the physical LO is used to set the "RF" center frequency, and on the other, there's digital frequency shifting that works on the signal as it comes from the ADC (or goes to the DAC) before it hits the decimation (interpolation) step that reduces (expands) the sampling rate by an integer factor between your user-selected sampling rate and the master clock rate (at which ADC/DAC physically sample).offset tuning


That f_offset can hence be chosen arbitrarily, as long f_offset + 1/2 f_sample <= 1/2 f_masterclockrate .

You can use a uhd.tune_request(f_target, f_offset) with your variable, for example, if the variable was called f_doppler and you used

"f_center + f_doppler" in the RF Frequency field before, you could now do

uhd.tune_request(f_center + f_doppler, f_doppler)

to keep the RF LO frequency constant (in fact, there's more to the whole tune_request_t business).

I'd also recommend looking into message passing, which would allow you to *directly* modify the offset frequency [1]. Also, personally, that sounds like the "cleaner" way of doing things – having one of the (in GRC, grey) connections instead of just sharing variable names somewhere.

Best regards,
Marcus

[1] http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax

On 20.12.2016 16:14, Tom Golden wrote:
Hi All,

I am connecting my flowgraph to a doppler prediction tool.  My block currently modifies a variable that is used to specify the center frequency of the USRP Source block.  The variable is updated every second.

When the variable updates, I see blank data (looks like all zeros) for a short blip when this occurs.  My QT FFT and Scope sinks flatline for a short period (subsecond).  Has anyone else seen this?

I've changed my flowgraph to leave the USRP Source alone and shift the frequency using a signal generator and multiply block.  I'm concerned about doing this for TX.  My concern is reduced performance because I'm not transmitting at the center frequency for the USRP Sink.  Is my concern unfounded?  Does anyone know if the same discontinuity for USRP Source is present for USRP Sink?

Thanks in advance,
-Tom



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