Confirming uhd.set_command_time is working

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

Which USRP is this?

M

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

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: [email protected]invalid
[[email protected]invalid] on behalf
of Marcus M. [[email protected]]
Sent: Tuesday, April 28, 2015 1:38 AM
To: [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

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

(and the center freq was 700e6 before running the command)


From: [email protected]invalid
[[email protected]invalid] on behalf
of Anderson, Douglas J. [[email protected]]
Sent: Wednesday, April 29, 2015 8:54 AM
To: Marcus M.; [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: [email protected]invalid
[[email protected]invalid] on behalf
of Marcus M. [[email protected]]
Sent: Tuesday, April 28, 2015 1:38 AM
To: [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

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:

  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:
[email protected]invalidmailto:[email protected]invalid
[[email protected]invalidmailto:[email protected]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:
[email protected]invalidmailto:[email protected]invalid
[[email protected]invalidmailto:[email protected]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

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

Spectrum analyzer and a wrist watch? (or a loopback cable to RX) :slight_smile:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs