Spectrum analyzer and a wrist watch? (or a loopback cable to RX) :-)
On Apr 29, 2015, at 9:44 AM, "Anderson, Douglas J." <dander...@its.bldrdoc.gov>
wrote:
> 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:
> 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=its.bldrdoc....@gnu.org
>> [discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org] on behalf of
>> Anderson, Douglas J. [dander...@its.bldrdoc.gov]
>> Sent: Wednesday, April 29, 2015 8:54 AM
>> To: Marcus Müller; 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
>> [discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org] on behalf of
>> Marcus Müller [marcus.muel...@ettus.com]
>> Sent: Tuesday, April 28, 2015 1:38 AM
>> To: 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
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> 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
