Project

General

Profile

Actions

Bug #2216

open

uhd: LO offset doesn't seem to work properly

Added by mhostetter almost 7 years ago. Updated almost 6 years ago.

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

0%

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


Files

Screenshot from 2017-04-28 14-49-27.png View Screenshot from 2017-04-28 14-49-27.png 28.5 KB Using UHD source with uhd.tune_request() mhostetter, 04/28/2017 06:49 PM
Screenshot from 2017-04-28 14-52-23.png View Screenshot from 2017-04-28 14-52-23.png 28.3 KB Using Osmocom source setting "lo_offset=" mhostetter, 04/28/2017 06:52 PM
uhd_test.grc uhd_test.grc 60.8 KB Comparison flowgraph mhostetter, 04/28/2017 06:53 PM
Actions #1

Updated by mhostetter almost 7 years 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.

Actions #2

Updated by laforge almost 6 years ago

  • Project changed from SDR (Software Defined Radio) to gr-osmosdr
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)