On 02/07/2012 03:12 AM, Hal Murray wrote:
mag...@rubidium.dyndns.org said:
Not quite right. If you lock up the clock, you do not lock to the birds,
but to GPS time or UTC as received over GPS. The observed time of the birds
would be a bad solution since you can't see a particular bird contino
mag...@rubidium.dyndns.org said:
> Not quite right. If you lock up the clock, you do not lock to the birds,
> but to GPS time or UTC as received over GPS. The observed time of the birds
> would be a bad solution since you can't see a particular bird continously
> unless you is in geosync orbit.
And then all that can be done is lock the oscillator to a solution derived
from the birds... this can explain why a receiver can fail to correctly
lock an oscillator or give a strange PPS. That is, it is possible, in case
of errors, to have, for example, a PPS displaced by 1mS but state that the
s
On 02/02/2012 10:13 AM, Azelio Boriani wrote:
OK, got it: no need to lock the receiver clock to birds to get stable data
(e.g. Oncore+Cs) but the clock can be locked to birds to get even better
data and obtain "for free" a reference clock (TBolt). The use of a stable
clock (not locked to birds) f
#x27;Discussion of precise time and frequency measurement'
Reply-To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] FE-.5680A trimming resolution
If anyone is interested, I have just got hold of a PDF of the Technical Manual
TM 5680-0211 for 5680A serie
OK, got it: no need to lock the receiver clock to birds to get stable data
(e.g. Oncore+Cs) but the clock can be locked to birds to get even better
data and obtain "for free" a reference clock (TBolt). The use of a stable
clock (not locked to birds) feeding the receiver can show the various
errors
On Thu, 02 Feb 2012 00:50:39 +0100
Magnus Danielson wrote:
> > I have not seen any such papers yet. Do you have any pointers or hints
> > what to search for?
>
> Let me see... yes, here it is:
>
> http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA497270
Thanks!
Printed and ready to be read :-)
On 02/02/12 01:17, Azelio Boriani wrote:
In my opinion the work done locking the VCTCXO of the Oncore is different
from the TBolt OCXO management: the TBolt steers the OCXO based on the
received signal instead they locked the Oncore oscillator to a Cs
reference. Yes, if all the world is the same
In my opinion the work done locking the VCTCXO of the Oncore is different
from the TBolt OCXO management: the TBolt steers the OCXO based on the
received signal instead they locked the Oncore oscillator to a Cs
reference. Yes, if all the world is the same then there is no difference:
the Cs locks t
On 01/02/12 15:07, John Ackermann N8UR wrote:
There've been numerous threads on the Gnuradio mailing list about code
to receive GPS using the Ettus Research USRP hardware. I don't know
whether anyone has actually made it work, but it appears that it's been
the subject of quite a few academic proj
On 01/02/12 10:25, Attila Kinali wrote:
On Wed, 01 Feb 2012 01:52:16 +0100
Magnus Danielson wrote:
On 31/01/12 20:43, Attila Kinali wrote:
On Tue, 31 Jan 2012 18:50:08 +0100
b...@lysator.liu.se wrote:
Exactly that _is_ the appeal of the Tbolts.
Yes, but can this be replicated with a stan
There've been numerous threads on the Gnuradio mailing list about code
to receive GPS using the Ettus Research USRP hardware. I don't know
whether anyone has actually made it work, but it appears that it's been
the subject of quite a few academic projects.
John
On 2/1/2012 4:28 AM, Atti
Yes. If you look up old papers, they already did this with Oncores,
Cesium clocks and synthesis.
I have not seen any such papers yet. Do you have any pointers or hints
what to search for?
Attila,
I don't have a link either. I would look at the usual T&F web sources:
PTTI, NIST, FCS, EFTF, ION
I have opened the FTS125: the fixed OCXO 20MHz is fed using the EXT_CLK pin
7 on the CW25. Maybe it is possible to drive a CW12 with an external high
quality 20MHz but maybe a suitable firmware is then needed.
On Wed, Feb 1, 2012 at 10:28 AM, Attila Kinali wrote:
> On Tue, 31 Jan 2012 16:21:40 -
On Tue, 31 Jan 2012 16:21:40 -0800
"Tom Van Baak" wrote:
> We're waiting for some brave soul to implement an SDR-based
> GPS timing receiver; we can all then experiment with the TBolt
> model instead of the TIC/DAC model of GPSDO.
I'm planning that... I don't think it's too difficult to do, give
On Wed, 01 Feb 2012 01:52:16 +0100
Magnus Danielson wrote:
> On 31/01/12 20:43, Attila Kinali wrote:
> > On Tue, 31 Jan 2012 18:50:08 +0100
> > b...@lysator.liu.se wrote:
> >> Exactly that _is_ the appeal of the Tbolts.
> >
> > Yes, but can this be replicated with a standard GPS module?
>
> Yes
On Tue, 31 Jan 2012 15:27:45 -0800
Chris Albertson wrote:
> On Tue, Jan 31, 2012 at 11:43 AM, Attila Kinali wrote:
>
> >
> > My current progress is that the uC i wanted to use does not
> > do what i want. Can anyone recommend a uC with 32bit timers
> > and IEEE 1588 support?
>
> Does the syste
On Tue, 31 Jan 2012 21:19:50 + (UTC)
cfo wrote:
>
> You want these for the MCU
> http://www.st.com/internet/mcu/product/252140.jsp
Thanks! The links worked... Dunno why using the webpage does not...
Maybe some strange interferance with my firefox version and their
javascript stuff...
The S
On 31/01/12 22:14, Rob Kimberley wrote:
If anyone is interested, I have just got hold of a PDF of the Technical Manual
TM 5680-0211 for 5680A series Rubidiums.
Please contact me off list for a copy (1M, so too large to post on
time-nuts@febo.com)
I'll have it.
The russian version is here:
ht
On 31/01/12 20:43, Attila Kinali wrote:
On Tue, 31 Jan 2012 18:50:08 +0100
b...@lysator.liu.se wrote:
Let's say, i'm building a GPSDO with a high quality OCXO.
Wouldnt it then make sense to lock the reference clock of the GPS
receiver also to that OCXO?
Attila Kinali
> We're waiting for some brave soul to implement an SDR-based
> GPS timing receiver; we can all then experiment with the TBolt
> model instead of the TIC/DAC model of GPSDO.
There are several projects that do this.
There is one written using GNU Radio. I forget the details but I saw
it years ago
Let's say, i'm building a GPSDO with a high quality OCXO.
Wouldnt it then make sense to lock the reference clock of the GPS
receiver also to that OCXO?
Attila Kinali
It's a design decision. Most GPSDO sold are made by companies
that buy an OEM GPS timing receiver and then create a GPSDO
with th
Rob, I would be happy to put it on one of my web pages so people could
download it.
On Wed, Feb 1, 2012 at 8:14 AM, Rob Kimberley
wrote:
> If anyone is interested, I have just got hold of a PDF of the Technical
> Manual TM 5680-0211 for 5680A series Rubidiums.
> Please contact me off list for a c
On Tue, Jan 31, 2012 at 11:43 AM, Attila Kinali wrote:
>
> My current progress is that the uC i wanted to use does not
> do what i want. Can anyone recommend a uC with 32bit timers
> and IEEE 1588 support?
Does the system need to be small? If not Generic PC hardware can
work. Buy an Intel "Ato
On Tue, Jan 31, 2012 at 9:40 AM, Attila Kinali wrote:
> Let's say, i'm building a GPSDO with a high quality OCXO.
> Wouldnt it then make sense to lock the reference clock of the GPS
> receiver also to that OCXO?
Yes, I see. That is exactly what Trimble does in the Thunderbolt.
There is only one
The Navsync FTS125 is an example where the GPS receiver engine (the CW25)
is driven by a 20MHz fixed OCXO. At the moment I don't know if the CW25 of
the FTS125 has a specific firmware for that but I suspect that it must be
so. In my opinion it is best to have a tunable OCXO (like the TBolt) to
have
On Tue, 31 Jan 2012 21:47:15 +0100, Attila Kinali wrote:
> STM32-F2/F4 (ST): ST doesn't want to give me the documentation to those.
> (website fails w/o error message)
I have no probs with the ST site (Discovery-F4)
http://www.st.com/internet/evalboard/product/252419.jsp
You want these for the
El 31/01/2012 21:47, Attila Kinali escribió:
This was exactly the device i intended to use.
But it doesnt really have 32bit timers. They cascade two 16bit timers
to get 32bit, but then all kind of restrictions apply which make the
timers unusable. And when using 16bit timers, i'll get an overfl
-nuts-boun...@febo.com] On Behalf
Of Attila Kinali
Sent: 31 January 2012 20:47
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] FE-.5680A trimming resolution
On Tue, 31 Jan 2012 21:06:04 +0100
Javier Herrero wrote:
> El 31/01/2012 20:43, Attila Kinali escr
In message ,
"Don Latham" writes:
>>> > want. Can anyone recommend a uC with 32bit timers and IEEE 1588
An suitable motherboard and an intel 82599 based ethernet card ?
The latter will set you back approx $700, but $1000 should get you far
in total.
The 82599 has some very interesting time-nut
If you are willing to use external counters:
Dallas DS2423 Dual 32-bit Counter
Or, if you have an unlimited budget:
http://www.cwcelectronicsystems.com/dual32ct_modulario.html
the word "defense" is prominent here :-).
Or counter products from: http://www.lsicsi.com/
I use encoder interfaces from t
On Tue, 31 Jan 2012 21:06:04 +0100
Javier Herrero wrote:
> El 31/01/2012 20:43, Attila Kinali escribió:
> > My current progress is that the uC i wanted to use does not do what i
> > want. Can anyone recommend a uC with 32bit timers and IEEE 1588 support?
> You can have a look on these
> http:/
On Tue, 31 Jan 2012 20:43:35 +0100, Attila Kinali wrote:
> My current progress is that the uC i wanted to use does not do what i
> want. Can anyone recommend a uC with 32bit timers and IEEE 1588 support?
>
Some of the ST's supports IEEE-1588
http://www.embeddedstar.com/weblog/2011/09/21/stm32-f4
El 31/01/2012 20:43, Attila Kinali escribió:
My current progress is that the uC i wanted to use does not do what i
want. Can anyone recommend a uC with 32bit timers and IEEE 1588 support?
You can have a look on these
http://www.ti.com/mcu/docs/mculuminaryfamilynode.tsp?sectionId=95&tabId=2597&f
On Tue, 31 Jan 2012 18:50:08 +0100
b...@lysator.liu.se wrote:
> > Let's say, i'm building a GPSDO with a high quality OCXO.
> > Wouldnt it then make sense to lock the reference clock of the GPS
> > receiver also to that OCXO?
> >
> > Attila Kinali
>
> Exactly that _is_ the app
> On Tue, 31 Jan 2012 09:32:22 -0800
> Chris Albertson wrote:
>
>> On Tue, Jan 31, 2012 at 7:52 AM, Attila Kinali wrote:
>>
>> > one could take a GPS module, like the LEA-6T
>> > and replace the TCXO they have with a VCXO that is phase locked
>> > to the 10MHz reference
>>
>> I'm trying t
On Tue, 31 Jan 2012 09:32:22 -0800
Chris Albertson wrote:
> On Tue, Jan 31, 2012 at 7:52 AM, Attila Kinali wrote:
>
> > one could take a GPS module, like the LEA-6T
> > and replace the TCXO they have with a VCXO that is phase locked
> > to the 10MHz reference
>
> I'm trying to figure o
On Tue, 31 Jan 2012 11:46:45 -0500 (EST)
ewkeh...@aol.com wrote:
> In a message dated 1/31/2012 10:53:22 A.M. Eastern Standard Time,
> att...@kinali.ch writes:
>
> > I just wonder, whether one could take a GPS module, like the LEA-6T
> > and replace the TCXO they have with a VCXO that is phas
On Tue, Jan 31, 2012 at 7:52 AM, Attila Kinali wrote:
> one could take a GPS module, like the LEA-6T
> and replace the TCXO they have with a VCXO that is phase locked
> to the 10MHz reference
I'm trying to figure out your goal. The above assumes one already
has a 10MHz reference.
Chr
What do you think you would gain from that. Does the LEA-6T have a TCXO?
Bert
In a message dated 1/31/2012 10:53:22 A.M. Eastern Standard Time,
att...@kinali.ch writes:
On Mon, 30 Jan 2012 17:47:54 +
Mark Sims wrote:
>
> The Tbolt does not have any sawtooth error or corrections.
On Mon, 30 Jan 2012 17:47:54 +
Mark Sims wrote:
>
> The Tbolt does not have any sawtooth error or corrections.
> Its' GPS receiver LO is generated from the 10 MHz oscillator.
> That's what makes it the best GPSDO out there.
I just wonder, whether one could take a GPS module, like the LEA-
Mark,
If you feel adventurous, my GPSMonitor (written in C for the 8051) source
code is available. Development tools including C compiler are free.
Didier KO4BB
On Mon, Jan 30, 2012 at 11:47 AM, Mark Sims wrote:
>
> The Tbolt does not have any sawtooth error or corrections. Its' GPS
> receiver
n the "SAS" plot and small
delta "signal strength blips" in the "SAD" plot due to multipath
cancellations.
ws
*
- Original Message -
From: "Chris Albertson"
To: "Discussion of precise time and frequency measurement"
Sent: M
On Mon, Jan 30, 2012 at 10:43 AM, Mark Sims wrote:
>
> These are 4-BYTE single precision floating point numbers, not 4 bit
> integers. They are the values plotted in the Lady Heather PPS and OSC
> graphs
Sorry I type faster than I think. You are right they can't be four bits.
I work in
These are 4-BYTE single precision floating point numbers, not 4 bit integers.
They are the values plotted in the Lady Heather PPS and OSC graphs (and used
in the "ADEV" calculations and plots (not actually true ADEV values since they
are not refereneced to an external reference, but still
On Mon, Jan 30, 2012 at 9:47 AM, Mark Sims wrote:
>
> The Tbolt does not have any sawtooth error or corrections. Its' GPS receiver
> LO is
> generated from the 10 MHz oscillator. That's what makes it the best GPSDO
> out there.
Inside "Packet 0x8F-AC" (supplemental timing packet) there are
The Tbolt does not have any sawtooth error or corrections. Its' GPS receiver
LO is generated from the 10 MHz oscillator. That's what makes it the best
GPSDO out there.
--
I'm also thinking of porting over much of the Lady Heather t-bolt monitoring
stuff to the Arduino.
On
Hi
It's the whole "unlock and relock thing that I was trying to get around. In any
PLL, the VCXO / VCO will need to pull a bit further than the lock range, just
to get things lined up. Testing this sort of thing can be a pain.
Bob
On Jan 30, 2012, at 2:20 AM, Javier Herrero wrote:
> Hello,
El 30/01/2012 03:19, Chris Albertson escribió:
On Sun, Jan 29, 2012 at 10:19 AM, Javier Herrero wrote:
El 29/01/2012 14:45, Bob Camp escribió:
My next intention is to replace the OCXO in one of my Thunderbolts with a Rb
and use a small microcontroller to get the voltage correction from the
Hello,
Also I expect that the range would be somewhat limited by the unit
software, since the control word is 32-bit, same as the DDS program word
with, and I don't think that the little thing would enable to program
the DDS from zero to 32-bit. In any case, my idea was first to only
monitor
On Sun, Jan 29, 2012 at 10:19 AM, Javier Herrero wrote:
> El 29/01/2012 14:45, Bob Camp escribió:
>
> My next intention is to replace the OCXO in one of my Thunderbolts with a Rb
> and use a small microcontroller to get the voltage correction from the
> Thunderbolt through the serial port and con
Hi
A roughly 30 second update rate makes a lot of sense. That would keep the
update steps buried in the short term stability "noise".
Good news on the serial update timing and it's stability. Sounds like you could
do several updates a second. That's plenty fast enough.
Bob
On Jan 29, 2012,
Hi
If you try to do full scale, check the range of your VCXO first. The digital
test is much easier if you already know where your VCXO stops tuning.
Bob
On Jan 29, 2012, at 1:45 PM, Javier Herrero wrote:
> I'm now gathering the unit self-updating of DDS data, that will take somewhat
> lon
I'm now gathering the unit self-updating of DDS data, that will take
somewhat long... so I will try later or tomorrow. Since we have seen
that the DDS values are reported back in a response to a command, it is
easy to do without the need to have anything hooked to the SPI bus :)
Regards,
Javi
At 05:45 AM 1/29/2012, Javier Herrero wrote:
For example, the following data has been gathered:
Serial offset 00 00 00 00
DDS A word: 44 02 62 F6 = 1141007094 = 5 313 228.32219 Hz
DDS B word: 43 FD CC 8E = 1140706446 = 5 311 828.32085 Hz
Can you do a test at +/- fullscale offset as well?
Thi
El 29/01/2012 14:45, Bob Camp escribió:
Hi
Very interesting.
It sounds like dithering would be needed to get down to parts in 10^-14. If we
do that from an external device (PC / PIC / FPGA / whatever) it would be useful
to know the delay between the serial command and the DDS update. The more
Hi
Yes, I think the dither would just be a minor routine running on what ever you
use to discipline the rubidium. Other than a disciplined environment I don't
see a lot of need for sub 7x10^-13 steps.
Bob
On Jan 29, 2012, at 9:12 AM, Magnus Danielson
wrote:
> On 01/29/2012 02:45 PM, Bob
On 01/29/2012 02:45 PM, Bob Camp wrote:
Hi
Very interesting.
It sounds like dithering would be needed to get down to parts in 10^-14. If we
do that from an external device (PC / PIC / FPGA / whatever) it would be useful
to know the delay between the serial command and the DDS update. The more
Hi
That is indeed an odd update rate. The short term stability of the FE-5680 is
in the parts in 10^-13 range once you get past 100 seconds. I would think
updates of a DDS lsb or more would mess up the stability.
Of course if it is temperature correction, it may still be in the noise.
Bob
O
Hi
Very interesting.
It sounds like dithering would be needed to get down to parts in 10^-14. If we
do that from an external device (PC / PIC / FPGA / whatever) it would be useful
to know the delay between the serial command and the DDS update. The more
variable the delay, the less accurate t
El 29/01/2012 13:57, Magnus Danielson escribió:
Hi Javier,
On 01/29/2012 12:45 PM, Javier Herrero wrote:
Hello,
As it has been discussed in the past days, the architecture of the newer
FE-5680A that has been recently purchased by a lot of us does not led to
a trimming resolution through the se
Hi Javier,
On 01/29/2012 12:45 PM, Javier Herrero wrote:
Hello,
As it has been discussed in the past days, the architecture of the newer
FE-5680A that has been recently purchased by a lot of us does not led to
a trimming resolution through the serial port of 1.7854e-7Hz, but rather
leds to thin
Wow, good work, a very fine reverse engineering attempt.
On Sun, Jan 29, 2012 at 12:45 PM, Javier Herrero wrote:
> Hello,
>
> As it has been discussed in the past days, the architecture of the newer
> FE-5680A that has been recently purchased by a lot of us does not led to a
> trimming resolution
Hello,
As it has been discussed in the past days, the architecture of the newer
FE-5680A that has been recently purchased by a lot of us does not led to
a trimming resolution through the serial port of 1.7854e-7Hz, but rather
leds to think that the trimming resolution is in fact 6.80789e-6Hz
64 matches
Mail list logo
