Martin, Thanks. On Friday, one of my coworkers saw something on github about the lo_locked sensors being fixed. So, that is good -- thanks for pointing that out.
Regarding your other comments about timed "future tunes" on the E320: you mentioned that the E320 doesn't let you do those. That is what I've been trying to get working. Are you saying that timed commands are not supported on the E320 -- or just timed tunes? Our ultimate target device is an N320/N321, so I'm going to start developing with one of those. Do timed commands (including frequency tunes) work on the N320/N321? In a different USRP-users email I commented that the UHD provided "test_timed_commands" example doesn't work on either the N320, E320, or X310 in UHD 4.1 (nor does my own timed frequency tuning code). A few others have chimed in that they have found the same thing -- although Marcus L. mentioned that "test_timed_commands" does work with an N310 in UHD 3.15. If you could help clarify any of this, it would be appreciated. Thanks, Jim ________________________________ From: Martin Braun <martin.br...@ettus.com> Sent: Monday, February 7, 2022 6:01 AM To: Jim Palladino <j...@gardettoengineering.com> Cc: USRP-users@lists.ettus.com <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] RX Frequency Tuning Questions Jim, just a quick follow-up. There was indeed a bug with the lo-lock sensors which was fixed in https://github.com/EttusResearch/uhd/commit/6666f36c267fc9ca908032fb719ec318c142636f<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_commit_6666f36c267fc9ca908032fb719ec318c142636f&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=XUEEtUEfpaAEGxRI-WGuqHauOvsPdD2NZkfwDnwpYx0&m=8pK83LBB7KAhLXeNc09e57pJ83WRI6hjRKkUjMCJg90&s=H1DYQq-AykcX0u5iRic0_dKSZ-XxL8tS2ImlRjGUHHQ&e=> (see also https://github.com/EttusResearch/uhd/issues/534<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_issues_534&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=XUEEtUEfpaAEGxRI-WGuqHauOvsPdD2NZkfwDnwpYx0&m=8pK83LBB7KAhLXeNc09e57pJ83WRI6hjRKkUjMCJg90&s=D5nPFApIzjnAFrUWvAMofbvCFoWkbIRuoXDn68_-LeE&e=>). Both the name mismatch (lo_lock vs. lo_locked) and the lack of reporting lock are fixed. But as Marcus says, the tuning is not as fast as on N320. As for your first question: Yes, these API calls are non-blocking, unless the hardware queues are full up. This is so you can schedule future tunes (although E320 doesn't let you do those). However, when the queues fill up, those API calls become blocking. --M On Wed, Feb 2, 2022 at 5:15 PM Jim Palladino <j...@gardettoengineering.com<mailto:j...@gardettoengineering.com>> 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=8pK83LBB7KAhLXeNc09e57pJ83WRI6hjRKkUjMCJg90&s=B1--VAdNrxLGnLI1wGs-Nyl_ge6ekEqS_rhh7wh61rQ&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 _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
