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 (see also https://github.com/EttusResearch/uhd/issues/534). 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> 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 > > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to 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
