[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Confirming uhd.set_command_time is working

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Confirming uhd.set_command_time is working
Date: Wed, 29 Apr 2015 18:07:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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,

On 04/29/2015 04:59 PM, Anderson, Douglas J. wrote:
(and the center freq was 700e6 before running the command)

From: address@hidden [address@hidden] on behalf of Anderson, Douglas J. [address@hidden]
Sent: Wednesday, April 29, 2015 8:54 AM
To: Marcus Müller; address@hidden
Subject: Re: [Discuss-gnuradio] Confirming uhd.set_command_time is working


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.


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


From: address@hidden [address@hidden] on behalf of Marcus Müller [address@hidden]
Sent: Tuesday, April 28, 2015 1:38 AM
To: address@hidden
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)
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))
print("get_center_freq after sleep: {:f} MHz".format(u.get_center_freq()/1e6))


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> >
[... 2 second pause is here ...]

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?


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]