VRT Branch: config_clock / PPS questions

GNU Radio
1

Hi,

I’ve finally had a bit of time to have a go with the VRT branch - I
noticed
with the rx_timed_samples example it’s now possible to start
rx_streaming at
a specific time so I’ve quickly merged my custom usrp2 timestamp source
block (gr-usrp2 - providing a second stream of timestamps - I dont think
the
vrt_header is available after this block at the moment).
I think I also need to add the python calls to the start_streaming_at
functionality.

As I havent got a scope around at the moment to check, am I correct in
thinking that the old config_mimo command to use the 10MHz Ref Input
needs
to be replaced with something like:

u=usrp2.source_32fc()

clock_settings=usrp2.clock_configt_t()
clock_settings.ref_source=clock_settings.REF_SMA
u.clock_config(clock_settings)

I’ve also noticed the set_time_at_next_pps() command, I’m assuming I can
use
this to force the usrp2 to set zero fractional seconds and some integer
(or
zero) number of seconds - this seems to be similar to what the
rx_timed_samples example is doing.

Is the PPS used after this to keep the integer seconds increment aligned
with the PPS?

Thanks in advance,

Tim

2

On 02/18/2010 12:27 PM, Tim P. wrote:

Hi,

I’ve finally had a bit of time to have a go with the VRT branch - I noticed
with the rx_timed_samples example it’s now possible to start rx_streaming at
a specific time so I’ve quickly merged my custom usrp2 timestamp source
block (gr-usrp2 - providing a second stream of timestamps - I dont think the
vrt_header is available after this block at the moment).
I think I also need to add the python calls to the start_streaming_at
functionality.

Cool. Yea, the python functionality is not in there.

If you wanted to pass the vrt header to the next block, then you have to
figure out how ot use this PMT stuff in gnuradio. Hmm…

As I havent got a scope around at the moment to check, am I correct in
thinking that the old config_mimo command to use the 10MHz Ref Input needs
to be replaced with something like:

u=usrp2.source_32fc()

clock_settings=usrp2.clock_configt_t()
clock_settings.ref_source=clock_settings.REF_SMA
u.clock_config(clock_settings)

The config mimo was replaced with a clock config call that takes a
struct of clock configuration arguments. Setting the PPS source, REF
source, and PPS polarity.

Im not sure what it looks like in python, but the above seems correct.

I’ve also noticed the set_time_at_next_pps() command, I’m assuming I can use
this to force the usrp2 to set zero fractional seconds and some integer (or
zero) number of seconds - this seems to be similar to what the
rx_timed_samples example is doing.

set_time_at_next_pps will latch in a new seconds and ticks when the next
pps pulse arrives. Because there is a race condition, I recommend using
this only in conjunction with something that can asynchronously message
your computer on a pps pulse (like a gps with a serial port).

Is the PPS used after this to keep the integer seconds increment aligned
with the PPS?

Nope. The pps call is a one time thing.

Once set, the integers seconds will continue to increment on their own
as the ticks rollover to zero after 100e6 counts. Your usrp2 should be
able to keep exact gps time without re-syncing provided that the 10mhz
ref is attached.

You could re-call set_time_at_next_pps every second. It shouldnt be
necessary unless you are worried about leap seconds.

-Josh