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. [[email protected]]
Sent: Wednesday, April 29, 2015 10:07 AM
To: Anderson, Douglas J.; [email protected]; 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:
- 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.
- 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.invalidmailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalidmailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid]
on behalf of Anderson, Douglas J.
[[email protected]mailto:[email protected]]
Sent: Wednesday, April 29, 2015 8:54 AM
To: Marcus M.;
[email protected]mailto:[email protected]
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.invalidmailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalidmailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid]
on behalf of Marcus M.
[[email protected]mailto:[email protected]]
Sent: Tuesday, April 28, 2015 1:38 AM
To: [email protected]mailto:[email protected]
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
