Thank you! I'll give it a try. BR, -Tom
On Tue, Dec 20, 2016 at 8:37 AM, Marcus Müller <[email protected]> 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).[image: 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 > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > 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
