Thanks Marcus, that's what I assumed (that the code that spits back the "Successfully tuned" bit and stores the current freq settings) is independent of the queue that holds the timed commands.
I'm wondering if there's no other way to verify that the timed command is actually being delayed. Right now I feel like I just have to take in on faith that timed commands are working, know what I mean? -Doug ________________________________ From: Marcus Müller [marcus.muel...@ettus.com] Sent: Wednesday, April 29, 2015 10:07 AM To: Anderson, Douglas J.; discuss-gnuradio@gnu.org; Martin Braun Subject: Re: [Discuss-gnuradio] Confirming uhd.set_command_time is working Hi Doug, I've had a multi-page explanation to this phenomenon typed out when it hit me. Consider your output: about to issue tune command... -- Successfully tuned to 800.000000 MHz Between these two lines, you issue your timed tuning command (to go from 700 to 800 MHz) 2s in the future. I shouldn't read UHD code any further; there's logically only two options: 1. Either, the result of set_center_freq (and also, get_center_freq) comes from a cached value from the PC, in which case it will immediately return, and give you that "newly cached" value (while it's still not valid). In that case, no wait between those two lines of output. 2. Or, the result of set_center_freq (& get_center_freq) comes from the USRP; if that's the case, getting the result will be a timed command just like setting the frequency -- and hence the function will block for as long as it waits for an answer, you will see a 2s pause between the aforementioned output lines, and you'll also get the new value. This can't really be solved without bigger changes to the USRP/settings_bus architecture, if I'm not mistaken. But then again, this is something of architectural nature, and maybe Martin or Ian know better than I how it's actually handled. Best regards, Marcus On 04/29/2015 04:59 PM, Anderson, Douglas J. wrote: (and the center freq was 700e6 before running the command) ________________________________ From: discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org<mailto:discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org> [discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org<mailto:discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org>] on behalf of Anderson, Douglas J. [dander...@its.bldrdoc.gov<mailto:dander...@its.bldrdoc.gov>] Sent: Wednesday, April 29, 2015 8:54 AM To: Marcus Müller; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Confirming uhd.set_command_time is working Martin, Sorry for the slow reply. It's a USRP N210. I'm running a pybombs build of UHD and GNURadio that's about a month old. Marcus, Using "actual_rf_freq" and "actual_dsp_freq", I get: about to issue tune command... -- Successfully tuned to 800.000000 MHz -- immediate tune result: 800.000000MHz RF, 0.000000 Hz DSP get_center_freq before sleep: 800.000000 MHz get_center_freq after sleep: 800.000000 MHz -Doug ________________________________ From: discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org<mailto:discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org> [discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org<mailto:discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org>] on behalf of Marcus Müller [marcus.muel...@ettus.com<mailto:marcus.muel...@ettus.com>] Sent: Tuesday, April 28, 2015 1:38 AM To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Confirming uhd.set_command_time is working Hi Doug, I'm not 100%, but: Getting the center frequency might be a command which will also end up in the timed command queue. What happens if you: u.set_command_time(u.get_time_now() + uhd.time_spec(2)) print("about to issue tune command...") result = u.set_center_freq(800e6) u.clear_command_time() print("immediate tune result: {:f}MHz RF, {:f} Hz DSP".format(result.rf_freq/1e6, result.dsp_freq)) print("get_center_freq before sleep: {:f} MHz".format(u.get_center_freq()/1e6)) time.sleep(2) print("get_center_freq after sleep: {:f} MHz".format(u.get_center_freq()/1e6)) Greetings, Marcus On 04/28/2015 12:03 AM, Anderson, Douglas J. wrote: Hi all, I'm playing around with timed commands on the USRP, but I'm not sure I understand them correctly. I've got a usrp connected as "u" and set to center freq 700e6. >>> u.set_command_time(u.get_time_now() + uhd.time_spec(2)); >>> u.set_center_freq(800e6); u.clear_command_time(); >>> print(u.get_center_freq()); time.sleep(2); print(u.get_center_freq()) -- Successfully tuned to 800.000000 MHz -- <gnuradio.uhd.uhd_swig.tune_result_t; proxy of <Swig Object of type '::uhd::tune_result_t *' at 0x7f1b75a3b930> > 800000000.0 [... 2 second pause is here ...] 800000000.0 It looks like it's changing the freq immediately... but I'm assuming as usual there's more than meets the eye to this command. Any hints? -Doug _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
