Hi, Problem fixed:) It was easier than I thought. No patches needed:) The answer was in host/lib/types/tune.cpp always:
tune_request_t::tune_request_t(double target_freq, double lo_off) .target_freq(target_freq) , rf_freq_policy(POLICY_MANUAL) , rf_freq(target_freq + lo_off) , dsp_freq_policy(POLICY_AUTO) , dsp_freq(0.0) There is only a labeling confusion in the definition of tune_request_t. The first 3 fields refer to the RF chain. It is curious that there are both target_freq and rf_freq at the same time. Rf_freq should be renamed lo_freq! rf_freq_policy affects both target freq and lo_freq:) HTH Nikos On Sat, May 24, 2025 at 6:16 AM Nikos Balkanas <nbalka...@gmail.com> wrote: > Hi Marcus, > > I am aware of those. I wouldn't be doing all these if they were available > to me:( > You can check C API availability in usrp.h:) > > BR > Nikos > > On Sat, May 24, 2025 at 12:33 AM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> On 2025-05-23 13:41, Nikos Balkanas wrote: >> >> 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 >> >> I'll note that the C++ API has a couple of "helper" functions for >> creating tune_request_t objects: >> >> >> https://files.ettus.com/manual/structuhd_1_1tune__request__t.html#af9d2c5fb89c10024b1acae43e88ebe7f >> >> The second form, which takes both a desired target frequency, and the >> desired lo_offset, is what I have used in the past. >> >> I don't know if these are somehow available in the C API to form the >> tune_request_t structure. >> >> >> >> 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
