Re: [Discuss-gnuradio] Re: New external clock board for USRP

[Jason]

Alexander Chemeris wrote:
> Hi all,
>
> As I wrote in my previous mail, we're working on an universal clock
> source for USRP (and not only for USRP). It is based on 0.28ppm TCXO
> from Connor Winfield [1], National Semiconductor LMX2531 VCO+PLL [2]
> and LMK01000 CD [3] for clock generation and Atmel ATUSB for control.
> So far we've finished PCB design and working on production of the first
> 25 units. We'll reserve 5 of them for our own use and testing of
> different options, 8 others are requested by community people, so there
> are more then 10 left for sale. We plan to finish production at
> the beginning of Dec and take units to 26C3. If you plan to attend it,
> you have a great chance to see them, play with them and take some of
> them with you. ;)

Awesome!  I don't think I'll be able to swing 26C3, though.

> As we promised, units form this experimental batch will be sold out
> for only $100 or 66EUR (without shipping). We kindly invite everyone
> interested in such unit to get one and try fitting it to your setup.
> Also we need your help determining the best feature set for the unit
> (read on for the ample list of possible features). We aim at creating
> a really flexible and cheap clocking unit, which may used by a broad
> GnuRadio community and will best fit its needs. Unit with open source
> software and open hardware.

Can you post the preliminary pcb/gerber/asm files?  Are you using 
geda/pcb, by chance?

> Now, lets get to facts. Board dimensions are 86x44mm (3.4" x 1.7") -
> it is designed to work inside of USRP box with RFX boards installed
> with no external connections.
>
> Default distribution version includes:
> 1) Clock board with default options
> 2) U.FL to SMA cable to connect to USRP
> 3) Power cable to connect to USRP's fan connector
>
> Default board options:
[snip]
> 12) 1pps external signal may be used to tame the clock to external
> GPS unit. It will be passed to ATMega's interrupt input, so you
> should keep in mind that this will need a lot of software work for filtering
> out jitter, generated by it. We don't plan to develop this software at
> least now, but anyone who need this is welcome to take it.

This would be interesting.

thx,

Jason.