# Confirming uhd.set\_command\_time is working **URL:** \ **Category:** GNU Radio\ **Created:** [April 28, 2015, 12:05am UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737 "2015-04-28T00:05:42Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [April 28, 2015, 12:05am UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/1 "2015-04-28T00:05:42Z")
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 > > > – > > > \ > > ‘::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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [April 28, 2015, 1:21am UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/2 "2015-04-28T01:21:39Z")
Which USRP is this? M ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [April 28, 2015, 9:39am UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/3 "2015-04-28T09:39:25Z")
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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [April 29, 2015, 4:58pm UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/4 "2015-04-29T16:58:23Z")
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=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf of Marcus M. [removed\_email\_address@domain.invalid] Sent: Tuesday, April 28, 2015 1:38 AM To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 > > > – > > > \ > > ‘::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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [April 29, 2015, 6:08pm UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/5 "2015-04-29T18:08:30Z")
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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [April 29, 2015, 5:01pm UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/6 "2015-04-29T17:01:18Z")
(and the center freq was 700e6 before running the command) * * * From: [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf of Anderson, Douglas J. [removed\_email\_address@domain.invalid] Sent: Wednesday, April 29, 2015 8:54 AM To: Marcus M.; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf of Marcus M. [removed\_email\_address@domain.invalid] Sent: Tuesday, April 28, 2015 1:38 AM To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 > > > – > > > \ > > ‘::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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [April 29, 2015, 6:45pm UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/7 "2015-04-29T18:45:55Z")
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. [removed\_email\_address@domain.invalid] Sent: Wednesday, April 29, 2015 10:07 AM To: Anderson, Douglas J.; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid); Martin B. 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=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid)[mailto:discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid[mailto:discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid)] on behalf of Anderson, Douglas J. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Wednesday, April 29, 2015 8:54 AM To: Marcus M.; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid)[mailto:discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid[mailto:discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid)] on behalf of Marcus M. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Tuesday, April 28, 2015 1:38 AM To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 > > > – > > > \ > > ‘::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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [April 29, 2015, 11:08pm UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/8 "2015-04-29T23:08:16Z")
On 29.04.2015 09:07, Marcus M. wrote: > 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. This is it. The tune value is stored in the property tree, and getting it simply reads it back. I can see how this is non-ideal w.r.t. timed commands. Note that the value stored is not necessarily what you write, though. It gets coerced to something that actually makes sense with your hardware, which is why this function has its place. Cheers, M ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [April 29, 2015, 7:01pm UTC](https://www.ruby-forum.com/t/confirming-uhd-set-command-time-is-working/241737/9 "2015-04-29T19:01:41Z")
Spectrum analyzer and a wrist watch? (or a loopback cable to RX) 🙂