usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsCurious energy spikes from my X310
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
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?
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
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
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
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
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
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 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:
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
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,
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 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