Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[Josh Blum]

On 01/04/2013 01:55 AM, LD Zhang wrote:
> Hello,
> 
>  
> 
> Thanks for the note below. 
> 
>  
> 
> I am reading an older email exchange between Josh Blum and a guest. Josh
> mentioned that there is a downstream block (in GRC I guess) that can use the
> timestamp tag to decide which samples are to be stored. Also there appears
> to be metadata utility to use. Maybe these magic functions such as stream
> tags (or) and get_time_last_pps to get the job done. So far I have used none
> of these utilities. My goal here is trying to avoid using the PPS if
> possible. Since the data gathering is done infrequently, I tend to think
> that the PPS can be avoided. I am trying not to use the PPS at least for
> this phase of the development. Yes for the next phase with enhanced
> capabilities, the external reference need will resurrect again. But it is
> better not to use the PPS right now, unless I am wrong here and need
> re-education of the USRP. The mimo cable is not an option since the 2 units
> are not co-located.
> 

If you want to use the PC clock, I recommend calling set time now with
the current PC time before scheduling streaming. This will make the USRP
tick counter roughly match the PC clock.

python:
usrp_source.set_time_now(uhd.time_spec_t(time.time())

c++
usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6));

This way, your only time-ambiguity is the variance in ethernet control
packets and the difference in time between the different PCs. That
should satisfy referenced to PC's time anyway...

--

The next step would be to schedule when a stream begins for each device
so they send RX samples to the host at the "same time" (according to the
USRP anyway).

I think the USRP source block supports setting the time, and streaming
at a specific time, but there isnt a way to do this at the GRC level. So
you might need some hand coded python added to the generated flowgraph,
if you are using GRC.


> 
> So is it possible to do the downstream block and metadata stream tags in GRC
> (currently using UHD source block and file sink block)?
> 
>  

The file sink does not save metadata, but I suspect you dont need to
save the metadata if you presumably have asked the devices to stream at
the same time.

-josh

> 
> Thanks very much,
> 
>  
> 
> LD
> 
>  
> 
> From: John Malsbury [mailto:john.malsb...@ettus.com] 
> Sent: Thursday, January 03, 2013 11:24 PM
> To: LD Zhang
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210
> samples with host computer system time?
> 
>  
> 
> You can get the synchronize two USRPs with an external reference or a USRP
> MIMO   cable, and specifying
> the time to start streaming for both.
> 
> -John
> 
> 
> 
> 
> On Thu, Jan 3, 2013 at 11:18 PM, LD Zhang  wrote:
> 
> Hi Folks,
> 
>  
> 
> We are testing 2 USRP N210 units with data gathering (using GRC source and
> file sink). The command from the host to the N210 is sent at the
> approximately simultaneous time (referenced to system NTP time). However,
> the samples gathered from the 2 units appear to differ by as much as 0.4-0.5
> seconds! The intention is to gather data at the 2 units at approximately the
> same time as the pre-programmed system time commands. The gathering is done
> with the top_block.py code generated from GRC. What happens inside the USRP
> appears to be beyond my control here. So the natural thing to do here is to
> time-stamp the samples with host computer system time. I hope that we don't
> have to use an external reference for the USRP. Isn't there an internal USRP
> clock that is continuously counting. If we can get the USRP clock counts to
> tie together the samples counts and the host computer system time, we would
> be in good shape. Is this a good idea? 
> 
>  
> 
> Your thoughts and help are appreciated.
> 
>  
> 
> LD Zhang
> 
> 
> ___
> 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

[Discuss-gnuradio] Minimal grc python block

[MJS]

Evening all. I only recently (yesterday) started working with gnuradio and am
having some trouble getting a minimal grc python block going. I've found a
number of references in this mailing list and elsewhere (and lots of broken
links) but just can't seem to piece it all together. Some guidance would be
greatly appreciated.

My current goal is just to create a block in grc, it doesn't even have to do
anything yet. Here's what I've done so far. I've added these to .bashrc:

export PYTHONPATH=$PYTHONPATH:/home/user/mygnuradioblocks
export GRC_BLOCKS_PATH=$GRC_BLOCKS_PATH:/home/user/mygnuradioblocks

As suggested by (I've tried the other two methods for specifying the .xml
path as well):

gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Adding-Custom-Blocks

And added the following two files to this folder (based on
https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide):

mytestblock.py
---

#!/usr/bin/env python

from gnuradio import gr
import block_gateway

class my_first_block(gr.block):
  def __init__(self):
gr.block.__init__(self, name = "my first block", in_sig=None,
out_sig=None)

  def work(self, input_items, output_items):
return 0

mytestblock.xml
-



MY: FIRST BLOCK
MY
my_first_block
import mytestblock as mtb
mtb.my_first_block()

my param1
my_param_1
False
bool
val_falseFalse
val_trueTrue


MY TEST BLOCK: Bleh, hope this works!



I however can't get grc to recognize this block, In addition I've tried
moving these two files to the system xml and py directories respectively:

/usr/local/share/gnuradio/grc/blocks/
/usr/local/lib/python2.7/dist-packages/gnuradio/extras/

And even modifying files in those two folders to a minimal form. In short,
I'm having a fairly hard time to get my first python grc block going, if
anyone could point me in the right direction for creating a minimal grc
python block it would be much appreciated.




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Minimal-grc-python-block-tp38838.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[LD Zhang]

Great! Thanks Josh for the answers to my last email. Please see my comments
and questions below.




If you want to use the PC clock, I recommend calling set time now with the
current PC time before scheduling streaming. This will make the USRP tick
counter roughly match the PC clock.

python:
usrp_source.set_time_now(uhd.time_spec_t(time.time())

c++
usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6));

This way, your only time-ambiguity is the variance in ethernet control
packets and the difference in time between the different PCs. That should
satisfy referenced to PC's time anyway...

>>> 
I will try it in Python to set the USRP time. My generated top_block.py is
doing as: self.uhd_usrp_source_0.set_...
I suppose I will just do:
self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time())

There is however a question of how often one needs to set the USRP time. It
would depend on how fast the USRP clock drifts with respect to host computer
system time. I remember a number of 2 ppm accuracy of the TCXO frequency
reference. How does this translate to rate of clock drift (in say
micro-seconds drift per hour)?

>>>

--

The next step would be to schedule when a stream begins for each device so
they send RX samples to the host at the "same time" (according to the USRP
anyway).

I think the USRP source block supports setting the time, and streaming at a
specific time, but there isnt a way to do this at the GRC level. So you
might need some hand coded python added to the generated flowgraph, if you
are using GRC.

>>>
OK, I want to do this. But what is the command to do in python? Something
like:
self.uhd_usrp_source_0.rx_sample_time??? Or .schedule_time??? 

I do need to pass the sample gather start time as a variable to the
top_block.py script.  How do I do that (I am a matlaber who is still clumsy
with python)?

Thanks and Regards,

LD

___
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

Re: [Discuss-gnuradio] Minimal grc python block

[MJS]

FYI I just solved the problem. The  and  tag order was
reversed. I didn't know that the xml format was so strict. Well on my way
now.

---

The blank lines in my xml data should have contained the  tags, they were
lost in copying the xml over for some reason.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Minimal-grc-python-block-tp38838p38840.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[Josh Blum]

On 01/04/2013 01:21 PM, LD Zhang wrote:
> Great! Thanks Josh for the answers to my last email. Please see my comments
> and questions below.
> 
> 
> 
> 
> If you want to use the PC clock, I recommend calling set time now with the
> current PC time before scheduling streaming. This will make the USRP tick
> counter roughly match the PC clock.
> 
> python:
> usrp_source.set_time_now(uhd.time_spec_t(time.time())
> 
> c++
> usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6));
> 
> This way, your only time-ambiguity is the variance in ethernet control
> packets and the difference in time between the different PCs. That should
> satisfy referenced to PC's time anyway...
> 

> I will try it in Python to set the USRP time. My generated top_block.py is
> doing as: self.uhd_usrp_source_0.set_...
> I suppose I will just do:
> self.uhd_usrp_source_0.set_time_now(uhd.time_spec_t(time.time())
> 
> There is however a question of how often one needs to set the USRP time. It
> would depend on how fast the USRP clock drifts with respect to host computer
> system time. I remember a number of 2 ppm accuracy of the TCXO frequency
> reference. How does this translate to rate of clock drift (in say
> micro-seconds drift per hour)?
> 

Doesnt really matter. The PC and USRP are on two different clocks with
very different drifts. You should probably just set the time again
before every acquisition. The ambiguity is probably going to be on the
order of several ms anyway.


> 
> --
> 
> The next step would be to schedule when a stream begins for each device so
> they send RX samples to the host at the "same time" (according to the USRP
> anyway).
> 
> I think the USRP source block supports setting the time, and streaming at a
> specific time, but there isnt a way to do this at the GRC level. So you
> might need some hand coded python added to the generated flowgraph, if you
> are using GRC.
> 

> OK, I want to do this. But what is the command to do in python? Something
> like:
> self.uhd_usrp_source_0.rx_sample_time??? Or .schedule_time??? 
> 


There is a set_start_time() call. setting this will effect what time the
streaming begins when the flow graph starts

Also, as an alternative, there is access to the issue_stream_cmd(). You
can leave the flow graph running and issue commands to turn streaming on
and off, schedule bursts, etc...

> I do need to pass the sample gather start time as a variable to the
> top_block.py script.  How do I do that (I am a matlaber who is still clumsy
> with python)?
> 

I guess you could just exec the python process to do a single
acquisition, write to file, close and return.

If you are messing w/ GRC, the parameter block will generate command
line options and top block constructor parameters for you.

-josh

> Thanks and Regards,
> 
> LD
> 
> ___
> 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

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[LD Zhang]

Hi Josh,

Thanks for replying. I have some thoughts on using the "set_start_time".
Please see my comments and questions  below:

=

There is a set_start_time() call. setting this will effect what time the
streaming begins when the flow graph starts

>>>
Once the set_time_now command is performed. I consider the USRP have the
same (or approximately the same) time as the host computer, correct?

The set_start_time() call looks nice, but it requires a time passed to it. I
currently don't know how to dynamically call the set_start_time() command
with a variable of system time in hour:min:sec.microsecond format. I found a
discussion a while ago on some problems with the set_start_time. Someone was
complaining that the time-out window in the cpp code is too short so a
future scheduled time did not work.

Thinking about what I need to achieve, the set_start_time command is
certainly good to make to work. But maybe I have an easier task here. Since
the time is already sync'd, and presuming that I can get the time tag of the
first sample, it is OK if the start time is off a bit(as long as it doesn't
jump around by more than 0.1 seconds each time I perform the same function),
all I need is to know the time of the start sample referenced to the host
system time. So I say all I need right now is to get the time tag of the
beginning sample and that would suffice, just to make it easier.

>>>

Also, as an alternative, there is access to the issue_stream_cmd(). You can
leave the flow graph running and issue commands to turn streaming on and
off, schedule bursts, etc...

>>>
I will try to make the previous approach to work before I mess with this
one.

LD


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[Josh Blum]

On 01/04/2013 03:15 PM, LD Zhang wrote:
> Hi Josh,
> 
> Thanks for replying. I have some thoughts on using the "set_start_time".
> Please see my comments and questions  below:
> 
> =
> 
> There is a set_start_time() call. setting this will effect what time the
> streaming begins when the flow graph starts
> 

> Once the set_time_now command is performed. I consider the USRP have the
> same (or approximately the same) time as the host computer, correct?
> 
> The set_start_time() call looks nice, but it requires a time passed to it. I
> currently don't know how to dynamically call the set_start_time() command
> with a variable of system time in hour:min:sec.microsecond format. I found a

You pass it a uhd.time_spec. SInce you are using the PC's time, there is
already something you may find convenient: uhd.time_spec.get_system_time()

http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html#a28bb1e25ad03f333078bea59d21b4854

> discussion a while ago on some problems with the set_start_time. Someone was
> complaining that the time-out window in the cpp code is too short so a
> future scheduled time did not work.

The timeout in the current implementation of uhd usrp source is no more.
The work function just keeps going, samples or no samples.

> 
> Thinking about what I need to achieve, the set_start_time command is
> certainly good to make to work. But maybe I have an easier task here. Since
> the time is already sync'd, and presuming that I can get the time tag of the
> first sample, it is OK if the start time is off a bit(as long as it doesn't
> jump around by more than 0.1 seconds each time I perform the same function),
> all I need is to know the time of the start sample referenced to the host
> system time. So I say all I need right now is to get the time tag of the
> beginning sample and that would suffice, just to make it easier.
> 

> 
> Also, as an alternative, there is access to the issue_stream_cmd(). You can
> leave the flow graph running and issue commands to turn streaming on and
> off, schedule bursts, etc...
> 

> I will try to make the previous approach to work before I mess with this
> one.
> 
> LD
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[LD Zhang]

You pass it a uhd.time_spec. SInce you are using the PC's time, there is
already something you may find convenient: uhd.time_spec.get_system_time()

>>>
Can you do this in python script that I have, or how you do this in python?

If not in python, then the easier thing for me to do may still be trying to
get the time of captured start sample of the data.

Please advise.

Thanks,


For your reference, I am pasting the python code I have:

class top_block(gr.top_block):

def __init__(self):
gr.top_block.__init__(self, "test_1")

##
# Variables
##
self.samp_rate = samp_rate = 1000

##
# Blocks
##
self.uhd_usrp_source_0 = uhd.usrp_source(
device_addr="",
stream_args=uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_source_0.set_subdev_spec("A:B", 0)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(0, 0)
self.uhd_usrp_source_0.set_gain(0, 0)
self.gr_skiphead_0 = gr.skiphead(gr.sizeof_gr_complex*1,
10240)
self.gr_head_0 = gr.head(gr.sizeof_gr_complex*1, 1000)
self.gr_file_sink_0 = gr.file_sink(gr.sizeof_gr_complex*1,
"sample_sink.dat")
self.gr_file_sink_0.set_unbuffered(True)

##
# Connections
##
self.connect((self.gr_head_0, 0), (self.gr_file_sink_0, 0))
self.connect((self.uhd_usrp_source_0, 0),
(self.gr_skiphead_0, 0))
self.connect((self.gr_skiphead_0, 0), (self.gr_head_0, 0))

def get_samp_rate(self):
return self.samp_rate

def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)

if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog:
[options]")
(options, args) = parser.parse_args()
tb = top_block()
tb.run()




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] New Features in 3.6.3

[Roy Thompson]

I am starting to play around with 3.6.3rc0 a little bit.  I'm excited
about the new message passing infrastructure and the Python-based
signal processing blocks.  In fact, I would really like to be able to
create Python-based blocks that use the new message infrastructure.
However, as best I can tell this is not currently possible since the
message_port_xxx functions are not being exposed to Python.  Is that
accurate?  If so, are there any plans to marry them together in the
future?

Thanks,
Roy

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[LD Zhang]

Hello,

I tried the following command in python:

> python:
> usrp_source.set_time_now(uhd.time_spec_t(time.time())
> 

It doesn't seem to work. Looks like the "time.time()" is wrong? Looked up an
earlier example:

set_time_now(uhd::time_spec_t(0.0), 0)

The syntax looks different. But this may be doing something different from
my intention which is to sync the USRP time to the host system time. I am
still searching for the right syntax for this command. Any help is
appreciated.

LD
 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[Marcus D. Leech]

On 01/04/2013 07:03 PM, LD Zhang wrote:

Hello,

I tried the following command in python:


python:
usrp_source.set_time_now(uhd.time_spec_t(time.time())


It doesn't seem to work. Looks like the "time.time()" is wrong? Looked up an
earlier example:

set_time_now(uhd::time_spec_t(0.0), 0)

The syntax looks different. But this may be doing something different from
my intention which is to sync the USRP time to the host system time. I am
still searching for the right syntax for this command. Any help is
appreciated.

LD



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



You'll have to put an:

import time

In your python



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Delete a reference to PMT - GRextras

[Jose Torres Diaz]

Hi Community,

I'm working with blob manager to implement our design. The block diagram in
GRExtras looks similar to this:

BLOCK 1 --> BLOCK 2 --> BLOCK 3 --> SINK

Where, Block 1 contains the manager as follows:

MsgBlobManager = pmt::pmt_mgr::make();
  for (size_t i = 0; i < MSG_BLOBS_ALLOCATION; i++)
  {

MsgBlobManager->set(pmt::pmt_make_blob(BLOB_MSG_INITIAL_SIZE));
  }


However, when I made some changes in the blob that is passing around in
BLOCK 2 (only 1 field of the blob), in BLOCK 3 I received the old data from
BLOCK 1. This happens exactly 3 times until BLOCK 3 received the correct
updated data.

I'm not sure if it is related due to previous blocks are keeping a
reference to the incoming message (as explained in
https://github.com/guruofquality/grextras/wiki#wiki-pmt-manager-object).
What I do not know either is the following:

"Normally, a PMT is created and passed to a downstream consumer. When all
downstream consumers delete their references to the PMT, the object is
deconstructed and freed back into nothingness"

1. How the downstream consumer delete their reference to a PMT object?
2. Is it automatically done or should I explicitly do this?

Thanks for your time and advice,

Regards,

Jose.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] sending single tone Am modulated using usrp1+wbx

[Marcus D. Leech]

On 01/04/2013 08:24 PM, José María Valencia wrote:


Hi, I want to transmitand receivea1kHz cosinetoneusing dsb am 
modulation and usrp1 with2wbx dbs,I have connectedfromtx/rx output  
wbx-ato rx2 inputwbx-b with a 50ohmsma cable, I'mexpectingin scope 
sinkthe cosine tone with 1KHz butI have another signal, can you tell 
me what could be the error?


I'm based on the complex envelope theory:   I=Ac(1+m(t))Q=0

You can see the diagram and the signals onthe attached image.

Thanks.



<<...>>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

So, did you use an attenuator, or did you connect directly?

I suggest that you put in a 30dB attenuator in-line, and carefully 
adjust both the TX and RX gain until you see the spectral component you 
need.


Connecting a transmitter directly to a receiver (whether it's a USRP or 
any other piece of radio equipment) is generally a bad idea -- there's a 
*strong*
  risk of damaging the front-end of the receiver.  More so when the 
receiver (such as with WBX) has a low-noise front-end.  So, when you're 
doing
  laboratory "loopback" tests, you use an attenuator.  The WBX receiver 
is easily capable of "seeing" extremely weak narrowband signals, so there's
  no reason not to put in a fair amount of attenuation and experiment 
with gain levels on both the RX and TX side.






--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I capture of the time of USRP N210 samples with host computer system time?

[LD Zhang]

Great! Thanks. I tried to import time and it works. Now I just have to see
if this is sufficient for my sample gather timing or I still have to get the
timestamp of the first sample using metadata and such.

LD

-Original Message-
From: Marcus D. Leech [mailto:mle...@ripnet.com] 
Sent: Friday, January 04, 2013 4:15 PM
To: LD Zhang; Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How do I capture of the time of USRP N210
samples with host computer system time?

On 01/04/2013 07:03 PM, LD Zhang wrote:
> Hello,
>
> I tried the following command in python:
>
>> python:
>> usrp_source.set_time_now(uhd.time_spec_t(time.time())
>>
> It doesn't seem to work. Looks like the "time.time()" is wrong? Looked 
> up an earlier example:
>
> set_time_now(uhd::time_spec_t(0.0), 0)
>
> The syntax looks different. But this may be doing something different 
> from my intention which is to sync the USRP time to the host system 
> time. I am still searching for the right syntax for this command. Any 
> help is appreciated.
>
> LD
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
You'll have to put an:

import time

In your python



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio