RE: [Discuss-gnuradio] USRP2 PPS and REF

[Suprin, Charles E.]

Matt,

I had not seen your other post before I responded to the first one.  

How do you do a "receive at"?  Looking at 
usrp2/host/apps/include/usrp2/usrp2.h, the only function I see is 
start_rx_streaming which does not have a timestamp in it.

As for the sync_every_pps, if one is running two setup, physically separate, 
then the timestamps of the same time will agree if they both reset on separate 
GPS generated PPS's.  That way if one reboots or restarts the application, the 
time ambiguity is in units of seconds which can generally resolved with a NTP 
on the host computer.  

If I am missing something that could solve this more easily, let me know.

Charles


-----Original Message-----
From: Matt Ettus [mailto:address@hidden 
Sent: Friday, February 13, 2009 2:52 PM
To: Suprin, Charles E.
Cc: Douglas Geiger; address@hidden
Subject: Re: [Discuss-gnuradio] USRP2 PPS and REF

Suprin, Charles E. wrote:
> Doug,
> 
> Working only on my single channel setup, what appears to happen is
> that there is the time stamp for the first sample in the frame. The
> frame alignment seems to remain a function of when the device was
> turned on.


NO.  Frame alignment is under explicit control from the host, as long as 
you do a "receive at" request.  That will allow you to specify EXACTLY 
when you want your samples.  If you do a "receive now" request, which is 
what you're doing, you'll get samples starting right away, which will be 
a function of host computer latency.

> Now if sync_every_pps worked with the 31 December 2008 firmware.  I
> think I need to wait for a newer FPGA/VHDL firmware release for that
> to happen.


Honestly, sync_every_pps is a hack and I don't know why you would want 
it.  It causes you to not know what second it is, since the clock is 
reset every second.

The normal "sync at next pps" makes more sense.  Since all the 
oscillators are locked, you only need to sync once, and everyone will 
remain in sync forever.

Matt