Re: [Discuss-gnuradio] Re: synchronizing sound cards in a cluster

[Dave Emery]

On Thu, Mar 13, 2003 at 09:23:23PM -0800, Eric Blossom wrote:
> On Thu, Mar 13, 2003 at 10:19:21PM -0500, Dave Emery wrote:
> > On Thu, Mar 13, 2003 at 03:50:02PM -0800, Steve Schear wrote:
> > > 
> > > Does the upcoming USB 2.0 card have a master/slave clock locker?  Might 
> > > be 
> > > nice for multiple card systems.
> > > 
> > > steve
> > 
> >     As I have said in another post, I think that there are two
> > related features that would be most useful.
> > 
> >     1.  External trigger input (and ideally also output allowing
> > multiple cards to be slaved to each other without needed an external
> > source of sample clock)).
> > 
> >     2.  Some provision for using an external standard frequency
> > reference to generate sample timing, thus allowing highly accurate
> > GPS time and frequency to be used for precise sampling where 
> > one cares about exact sample frequency.   Accepting a 10 mhz industry
> > standard reference frequency here would be ideal.
> 
> I should probably let Matt answer this, but... 
> 
> If you want to run the converters at full speed, I don't think you're
> going to get external trigger:
> 
>   (1) The on board oscillator is 120 MHz.  Clock jitter needs to be
>       held to single digit picoseconds for us to be able to
>       successfully IF sample.
> 

        Absolutely.   I was thinking you were going after something
somewhat slower.   But yes, you do need a low jitter clock to work
with IF sampling and narrow bandwidth signals.

        It sure would be nice to be able to use a 120 mhz 
high stability xtal vco which could be narrow loop bandwidth phase
locked to a 10 mhz reference.   This kind of technology is widely
used now in synthesizers for critical phase noise applications like
microwave spectrum analyzer LOs where the phase noise (and jitter)
is primarily that of the hf xtal VCO outside of the loop bandwidth
which can be made rather narrow.



>   (2) If we were to accept a 10 MHz timing reference, we'd need to
>       multiply it a bunch of times, and then get the jitter worked
>       out of it.  Not easy to do.

        I realize that cost is the big killer here.   Again I'm not
talking about directly using a harmonic of a supplied 10 mhz but 
extremely narrowband phase locking of a 120 mhz high stability xtal VCO
to the 10 mhz reference.   This can be done with a straightforward PLL I
should think.   I know there are 120 mhz region low jitter canned xtal
clock oscillators with frequency control inputs around and the rest is
very straightforward.

        Presumably you'd want to ground the frequency control input if
there was no 10 mhz reference available - and how much worse the VXCO
jitter might be because it had a varactor in the crystal oscillator
circuit is something I'd honestly have to ask a vendor - my guess would
be not too much, but I'd defer to someone more current on that kind of
problem.  It of course relates directly to phase noise and the Alan
variance of the timing from the VXCO and in particular the effect of the
varactor on crystal Q.

        And with a 10 mhz reference the quality of the 120 mhz clock
would depend on low phase noise from the 10 mhz inside the loop bandwith.
That of course is typical of a good grade 10 mhz OXCO references, but
not just any noisy crappy 10 mhz will do.

        I'd settle reluctantly for at least providing some kind of
support in the etch for using a canned  120 mhz VXCO with the rest of
the phase lock loop an optional higher cost option not always stuffed.

> 
> On the other hand, if you want to sample substantially slower than 60
> MHz, it's probably possible to get what you want.  There will be i/o
> pins brought out directly from the FPGA to connectors on the board
> edge.  You are free to define the guts of the FPGA.  It's an SRAM
> based device and it's configuration bitstream is loaded at runtime by
> by GNU Radio through the driver.  This implies that you get to control
> the clocks of the A/D's.  As I recall, the D/A's are driven directly
> from the oscillator, so you'd need to implement your timing on them by
> selecting which samples of the 120MS/s are the ones you want.
> 

        Yep, as you explain the architecture this becomes abundantly
clear.

        And yes I know that if one implements a NCO for a downconverter
and decimatator in the FPGA one can probably calibrate the thing by
somehow externally determining the 120 mhz oscillator error and
adjusting for it in the computation of the NCO phase accumulator
increment values.  But there are still advantages to having the
120 mhz clock spot on...


> 
> A quick review of the specs of the board:
> 
>   2 or 4   120 MS/second D/A's
>   2 or 4   60 MS/second A/D's
>   200K or 300K gate FPGA
>   USB 2 interface
> 
> Whether there are two or four analog ins and outs mostly depends on
> price.  The number of bits of the A/D's and D/A's depends on their
> number.  We're pin limited on the FPGA.  Fewer converters, more bits.
> Stay tuned for further details as they become available...

        Any idea at all of SFDR or where your intermodulation floor
might be with any of the chips being considered ?   And any idea
of what the analog front end might look like (AGC ?  Signal levels ?)

        And will there be Gnu VHDL or equivalent open source tool chains
for the FPGA available or how will those who don't want to just use
the canned versions of the FPGA code get access to low cost tools 
to develop their own code ?    (I know there are ASPs around that
might be helpful for this - but will there be a truly low cost version...
tools for FPGAs are often very pricey ...).


> 
> Eric

-- 
        Dave Emery N1PRE,  address@hidden  DIE Consulting, Weston, Mass. 
PGP fingerprint = 2047/4D7B08D1 DE 6E E1 CC 1F 1D 96 E2  5D 27 BD B0 24 88 C3 18