I forgot to mention, the function you were looking at 'uhd_usrp_set_rx_lo_freq' is not the function you need. This is a low-level function that is rarely needed. You will want to stay with the function 'uhd_usrp_set_rx_freq' which will send the appropriate command to the radio to set the LO and to the DDC to set the desired DSP frequency shift that will compensate for the LO being offset. Rob
On Fri, May 23, 2025 at 12:55 PM Rob Kossler <rkoss...@nd.edu> wrote: > 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
