On 2022-02-02 10:43, Jim Palladino wrote:
Hello,
I'm working on a frequency scanning app where I need to maximize the
tuning speed. I've been playing with timed commands -- I'm having
issues with that and have posted about that separately. But I have
some questions regarding RX tuning.
I'm currently using an E320 and UHD 4.1 and developing a C++ scanning
app. My first question is related to the set_rx_freq() command. If I
look at the documentation here:
https://files.ettus.com/manual/page_general.html#general_tuning_rfsettling
It implies that you need to wait and check the lo_locked sensor after
tuning if you want to make sure that the LO is really locked. This
tells me that the set_rx_freq() command does not block and wait until
it locks. I want to make sure that this is the case, as if I send
consecutive get_time_now() commands, the responses are somewhere
around 2ms apart. If I send the following series of commands:
get_time_now(), set_rx_freq(), get_time_now -- then the time
difference between get_time_now() responses is over 100ms. So, it
seems that the set_rx_freq() command takes quite a while to return. I
just want to confirm that it is not blocking and waiting for lock
before returning. This leads to my second question.
On the E320, I list the sensors using
"usrp->get_rx_sensor_names(ACTIVE_CHAN);" This returns the following
sensors: ad9361_temperature, rssi, lo_lock. Note that it is
"lo_lock" and not "lo_locked". I can querry "ad9361_temperature" and
get a reasonable value each time. However, the "lo_lock" sensor always
reports back unlocked. I use the following command to querry it:
usrp->get_rx_sensor("lo_lock", ACTIVE_CHAN).to_pp_string()
It doesn't matter how long I wait after tuning -- I can wait many,
many seconds. If I look at the samples I'm streaming and capturing
after tuning the RX LO, they look correct. If I insert a tone from a
signal generator, I see it where I expect, and it looks good. At least
by eyeball, it looks like the LO is locked. Similarly, if I run the
"usrp_list_sensors" example application included with UHD, the results
of the RX sensors are:
-------------------------------
| /
| | RX Sensors:
| |
| | Chan 0:
| | * ad9361_temperature: 66.783625 C
| | * rssi: -50.75 dB
| | * ad9361_lock: unlocked
| |
| | Chan 1:
| | * ad9361_temperature: 67.368423 C
| | * rssi: -55.0 dB
| | * ad9361_lock: unlocked
-------------------------------------
So, that is also reporting unlocked. Basically, I haven't been able to
ever read that sensor and have it say: "locked".
Any help understanding whether or not the set_rx_freq() command blocks
until it's locked or why I can't seem to read the "lo_lock" state and
see that it is locked would be appreciated.
Thanks,
Jim
Any device that uses the AD936x family of RFFE chips is going to be
"sluggish" -- at least when tuning further than 100MHz (AFAIR) from the
current frequency--because the
AD9361 needs a lot of "care and feeding" during tuning.
I also recall that the AD9361 doesn't really have an lo_lock indicator,
or if it does, the driver doesn't implement it.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
