On 2025-05-23 13:41, Nikos Balkanas wrote:
I'll note that the C++ API has a couple of "helper" functions for creating tune_request_t objects: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
https://files.ettus.com/manual/structuhd_1_1tune__request__t.html#af9d2c5fb89c10024b1acae43e88ebe7fThe 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. RobJust 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.htmlOn 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 tousrp-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
