Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Eric Blossom]

Thanks Dave,

Great ideas.

Eric


On Mon, Feb 26, 2007 at 05:32:19PM -0500, David I. Emery wrote:
> On Sun, Feb 25, 2007 at 03:56:07PM -0800, Eric Blossom wrote:
> > Would those of you with an interest in USRP inband signaling, please
> > take a look at the latest proposed packet format.  Now's a good time
> > to change things ;)
> 
>       I might have more comments later, but one function that would be
> very nice to have implemented in the FPGA/in band signaling code would
> be the ability to capture the count in the rolling 64 MHz counter on one
> edge (perhaps a  selectable edge selected by a bit in  a config register
> somewhere) of an external input signal available to the user via an IO
> pin and save that value in a register that could be read through the in
> band signaling mechanisms (or perhaps alternatively, automatically
> exported in the sample stream as a TIME_STAMP out of band message as
> soon as convenient after the edge happens).
> 
>       This would allow use of global tick signals such as 1 PPS from a
> GPSDO or GPS receiver to both synchronize a USRP sample stream (or
> streams from a cluster of multiple USRPs) to absolute (or at least
> global to a whole site) epochs in time, and for an accurate stable 1 PPS
> to be used to measure the moment to moment 64 MHz clock frequency offset
> allowing more or less auto-magical correction of all the various
> frequencies derived from this clock in the tune code and elsewhere.
> 
>       Of course a future, more advanced USRP might also include 
> provisions for locking the master clock (which has to be very very clean
> for optimum phase noise performance, particularly in aliased type
> sampling of higher than nyquist IFs and thus cannot all that easily be
> generated externally and piped around) to the universal standard 10 MHz
> reference frequency readily available from cheap and easily obtained
> GPSDOs.   At the very least providing an easy way of using a VCXO
> instead of just a cheap TCXO without cutting up the etch would help,
> even if the DAC and LPF required to sync it was external.
> 
> 
> -- 
>    Dave Emery N1PRE,  address@hidden  DIE Consulting, Weston, Mass 02493
> "An empty zombie mind with a forlorn barely readable weatherbeaten
> 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in 
> celebration of what could have been, but wasn't and is not to be now either."