usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsSensor issue
Hello,
I am trying to use the suggestion for manual tuning:
https://files.ettus.com/manual/page_general.html#general_tuning_dsp_sign
I am using the following sensor code:
static uhd_sensor_value_handle lo_locked = NULL;
uhd_sensor_value_make(&lo_locked);
if ((err = uhd_usrp_get_rx_sensor(dev[channel], "lo_locked", channel,
&lo_locked)))
warn(log, "Failed to get lo_locked[0] sensor\n", 0, FL, LN, FN);
if ((err = uhd_usrp_set_rx_freq(dev[channel], &tune_req, channel,
&tune_res)))
{
error(log, "Unable to set Tuner[%d] to %ld Hz, LO[%d]: %ld H (%d).
%s.\n", 0, FL, LN,
FN, channel, freq, channel, lo_off, err, uhdError(err));
return(FAIL);
}
while (!ready)
{
uhd_sensor_value_to_bool(lo_locked, &ready);
printf("NIKOS!!! ready: %d\n", ready);
sleep(0);
}
ready is always 0. Never changes value.Goes to an infinite loop. Am I doing
anything wrong?
TIA
Nikos
On 2025-05-24 14:35, Nikos Balkanas wrote:
uhd_usrp_get_rx_sensor(dev[channel], "lo_locked", channel, &lo_locked)))
You need to repeatedly call this in your while loop.
All you're doing is getting the sensor value once, immediately after
tuning, and then spinning on the value of the "value_to_bool"
conversion, which
will never change, because you aren't getting a fresh value of the
sensor.
Ty very much,
That worked.It converged in just 2 loops:)
I thought I was linking sensor to sensor, and lo_locked was updating in
real time:(
But this was a sensor_value_handle, not a sensor:(
BR
Nikos
On Sat, May 24, 2025 at 9:44 PM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 2025-05-24 14:35, Nikos Balkanas wrote:
uhd_usrp_get_rx_sensor(dev[channel], "lo_locked", channel, &lo_locked)))
You need to repeatedly call this in your while loop.
All you're doing is getting the sensor value once, immediately after
tuning, and then spinning on the value of the "value_to_bool"
conversion, which
will never change, because you aren't getting a fresh value of the
sensor.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Spectrum looks much nicer at the expense of less accurate tuning.
There is still some LO leakage...
I have my offset at sr/2 +20e6. maybe I need more.
On Sat, May 24, 2025 at 10:57 PM Nikos Balkanas nbalkanas@gmail.com wrote:
Ty very much,
That worked.It converged in just 2 loops:)
I thought I was linking sensor to sensor, and lo_locked was updating in
real time:(
But this was a sensor_value_handle, not a sensor:(
BR
Nikos
On Sat, May 24, 2025 at 9:44 PM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 2025-05-24 14:35, Nikos Balkanas wrote:
uhd_usrp_get_rx_sensor(dev[channel], "lo_locked", channel, &lo_locked)))
You need to repeatedly call this in your while loop.
All you're doing is getting the sensor value once, immediately after
tuning, and then spinning on the value of the "value_to_bool"
conversion, which
will never change, because you aren't getting a fresh value of the
sensor.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
On 2025-05-24 16:42, Nikos Balkanas wrote:
Spectrum looks much nicer at the expense of less accurate tuning.
There is still some LO leakage...
I have my offset at sr/2 +20e6. maybe I need more.
I always just set my offset, when I use it at all, to Fs/1.8 or
thereabouts. This moves the LO leakage
a little bit out-of-band.
On Sat, May 24, 2025 at 10:57 PM Nikos Balkanas nbalkanas@gmail.com
wrote:
Ty very much,
That worked.It converged in just 2 loops:)
I thought I was linking sensor to sensor, and lo_locked was
updating in real time:(
But this was a sensor_value_handle, not a sensor:(
BR
Nikos
On Sat, May 24, 2025 at 9:44 PM Marcus D. Leech
<patchvonbraun@gmail.com> wrote:
On 2025-05-24 14:35, Nikos Balkanas wrote:
uhd_usrp_get_rx_sensor(dev[channel], "lo_locked", channel,
&lo_locked)))
You need to repeatedly call this in your while loop.
All you're doing is getting the sensor value once, immediately
after
tuning, and then spinning on the value of the "value_to_bool"
conversion, which
will never change, because you aren't getting a fresh value
of the
sensor.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Actually , the previous runs were with sr/2 + 1e6 offset.
The ADF4350 has max freq range 2.2 - 4.4 Ghz
With sr/2 + 20e6 offset spectrum looks way better:
l2 specifies that offset. For comparison original with auto/auto is also
included.
Tuning accuracy is not an issue. It was just a matter of reporting the
right field,
clipped_rf_freq:)
On Sun, May 25, 2025 at 12:02 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 2025-05-24 16:42, Nikos Balkanas wrote:
Spectrum looks much nicer at the expense of less accurate tuning.
There is still some LO leakage...
I have my offset at sr/2 +20e6. maybe I need more.
I always just set my offset, when I use it at all, to Fs/1.8 or
thereabouts. This moves the LO leakage
a little bit out-of-band.
On Sat, May 24, 2025 at 10:57 PM Nikos Balkanas nbalkanas@gmail.com
wrote:
Ty very much,
That worked.It converged in just 2 loops:)
I thought I was linking sensor to sensor, and lo_locked was updating in
real time:(
But this was a sensor_value_handle, not a sensor:(
BR
Nikos
On Sat, May 24, 2025 at 9:44 PM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 2025-05-24 14:35, Nikos Balkanas wrote:
uhd_usrp_get_rx_sensor(dev[channel], "lo_locked", channel,
&lo_locked)))
You need to repeatedly call this in your while loop.
All you're doing is getting the sensor value once, immediately after
tuning, and then spinning on the value of the "value_to_bool"
conversion, which
will never change, because you aren't getting a fresh value of the
sensor.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
