Project

General

Profile

Bug #2216

uhd: LO offset doesn't seem to work properly

Added by mhostetter 12 months ago. Updated 12 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
04/28/2017
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

I discovered this bug while using GQRX, which uses gr-osmosdr.

The UHD tune request with LO offset feature doesn't appear to work properly in OsmoSDR. I created a GNU Radio flowgraph comparing a straight UHD Source and an Osmocom Source and found drastic differences. I configured them the same with 500 ksps sample rate and a 571 kHz LO offset (hoping to move the DC offset outside the spectrum). The spectrum captures are included. The Osmocom SDR source moves the spectrum as the LO offset is changed, but it appears that the shift is post anti-alias filter. I also included the GNU Radio flowgraph.

I looked through the source code and couldn't find anything obvious. Any ideas why specifying "lo_offset=571179" would cause this behavior?

Thanks,
Matt

Screenshot from 2017-04-28 14-49-27.png - Using UHD source with uhd.tune_request() (28.5 KB) mhostetter, 04/28/2017 06:49 PM

Screenshot from 2017-04-28 14-52-23.png - Using Osmocom source setting "lo_offset=" (28.3 KB) mhostetter, 04/28/2017 06:52 PM

uhd_test.grc - Comparison flowgraph (60.8 KB) mhostetter, 04/28/2017 06:53 PM

2620
2621

History

#1 Updated by mhostetter 12 months ago

The only difference I see when comparing the gr-osmosdr code to the gr-uhd code is this:

gr-osmosdr:

double uhd_source_c::set_center_freq( double freq, size_t chan ) {
#define APPLY_PPM_CORR(val, ppm) ((val) * (1.0 + (ppm) * 0.000001))

double corr_freq = APPLY_PPM_CORR( freq, _freq_corr );

// advanced tuning with tune_request_t
uhd::tune_request_t tune_req(corr_freq, _lo_offset);
_src->set_center_freq(tune_req, chan);

_center_freq = freq;

return get_center_freq(chan);
}

gr-uhd:

void usrp_block_impl::_cmd_handler_looffset(const pmt::pmt_t &lo_offset, int chan, const pmt::pmt_t &msg) {
if (pmt::dict_has_key(msg, CMD_FREQ_KEY)) {
// Then it's already taken care of
return;
}

double lo_offs = pmt::to_double(lo_offset);
::uhd::tune_request_t new_tune_request = _curr_tune_req[chan];
new_tune_request.rf_freq = new_tune_request.target_freq + lo_offs;
new_tune_request.rf_freq_policy = ::uhd::tune_request_t::POLICY_MANUAL;
new_tune_request.dsp_freq_policy = ::uhd::tune_request_t::POLICY_AUTO;

_update_curr_tune_req(new_tune_request, chan);
}

In gr-uhd they explicitly set the RF freq policy and DSP freq policy. I wonder if that is what's causing the difference.

Also available in: Atom PDF