Hi Nikos, Although I have not used the 'c' API, it appears it can do the same thing as the c++ API with regard to tune request. The 'c' structure uhd_tune_reqest_t <https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/types/tune_request.h#L28> includes a field called 'dsp_freq'. It seems that you can set this to 30 MHz. The c++ documentation for tune_request_t <https://files.ettus.com/manual/structuhd_1_1tune__request__t.html#af9d2c5fb89c10024b1acae43e88ebe7f> indicates that you should set the RF policy to manual and the DSP policy to automatic. I don't know for certain if you should set the 'target_freq' or the 'rf_freq' field of the tune request to the desired frequency but I'm guessing 'target_freq'.
There is an example program called rx_samples_c.c <https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_samples_c.c> which you may have seen. This shows using a tune request but without an LO offset. Rob On Fri, May 23, 2025 at 12:09 PM Nikos Balkanas <nbalka...@gmail.com> wrote: > Ty Rob for the link and the suggestions, > > We agree completely. I need to offset my LO. > You are probably not aware that I am using the C API. > I cannot use the C++ constructors for tune_request unless they are > exported as C API. > I can just use the tune_request_t struct, which has no lo_off member. > So, I have to offset my LO manually: > uhd_usrp_set_rx_lo_freq(uhd_usrp_handle h, double freq, char *name, size_t > channel, double *outfreq) > I have everything that I need except the LO name:( > To get name I use: > uhd_usrp_get_rx_lo_names() > That's my problem, right there. It just returns me an empty list of names. > No errors either. Why? > Without it, I cannot use the uhd_usrp_set_rx_lo_freq:( > Unfortunately, gdb is no help in this case. After 10 calls to the > /usr/include/c++ files and 7 more > calls to boost and preprocessor defines, it just advances to the next > source line. > Not gdb friendly sources:( > I am also looking to export as C API the tune_request(freq, lo_off) C++ > constructor. > This will mean to change code in uhd, which I will eventually have to, but > right now, > getting uhd_usrp_get_rx_lo_names() to work, is better:) > > BR > Nikos > > > > > > On Fri, May 23, 2025 at 4:57 PM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> On 2025-05-23 09:49, Rob Kossler wrote: >> >> Hi Nikos, >> Your RF card has 120 MHz bandwidth. The strong tone you see will always >> be at the center. But, if your application can tolerate using an >> instantaneous bandwidth < 60 MHz, you can use offset tuning as Marcus >> mentioned. To do this you simply need to create a tune request with your >> desired RF frequency and then specify an LO offset frequency of 30 MHz. >> This is all that is needed (again assuming that your bandwidth of interest >> is < 60 MHz). This link >> <https://dsp.stackexchange.com/questions/30562/large-spike-at-the-center-frequency-when-using-ettus-x310> >> discusses the topic. >> >> Also, if you want to reduce the DC offset, there are calibrations for the >> X310 - one of which will mitigate this signal. >> Rob >> >> Just a note that AFAIR, the *RX* DC-offset correction is something that >> doesn't require input from the calibration routines--it runs all the time >> (if its turned on). >> >> But phase/amplitude *balance* does require that you run the appropriate >> CAL utilities: >> >> https://files.ettus.com/manual/page_calibration.html >> >> >> >> On Fri, May 23, 2025 at 8:11 AM Nikos Balkanas <nbalka...@gmail.com> >> wrote: >> >>> I have implemented the following calls for uhd_usrp_set_rx_lo_freq: >>> >>> uhd_string_vector_handle names; >>> uhd_string_vector_make(&names); >>> if ((err = uhd_usrp_get_rx_lo_names(dev[channel], channel, &names))) >>> warn(log, "Failed to get lo names (%d). %s.\n", 0, FL, LN, FN, >>> err, uhdError(err)); >>> if ((err = uhd_string_vector_size(names, &len))) >>> warn(log, "Failed to get lo names size (%d). %s.\n",0,FL,LN,FN,err, >>> uhdError(err)); >>> if (!len) >>> { >>> error(log, "No lo names found on channel %d.\n", 0, FL, LN, FN, >>> channel); >>> uhd_string_vector_free(&names); >>> return(FAIL); >>> } >>> uhd_string_vector_free(&names); >>> >>> The problem is that names always returns 0. This is not right for my >>> SBX-120, or any >>> daughterboard with a tuner:( This is what i can get from the API. There >>> are no LO examples. >>> I have seen lo_enable() in c++, but nothing exported to C. What am I >>> missing? >>> >>> TIA >>> Nikos >>> >>> On Fri, May 23, 2025 at 8:12 AM Nikos Balkanas <nbalka...@gmail.com> >>> wrote: >>> >>>> Thx Marcus, >>>> >>>> For your fast and informative answers. Sorry it took me a while to >>>> reply, >>>> but I'm still trying to get: >>>> tune_request(freq, lo_off) >>>> to work in C. >>>> My X310 has 2 SBX-120 boards. Using uhd 4.6.0 in Ubuntu 24.04. >>>> True about the tuner. Much cheaper and easier to implement it in analog. >>>> I am using your FPGA image. Haven't touched it myself, yet. >>>> So, the spike is pretty narrow to interfere with my signals, but still >>>> messes my power calculations:( >>>> I already implemented the integer frequency tuner and working on the >>>> low oscillator offset. >>>> If you have any pointers about it, feel free to advise. >>>> LO is not part of the request_tuner_t struct. It is set independently. >>>> Is this the same LO in uhd_usrp_set_rx_lo_freq? >>>> If this is the case I can modify it externally:) >>>> >>>> BR >>>> Nikos >>>> >>>> On Fri, May 23, 2025 at 4:40 AM Marcus D. Leech < >>>> patchvonbr...@gmail.com> wrote: >>>> >>>>> On 2025-05-22 21:31, Nikos Balkanas wrote: >>>>> >>>>> The spike is very clean to come from outside. >>>>> Must be from my X310. My tuner must be adding a signal to the >>>>> center frequency. The small artifact at 2 Ghz is probably the tuner >>>>> not >>>>> equilibrating fully. >>>>> I recently updated my FPGA image. Is that where the tuner lives? >>>>> >>>>> You haven't mentioned in this thread which daughtercard you're >>>>> using. RF front-ends that use complex-baseband >>>>> downconversion suffer from something called "DC-offset", which >>>>> produces a spike at 0Hz in the complex spectrum. >>>>> The radio block in the standard FPGAs has methods for reducing this, >>>>> unless you turn it off. This is a very very >>>>> *normal* thing for complex-baseband receiver chains. >>>>> >>>>> If the algorithms are engaged and working, then there'll still be a >>>>> central spike, but *considerably* reduced, and I find that >>>>> said spike is usually swamped by external signals, even in radio >>>>> astronomy. >>>>> >>>>> The other method that people use is to use "offset tuning". Where the >>>>> tuner is tuned to a different RF frequency, and the >>>>> DDC brings your signal of interest down to 0Hz. >>>>> >>>>> https://files.ettus.com/manual/page_general.html#general_tuning >>>>> >>>>> The "tuner" is an analog collection of components, including an LO >>>>> generator, and mixers. While it is *controlled* through >>>>> the FPGA, it is an analog subsystem. >>>>> >>>>> >>>>> >>>>> On Fri, May 23, 2025 at 3:19 AM Nikos Balkanas <nbalka...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Whenever I look at my spectrum I always see an energy spike at the >>>>>> center frequency. >>>>>> In the first image you can see a spike at 2, but not at 2.001 Ghz. In >>>>>> the next image, >>>>>> at 2.001 Ghz you can see the energy spike at the center frequency, >>>>>> but also a small >>>>>> spike at 2 Ghz. >>>>>> I have verified these results by both fosphor (OpenCL fft) and >>>>>> fftw3f. Besides, if it were >>>>>> an fft artifact, why is the spike at 2 Ghz still visible after a few >>>>>> mins? These spikes >>>>>> seem to be transient, but real. In that part of the spectrum, you >>>>>> there is no traffic. Could it be harmonics from my power supply? >>>>>> Problems >>>>>> with my X-310? My transmitter >>>>>> doing funny things (I have 2 boards and not enabling my transmitter >>>>>> anywhere)? >>>>>> Naming of images is freq_sr.jpg. All are in Mhz. >>>>>> >>>>>> TIA >>>>>> Nikos >>>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>> >>>> _______________________________________________ >>> USRP-users mailing list -- usrp-users@lists.ettus.com >>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>> >> >>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
