New external clock board for USRP

[Alexander Chemeris]

Hi all,

We're creating a clocking unit which will be easy to use with
USRP. If there will be enough interest from the community we
can order some amount of PCBs and put them for sale alone or
soldered and ready to use. This should be useful for everyone
trying to run OpenBTS, working with GPS and everyone else
who need to re-clock their USRP or have more clock precision.

We've created it to run USRP at 52MHz with 0.3-0.5ppm after
calibrating or 1ppm in long term without recalibrating, but actually
it will support 2.84-65.83MHz, 65.91-71.82MHz, 72.5-79MHz clock
ranges with about the same precision.

Power will be taken from USRP 6V, clock output will be SMA to
connect to USRP directly. Frequency control will be accessible
over RS-232 (aka COM-port) with simple text-based protocol. We're
going to use ATMega for this. Ideally we want tighter integration
with USRP, so it can be controlled via the same USB connection,
so you can control clocks right from GnuRadio. But to date we can't
figure out how to do this cleanly. All suggestions are welcome.

We're testing it with USRP1, but I guess it should work fine for
USRP2 too.

Estimated overall cost (including all components needed to connect
it to USRP) will be about 100$.

Please, drop me a letter if you're interested and how much units
would you buy.

--
Regards,
Alexander Chemeris.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[David I. Emery]

On Fri, Sep 25, 2009 at 12:00:34AM +0400, Alexander Chemeris wrote:
> Power will be taken from USRP 6V, clock output will be SMA to
> connect to USRP directly. Frequency control will be accessible
> over RS-232 (aka COM-port) with simple text-based protocol. We're
> going to use ATMega for this. Ideally we want tighter integration
> with USRP, so it can be controlled via the same USB connection,
> so you can control clocks right from GnuRadio. But to date we can't
> figure out how to do this cleanly. All suggestions are welcome.

        Have you any sense of how much additional phase noise - sampling
clock jitter - the ATMega will introduce compared to the TXCO Matt uses ?
This impacts SNR... especially with  higher nyquist n subsampling.

--
  Dave Emery N1PRE/AE, die@...  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."



_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Matt Ettus]

Alexander Chemeris wrote:

> Hi all,
>
> We're creating a clocking unit which will be easy to use with
> USRP. If there will be enough interest from the community we
> can order some amount of PCBs and put them for sale alone or
> soldered and ready to use. This should be useful for everyone
> trying to run OpenBTS, working with GPS and everyone else
> who need to re-clock their USRP or have more clock precision.
>
> We've created it to run USRP at 52MHz with 0.3-0.5ppm after
> calibrating or 1ppm in long term without recalibrating, but actually
> it will support 2.84-65.83MHz, 65.91-71.82MHz, 72.5-79MHz clock
> ranges with about the same precision.

I don't know what part you are planning to use for this, but it looks
like a tunable oscillator, which is likely to have a lot of jitter.  To
avoid problems, you would need something with less than 1 picosecond of
jitter.  The crystal on there now has about 250 femtoseconds of jitter.

I would strongly suggest that you use a plain old tcxo, and pick a part
which is available in many different frequencies.  This would result in
a much cleaner output, and much less complexity.

Matt


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

On Fri, Sep 25, 2009 at 04:36, David I. Emery <die@...> wrote:

> On Fri, Sep 25, 2009 at 12:00:34AM +0400, Alexander Chemeris wrote:
>> Power will be taken from USRP 6V, clock output will be SMA to
>> connect to USRP directly. Frequency control will be accessible
>> over RS-232 (aka COM-port) with simple text-based protocol. We're
>> going to use ATMega for this. Ideally we want tighter integration
>> with USRP, so it can be controlled via the same USB connection,
>> so you can control clocks right from GnuRadio. But to date we can't
>> figure out how to do this cleanly. All suggestions are welcome.
>
>        Have you any sense of how much additional phase noise - sampling
> clock jitter - the ATMega will introduce compared to the TXCO Matt uses ?
> This impacts SNR... especially with  higher nyquist n subsampling.

We don't use ATMega for clock generation, it's used to control precise
generator and as interface to PC only.

--
Regards,
Alexander Chemeris.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

Hi Matt,

On Fri, Sep 25, 2009 at 05:20, Matt Ettus <matt@...> wrote:

> Alexander Chemeris wrote:
>> We're creating a clocking unit which will be easy to use with
>> USRP. If there will be enough interest from the community we
>> can order some amount of PCBs and put them for sale alone or
>> soldered and ready to use. This should be useful for everyone
>> trying to run OpenBTS, working with GPS and everyone else
>> who need to re-clock their USRP or have more clock precision.
>>
>> We've created it to run USRP at 52MHz with 0.3-0.5ppm after
>> calibrating or 1ppm in long term without recalibrating, but actually
>> it will support 2.84-65.83MHz, 65.91-71.82MHz, 72.5-79MHz clock
>> ranges with about the same precision.
>
> I don't know what part you are planning to use for this, but it looks like a
> tunable oscillator, which is likely to have a lot of jitter.  To avoid
> problems, you would need something with less than 1 picosecond of jitter.
>  The crystal on there now has about 250 femtoseconds of jitter.
>
> I would strongly suggest that you use a plain old tcxo, and pick a part
> which is available in many different frequencies.  This would result in a
> much cleaner output, and much less complexity.

Thank you for your input. Our unit is based on low-noise National's VCO+PLL
sourced from precise reference generator. Of course, all phase noises are taken
into account. I need to check with my collaborator who're actually doing this
work to get exact numbers. I'll post them here a bit later.

--
Regards,
Alexander Chemeris.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Tim Pearce-2]

In terms of integrating more tightly with the USRP/GnuRadio

You could (maybe) just use the SPI pins and one of the digital IO lines as the enable (the ATMega8 running as a slave)

That way theres functions to communicate with the chip already built in you just need to define the various commands etc?

Tim.

On Sun, Sep 27, 2009 at 9:53 PM, Alexander Chemeris <alexander.chemeris@...> wrote:

Hi Matt,

On Fri, Sep 25, 2009 at 05:20, Matt Ettus <matt@...> wrote:
> Alexander Chemeris wrote:
>> We're creating a clocking unit which will be easy to use with
>> USRP. If there will be enough interest from the community we
>> can order some amount of PCBs and put them for sale alone or
>> soldered and ready to use. This should be useful for everyone
>> trying to run OpenBTS, working with GPS and everyone else
>> who need to re-clock their USRP or have more clock precision.
>>
>> We've created it to run USRP at 52MHz with 0.3-0.5ppm after
>> calibrating or 1ppm in long term without recalibrating, but actually
>> it will support 2.84-65.83MHz, 65.91-71.82MHz, 72.5-79MHz clock
>> ranges with about the same precision.
>
> I don't know what part you are planning to use for this, but it looks like a
> tunable oscillator, which is likely to have a lot of jitter.  To avoid
> problems, you would need something with less than 1 picosecond of jitter.
>  The crystal on there now has about 250 femtoseconds of jitter.
>
> I would strongly suggest that you use a plain old tcxo, and pick a part
> which is available in many different frequencies.  This would result in a
> much cleaner output, and much less complexity.

Thank you for your input. Our unit is based on low-noise National's VCO+PLL
sourced from precise reference generator. Of course, all phase noises are taken
into account. I need to check with my collaborator who're actually doing this
work to get exact numbers. I'll post them here a bit later.

--
Regards,
Alexander Chemeris.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[David Burgess-4]

One of the approaches we are considering for OpenBTS is to use a VCTCXO with the control voltage taken from one of the D/A outputs of the FPGA, with LOTS of low-pass filtering, of course.

This would not give a wide range of frequencies, but would allow precise frequency calibration through the existing libusrp APIs.

On Sep 28, 2009, at 9:00 AM, Tim Pearce wrote:

In terms of integrating more tightly with the USRP/GnuRadio

You could (maybe) just use the SPI pins and one of the digital IO lines as the enable (the ATMega8 running as a slave)

That way theres functions to communicate with the chip already built in you just need to define the various commands etc? 

Tim.

David A. Burgess

Kestrel Signal Processing, Inc.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

Yes, connecting to SPI is an interesting option. We'll consider looking at it.
Is there any documentation for this bus available?

On Mon, Sep 28, 2009 at 20:00, Tim Pearce <timothy.pearce@...> wrote:

> In terms of integrating more tightly with the USRP/GnuRadio
>
> You could (maybe) just use the SPI pins and one of the digital IO lines as
> the enable (the ATMega8 running as a slave)
>
> That way theres functions to communicate with the chip already built in you
> just need to define the various commands etc?
>
> Tim.
>
> On Sun, Sep 27, 2009 at 9:53 PM, Alexander Chemeris
> <alexander.chemeris@...> wrote:
>>
>> Hi Matt,
>>
>> On Fri, Sep 25, 2009 at 05:20, Matt Ettus <matt@...> wrote:
>> > Alexander Chemeris wrote:
>> >> We're creating a clocking unit which will be easy to use with
>> >> USRP. If there will be enough interest from the community we
>> >> can order some amount of PCBs and put them for sale alone or
>> >> soldered and ready to use. This should be useful for everyone
>> >> trying to run OpenBTS, working with GPS and everyone else
>> >> who need to re-clock their USRP or have more clock precision.
>> >>
>> >> We've created it to run USRP at 52MHz with 0.3-0.5ppm after
>> >> calibrating or 1ppm in long term without recalibrating, but actually
>> >> it will support 2.84-65.83MHz, 65.91-71.82MHz, 72.5-79MHz clock
>> >> ranges with about the same precision.
>> >
>> > I don't know what part you are planning to use for this, but it looks
>> > like a
>> > tunable oscillator, which is likely to have a lot of jitter.  To avoid
>> > problems, you would need something with less than 1 picosecond of
>> > jitter.
>> >  The crystal on there now has about 250 femtoseconds of jitter.
>> >
>> > I would strongly suggest that you use a plain old tcxo, and pick a part
>> > which is available in many different frequencies.  This would result in
>> > a
>> > much cleaner output, and much less complexity.
>>
>> Thank you for your input. Our unit is based on low-noise National's
>> VCO+PLL
>> sourced from precise reference generator. Of course, all phase noises are
>> taken
>> into account. I need to check with my collaborator who're actually doing
>> this
>> work to get exact numbers. I'll post them here a bit later.
>>
>> --
>> Regards,
>> Alexander Chemeris.
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@...
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: [phone]


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

Hi David,

Could you elaborate why do you consider this approach? While we see some
advantages of it in terms of lower noise, it looks like our approach
is few times
cheaper with reasonable noise and stability figure. If we understood correctly,
bare VCTCXO chip costs $230 on DigiKey, while in our case discrete unit with
all accessories produced in low volume costs about $100.

On Mon, Sep 28, 2009 at 22:06, David Burgess <dburgess@...> wrote:

> One of the approaches we are considering for OpenBTS is to use a VCTCXO with
> the control voltage taken from one of the D/A outputs of the FPGA, with LOTS
> of low-pass filtering, of course.
> This would not give a wide range of frequencies, but would allow precise
> frequency calibration through the existing libusrp APIs.
>
> On Sep 28, 2009, at 9:00 AM, Tim Pearce wrote:
>
> In terms of integrating more tightly with the USRP/GnuRadio
>
> You could (maybe) just use the SPI pins and one of the digital IO lines as
> the enable (the ATMega8 running as a slave)
>
> That way theres functions to communicate with the chip already built in you
> just need to define the various commands etc?
>
> Tim.
>
>
> David A. Burgess
> Kestrel Signal Processing, Inc.
>
>
>
>

--
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: [phone]


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[David Burgess-4]

Alexander -

We expect to be able to get VCTCXOs in modest volumes for less than  
$30.  The TCXO we are using now is $23.  Most of the cost of the  
clock doubler board is the labor for getting it assembled locally in  
small batches.

When/if the FPGA firmware gets fixed, we can use a 26 MHz part  
without a doubler, which would reduce the cost further.

-- David


On Sep 29, 2009, at 2:02 AM, Alexander Chemeris wrote:

> Hi David,
>
> Could you elaborate why do you consider this approach? While we see  
> some
> advantages of it in terms of lower noise, it looks like our approach
> is few times
> cheaper with reasonable noise and stability figure. If we  
> understood correctly,
> bare VCTCXO chip costs $230 on DigiKey, while in our case discrete  
> unit with
> all accessories produced in low volume costs about $100.
>
> On Mon, Sep 28, 2009 at 22:06, David Burgess  
> <dburgess@...> wrote:
>> One of the approaches we are considering for OpenBTS is to use a  
>> VCTCXO with
>> the control voltage taken from one of the D/A outputs of the FPGA,  
>> with LOTS
>> of low-pass filtering, of course.
>> This would not give a wide range of frequencies, but would allow  
>> precise
>> frequency calibration through the existing libusrp APIs.
>>
>> On Sep 28, 2009, at 9:00 AM, Tim Pearce wrote:
>>
>> In terms of integrating more tightly with the USRP/GnuRadio
>>
>> You could (maybe) just use the SPI pins and one of the digital IO  
>> lines as
>> the enable (the ATMega8 running as a slave)
>>
>> That way theres functions to communicate with the chip already  
>> built in you
>> just need to define the various commands etc?
>>
>> Tim.
>>
>>
>> David A. Burgess
>> Kestrel Signal Processing, Inc.
>>
>>
>>
>>
>
>
>
> --
> Regards,
> Alexander Chemeris.
>
> SIPez LLC.
> SIP VoIP, IM and Presence Consulting
> http://www.SIPez.com
> tel: [phone]

David A. Burgess
Kestrel Signal Processing, Inc.






_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

On Mon, Sep 28, 2009 at 00:53, Alexander Chemeris
<alexander.chemeris@...> wrote:

> On Fri, Sep 25, 2009 at 05:20, Matt Ettus <matt@...> wrote:
>> Alexander Chemeris wrote:
>>> We're creating a clocking unit which will be easy to use with
>>> USRP. If there will be enough interest from the community we
>>> can order some amount of PCBs and put them for sale alone or
>>> soldered and ready to use. This should be useful for everyone
>>> trying to run OpenBTS, working with GPS and everyone else
>>> who need to re-clock their USRP or have more clock precision.
>>>
>>> We've created it to run USRP at 52MHz with 0.3-0.5ppm after
>>> calibrating or 1ppm in long term without recalibrating, but actually
>>> it will support 2.84-65.83MHz, 65.91-71.82MHz, 72.5-79MHz clock
>>> ranges with about the same precision.
>>
>> I don't know what part you are planning to use for this, but it looks like a
>> tunable oscillator, which is likely to have a lot of jitter.  To avoid
>> problems, you would need something with less than 1 picosecond of jitter.
>>  The crystal on there now has about 250 femtoseconds of jitter.
>>
>> I would strongly suggest that you use a plain old tcxo, and pick a part
>> which is available in many different frequencies.  This would result in a
>> much cleaner output, and much less complexity.
>
> Thank you for your input. Our unit is based on low-noise National's VCO+PLL
> sourced from precise reference generator. Of course, all phase noises are taken
> into account. I need to check with my collaborator who're actually doing this
> work to get exact numbers. I'll post them here a bit later.

Well, my workmate is very tentative in estimates and says he needs to finish
the unit design to calculate meaningful numbers. And there are still not enough
interest from people, so finishing design is somewhat low priority for us now.

Yet I have to say that our prototype works perfectly with OpenBTS - all phones
we were able to test with works as expected and calls does not drop even after
half an hour of talking. "kal" utility says our clock's jitter is
+-70Hz relative to
our closest BS clocks, which is +-0.08ppm and is well about measurement
error level.

In our prototype we use LMX2531 VCO+PLL with CW648-ND 10MHz TCXO,
but in final design this may change.

--
Regards,
Alexander Chemeris.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

David,

Do you have any specific VCTCXO model in mind?

On Tue, Sep 29, 2009 at 22:16, David Burgess <dburgess@...> wrote:

> We expect to be able to get VCTCXOs in modest volumes for less than $30.
>  The TCXO we are using now is $23.  Most of the cost of the clock doubler
> board is the labor for getting it assembled locally in small batches.
>
> When/if the FPGA firmware gets fixed, we can use a 26 MHz part without a
> doubler, which would reduce the cost further.
>
> -- David
>
>
> On Sep 29, 2009, at 2:02 AM, Alexander Chemeris wrote:
>
>> Hi David,
>>
>> Could you elaborate why do you consider this approach? While we see some
>> advantages of it in terms of lower noise, it looks like our approach
>> is few times
>> cheaper with reasonable noise and stability figure. If we understood
>> correctly,
>> bare VCTCXO chip costs $230 on DigiKey, while in our case discrete unit
>> with
>> all accessories produced in low volume costs about $100.
>>
>> On Mon, Sep 28, 2009 at 22:06, David Burgess <dburgess@...>
>> wrote:
>>>
>>> One of the approaches we are considering for OpenBTS is to use a VCTCXO
>>> with
>>> the control voltage taken from one of the D/A outputs of the FPGA, with
>>> LOTS
>>> of low-pass filtering, of course.
>>> This would not give a wide range of frequencies, but would allow precise
>>> frequency calibration through the existing libusrp APIs.
>>>
>>> On Sep 28, 2009, at 9:00 AM, Tim Pearce wrote:
>>>
>>> In terms of integrating more tightly with the USRP/GnuRadio
>>>
>>> You could (maybe) just use the SPI pins and one of the digital IO lines
>>> as
>>> the enable (the ATMega8 running as a slave)
>>>
>>> That way theres functions to communicate with the chip already built in
>>> you
>>> just need to define the various commands etc?
>>>
>>> Tim.
>>>
>>>
>>> David A. Burgess
>>> Kestrel Signal Processing, Inc.
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Regards,
>> Alexander Chemeris.
>>
>> SIPez LLC.
>> SIP VoIP, IM and Presence Consulting
>> http://www.SIPez.com
>> tel: [phone]
>
>
> David A. Burgess
> Kestrel Signal Processing, Inc.
>
>
>
>
>

--
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: [phone]


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

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. ;)

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.

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:
1) Control from miniUSB or 16-pin connector on USRP daughter boards.
It will be possible to write a GNURadio block to control clocks right
from GNURadio flowgraph!
2) Power from 2-pin connector for connecting to USRP fan power
connector and 2-pin pass-throw to connect fan to. That is board is
connected between USRP and fan.
3) One U.FL clock output with ability to generate frequency in the main
range 2.84-65.83MHz, and additional ranges 65.91-71.82MHz,
72.5-79MHz, and more ranges higher with <=0.44Hz step. Output
levels are CMOS. This means that you can tune your clock precisely
ti whatever frequency you want.
4) Initial frequency calibration 1ppm, temperature stability 0.28ppm,
holdover stability over 24h 0.32ppm [1]. Clock jitter will be measured
when first units arrive to us, I'll post measurement results here.

Pretty simple and flexible isn't it? But what makes this clock unit really
universal is a set of available options. You may solder them by yourself
or request ready-to-use units from us - I will make some notes on price
changes and options compatibility below, mail me for details if you're
interested in particular configuration. We want to be as flexible as
possible to fulfill community need in flexible clock source.

So, basic additional options include:
1) Power may be taken from 2-pin connector, 6V jack input or from USB.
All power options are mutually exclusive.
2) COM-port with RS-232 levels for clock control. This will add about 3.5$
to the price.
3) Up to 5 more additional U.FL outputs (6 outputs altogether), which
share VCO frequency, but may be independently divided in clock
distributor. 5 additional connectors will add 8-9$ to the price.
4*) Output levels may be (a) 4 LVPECL (or CMOS) outputs and 2 LVDS
outputs, (b) 6 LVPECL (or CMOS) outputs, (c) 6 LVDS outputs.
5) SMA connector may be soldered instead of one of U.FL with CMOS
levels. It will add 4.5$ to the price.
6) SMA connector with direct VCO output bypassing clock distributor.
It will add 4.5$ to the price.
7) SMA connector for external clock source. This way onboard
oscillator should be disabled by resistors soldering or should not be
present. It will add 4.5$ to the price.
8*) Oscillator could be changed to 0.5ppm. This will save you 7.5$.
9*) VCO+PLL with clock divider could be changed to clock divider
and multiplier. In this case you won't be able to tune your clock
precisely, but you'll be able to generate, e.g. 13MHz, 26MHz and 62MHz
from a single oscillator.
10*) Frequency range could be extended to 1.87-94.75MHz (and more
ranges higher) at the price of more phase noise.
11*) For nerds only - unit may be used without onboard controller by
direct access to VCO+PLL pins. But this is roughly equivalent to
a VCO starter kit and obviously is not compatible with features like
SPI/USB/RS232 control, and can't be used with power from USRP.
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.

* These options is not immediately available because of changes in
components list. Some options need testing before we can offer units
with them. Some options available for small orders, some available
only for volume orders. And sure, you can solder them by yourself.
Mail me for details, if you're interested.

There are two big options, which touches a big part of the unit and are
very much experimental. We can't guarantee that they will work,
but we think they will. :)
* TCXO with VCO+PLL could be replaced with VCTCXO with DAC.
DAC can be 12-bit linear or 16-bit delta-sigma. This will make it
about 20$ cheaper then default bundle if we produce it in volume.
The downside of this is that frequency range is much smaller and
more calibration is needed.
* GPS chip could be actually installed right on board to provide
1pps signal. PCB is designed to be used with cheap EB230 GPS
Module and will add about 40$ to the price. But there are some small
limitations - you can't use RS232 output with it, only 5 output channels
are possible. Same notes on software as for 1pps input applies.

We're working on detailed documentation and will make it available
as soon as possible.

1. http://www.conwin.com/datasheets/tx/tx236.pdf
2. http://www.national.com/ds/LM/LMX2531LQ1515E.pdf
3. http://www.national.com/ds/LM/LMK01000.pdf

--
Regards,
Alexander Chemeris.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Jason-99]

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.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

On Tue, Oct 20, 2009 at 18:29, Jason <gnuradio@...> wrote:

> Alexander Chemeris wrote:
>> 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?

We will setup a website for the project and will put sources and schematics
there. To date software is in embryo stage - we were busy placing unit
into production to get it before 26C3. We plan to get back to it soon and
will publish it then.

>> 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.

You're welcome to get the unit and hack this ;)


--
Regards,
Alexander Chemeris.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Alexander Chemeris]

Hi all,

Status update - PCBs for the first batch are ready and we'll start populating
soon. To date we're on time! :)
See some PCB pictures here:
http://openbts.chemeris.ru/2009/10/universal-clocking-unit-for-usrp-pcbs-are-ready/
Only when you hold it in hands, you realize how small and densely populated
it is for all its features.

On Tue, Oct 20, 2009 at 01:31, Alexander Chemeris
<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. ;)
>
> 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.
>
> 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:
> 1) Control from miniUSB or 16-pin connector on USRP daughter boards.
> It will be possible to write a GNURadio block to control clocks right
> from GNURadio flowgraph!
> 2) Power from 2-pin connector for connecting to USRP fan power
> connector and 2-pin pass-throw to connect fan to. That is board is
> connected between USRP and fan.
> 3) One U.FL clock output with ability to generate frequency in the main
> range 2.84-65.83MHz, and additional ranges 65.91-71.82MHz,
> 72.5-79MHz, and more ranges higher with <=0.44Hz step. Output
> levels are CMOS. This means that you can tune your clock precisely
> ti whatever frequency you want.
> 4) Initial frequency calibration 1ppm, temperature stability 0.28ppm,
> holdover stability over 24h 0.32ppm [1]. Clock jitter will be measured
> when first units arrive to us, I'll post measurement results here.
>
> Pretty simple and flexible isn't it? But what makes this clock unit really
> universal is a set of available options. You may solder them by yourself
> or request ready-to-use units from us - I will make some notes on price
> changes and options compatibility below, mail me for details if you're
> interested in particular configuration. We want to be as flexible as
> possible to fulfill community need in flexible clock source.
>
> So, basic additional options include:
> 1) Power may be taken from 2-pin connector, 6V jack input or from USB.
> All power options are mutually exclusive.
> 2) COM-port with RS-232 levels for clock control. This will add about 3.5$
> to the price.
> 3) Up to 5 more additional U.FL outputs (6 outputs altogether), which
> share VCO frequency, but may be independently divided in clock
> distributor. 5 additional connectors will add 8-9$ to the price.
> 4*) Output levels may be (a) 4 LVPECL (or CMOS) outputs and 2 LVDS
> outputs, (b) 6 LVPECL (or CMOS) outputs, (c) 6 LVDS outputs.
> 5) SMA connector may be soldered instead of one of U.FL with CMOS
> levels. It will add 4.5$ to the price.
> 6) SMA connector with direct VCO output bypassing clock distributor.
> It will add 4.5$ to the price.
> 7) SMA connector for external clock source. This way onboard
> oscillator should be disabled by resistors soldering or should not be
> present. It will add 4.5$ to the price.
> 8*) Oscillator could be changed to 0.5ppm. This will save you 7.5$.
> 9*) VCO+PLL with clock divider could be changed to clock divider
> and multiplier. In this case you won't be able to tune your clock
> precisely, but you'll be able to generate, e.g. 13MHz, 26MHz and 62MHz
> from a single oscillator.
> 10*) Frequency range could be extended to 1.87-94.75MHz (and more
> ranges higher) at the price of more phase noise.
> 11*) For nerds only - unit may be used without onboard controller by
> direct access to VCO+PLL pins. But this is roughly equivalent to
> a VCO starter kit and obviously is not compatible with features like
> SPI/USB/RS232 control, and can't be used with power from USRP.
> 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.
>
> * These options is not immediately available because of changes in
> components list. Some options need testing before we can offer units
> with them. Some options available for small orders, some available
> only for volume orders. And sure, you can solder them by yourself.
> Mail me for details, if you're interested.
>
> There are two big options, which touches a big part of the unit and are
> very much experimental. We can't guarantee that they will work,
> but we think they will. :)
> * TCXO with VCO+PLL could be replaced with VCTCXO with DAC.
> DAC can be 12-bit linear or 16-bit delta-sigma. This will make it
> about 20$ cheaper then default bundle if we produce it in volume.
> The downside of this is that frequency range is much smaller and
> more calibration is needed.
> * GPS chip could be actually installed right on board to provide
> 1pps signal. PCB is designed to be used with cheap EB230 GPS
> Module and will add about 40$ to the price. But there are some small
> limitations - you can't use RS232 output with it, only 5 output channels
> are possible. Same notes on software as for 1pps input applies.
>
> We're working on detailed documentation and will make it available
> as soon as possible.
>
> 1. http://www.conwin.com/datasheets/tx/tx236.pdf
> 2. http://www.national.com/ds/LM/LMX2531LQ1515E.pdf
> 3. http://www.national.com/ds/LM/LMK01000.pdf
>
> --
> Regards,
> Alexander Chemeris.
>

--
Regards,
Alexander Chemeris.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio