Marcus, Thanks. I just checked and usrp_list_sensors() shows the RX LOs are locked on both an N320 and X310 that we have. I think I'll start working with the N320 for now instead of the E320 and see if I can make more progress with that for our scanning application, as it isn't AD9361-based.
Thanks, Jim ________________________________ From: Marcus D. Leech <patchvonbr...@gmail.com> Sent: Wednesday, February 2, 2022 11:41 AM To: usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> Subject: [USRP-users] Re: RX Frequency Tuning Questions 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__files.ettus.com_manual_page-5Fgeneral.html-23general-5Ftuning-5Frfsettling&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=XUEEtUEfpaAEGxRI-WGuqHauOvsPdD2NZkfwDnwpYx0&m=GEMRcx3mF9NRSEZH3xxoIfUgpEtahRp18Qx1JSEMnvo&s=4JGYhQKGg3XpurqA1pKw7EZzPfv6AUBKA-8NHL3CN9A&e=> 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
