I got the chance to look into uhd's guts.
My driver for the X300, x300_radio_control.cpp, uses get_tree() to set/get
all its properties.
This tree is maintained in RFNOC. I don't use it. I use Vivado.
The path given for get_rx_lo_names db_path("rx", channel) didn't have any /
"los" key in it.
I guess all other keys must have worked, or i couldn't set/get anything in
my box.
Could it be because i don't use RFNOC? that would be a shame:(TIA Nikos On Sat, May 24, 2025 at 12:30 PM Nikos Balkanas <nbalka...@gmail.com> wrote: > 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
