Hi Rob, I've done all these, but they do not affect LO offset. C API exports only these low level LO commands (in usrp.h) So, either I work it out with what I have, or I expand the C API to include the higher level C++ constructors. My luck. Both issues have to do with the C API:) Sampling rate is very important, but not useful in this case. I leave it on auto. RF is on manual:)
BR Nikos On Fri, May 23, 2025 at 7:59 PM Rob Kossler <rkoss...@nd.edu> wrote: > 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
