usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsCurious energy spikes from my X310
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 rkossler@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 rkossler@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 nbalkanas@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 patchvonbraun@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 nbalkanas@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 nbalkanas@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 <
patchvonbraun@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 nbalkanas@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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 nbalkanas@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 rkossler@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 rkossler@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 nbalkanas@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 <
patchvonbraun@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 nbalkanas@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 nbalkanas@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 <
patchvonbraun@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 nbalkanas@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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 rkossler@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 <rkossler@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
<nbalkanas@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
<patchvonbraun@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
<nbalkanas@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
<nbalkanas@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 <patchvonbraun@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 <nbalkanas@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-leave@lists.ettus.com
_______________________________________________
USRP-users mailing list --
usrp-users@lists.ettus.com
To unsubscribe send an email to
usrp-users-leave@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to
usrp-users-leave@lists.ettus.com
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 patchvonbraun@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 rkossler@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 rkossler@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 nbalkanas@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 <
patchvonbraun@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 nbalkanas@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 nbalkanas@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 <
patchvonbraun@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 nbalkanas@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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 nbalkanas@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 patchvonbraun@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 rkossler@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 rkossler@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 nbalkanas@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 <
patchvonbraun@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 nbalkanas@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 nbalkanas@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 <
patchvonbraun@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 <
nbalkanas@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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 nbalkanas@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 nbalkanas@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 patchvonbraun@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 rkossler@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 rkossler@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 nbalkanas@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 <
patchvonbraun@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 nbalkanas@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 nbalkanas@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 <
patchvonbraun@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 <
nbalkanas@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com