Hi Nikos, As I mentioned, I haven't tried the 'c' API. But, it sure looks to me like the 'c' API already supports what you need with the function 'uhd_set_rx_frequency' and the structure 'uhd_tune_request_t' which are both part of the 'c' API and are demonstrated (without LO offset) in the 'c' example 'rx_samples_c.c'. The example could be modified to set the 'dsp_freq' field of the 'uhd_tune_request_t' structure and change the policy fields accordingly. But, perhaps you tried this and it doesn't work. Rob
On Fri, May 23, 2025 at 1:41 PM Nikos Balkanas <nbalka...@gmail.com> 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 > > 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
