Incorrect center RX frequency when using NCO offset about soapyuhd

[guruofquality]

@ccsh23 How were you invoking the tuning offset from SoapySDR (which calls were you using).

Excuse the psudo code:

This call setFrequency(SOAPY_SDR_RX, 0, centerFreq, {"OFFSET":"2e6"}) should directly result in a UHD tune request with the offset parameter set to 2 MHz: https://github.com/pothosware/SoapyUHD/blob/master/SoapyUHDDevice.cpp#L479

[ccsh23]

I am actually using "BB" component, not "OFFSET":

device->setFrequency(SOAPY_SDR_TX, 0, "RF", 1455e6);
//wait for TX PLL lock here
device->setFrequency(SOAPY_SDR_TX, 0, "BB", -5e6);

device->setFrequency(SOAPY_SDR_RX, 0, "RF", 1455e6);
//wait for RX PLL lock here
device->setFrequency(SOAPY_SDR_RX, 0, "BB", -5e6);

As far as I understand, "OFFSET" is meant to move the LO out of the passband and should be automatically compensated with "BB" component to keep the same frequency as the one which wold be used without calling OFFSET at all - that is not what I want here. I actually want to shift my signal in frequency domain with the "BB" component (and doing this successfully on TX side with above code, problem is with RX side).

[guruofquality]

UHD could be parsing the tune request in a strange or inconsistent way, those two commands basically translate into:

//RF:
uhd::tune_request_t tr(1455e6);
tr.rf_freq = 1455e6;
tr.rf_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
tr.dsp_freq_policy = uhd::tune_request_t::POLICY_NONE;

//BB:
uhd::tune_request_t tr(-5e6);
tr.dsp_freq = -5e6;
tr.rf_freq_policy = uhd::tune_request_t::POLICY_NONE;
tr.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;

When you were using UHD, any idea what the tune requests looked like for comparison? Maybe we can change this to better match what B200 code expects internally. Also, what is getFrequency() reporting for RF and BB components?

[ccsh23]

Okay, I have tested it today and found that this is actually UHD bug.

Everything should work as described above for following frequencies:

double f_rf_tx = 1455e6;
double f_dsp_tx = -5e6;

double f_rf_rx = 1455e6;
double f_dsp_rx = -5e6;

But for some reason it works for following settings:

double f_rf_tx = 1455e6;
double f_dsp_tx = -5e6;

double f_rf_rx = 1455e6;
double f_dsp_rx = 5e6;

So, in RX tune request you have to use negative value of DSP offset used in TX tune request. I have tested it for several offsets in different directions and all results followed that rule. I believe this is wrong and should be reported on UHD github tracker, but I'll wait for your confirmation.

P.S. With applying such settings (which in my opinion are incorrect) in my SoapyUHD-based application I also got expected result.

[guruofquality]

Its so easy to sign flip something like this. I actually have no idea what the intention should be. I think the cordic is often used to implement a LO offset, so the direction doesnt matter, or folks simply just flip the sign. But maybe thats not ideal...

So I think there are two schools of thought here:

• Perhaps this is how UHD looks at the CORDIC freq: when tx is positive it means upconvert, and therefore the reverse is rx downconvert needs a corresponding sign flip.

• On the other hand, you could treat the CORDIC as the desired IF frequency, and so therefore the API should be the same number, and the driver should internally flip the sign if need be to get the intended result.

I think UHD actually wants to implement the second concept (same for SoapySDR), it even has this different sign bit for Tx and not Rx: https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/multi_usrp.cpp#L337 but it just doesnt use this number when running DSP POLICY_MANUAL, so I think it is a UHD bug. It should use the xxsign variable here too: https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/multi_usrp.cpp#L341

Please ask the UHD folks what the intention is with this in mind. But I'm happy to add the sign flip in SoapyUHD for rx or tx in this specific case, but I think thats not the solution.

[ccsh23]

Just got the answer from UHD folks. They say it is intended design. I am not sure what about SoapyUHD now, but I guess your decision will be the best ;) Thanks for the help again!

[guruofquality]

Ignoring the automatic behaviour with the offset argument, if you are just talking about multiplying by a digital sine wave, then f_dsp_rx and f_dsp_tx would have to use opposite signs effectively operate on the same center frequency.

So it looks like I was wrong, the intention of the manual tune policy was to actually set the CORDIC frequency. Therefore a positive frequency will shift the signal in the positive frequency direction, and vice versa. So naturally, if you want the rx and tx center frequency to be the same, the signs have to mismatch so one direction can shift up, and the other down.

So I think the UHD behaviour is expected here, and I should have known that. Again most people just experimentally see what happens and flip the sign because these things tend to get implemented inconsistently, and UHD has flipped cordic signs many times for the same confusing reasons.

I take it this means that you actually think that the setFrequency(direction, channel, "BB", dsp_freq) for SoapyLMS may be swapped for one direction or the other then. Curious about your thoughts, thanks.

[ccsh23]

I just noticed that by calling the same SoapySDR function on LimeSDR and UHD-based devices you get different results (on USRP you have to flip the sign on RX side while on LimeSDR you dont have to do it). I can adapt to any convention and even use different sign im these both cases, just thought that maybe it should be "standarized" so that you are sure what result to expect, no matter what device you are using

[guruofquality]

alright, turns out there is no standard and the driver providers like their sign bits the way they are