Re: [time-nuts] First success with very simple, very low cost GPSDO

[WarrenS]

Magnus wrote


It may appear so, but the derivate, scale-factor F and integrate does not
make the scale-factor F equalent to P, since you are forgetting that the
derivate removes the DC term


We don't quite agree on that point yet.
I can not find anything different or special that your code example is doing 
"at it's output",

It seems to produce the exact same results as a standard PI controller.
Also in your code and all PI code the FLL function you talk about is 
provided by the P term, Don't need to add the derivate, scale-factor F and 
integrate term.


The derivate & integrate function could remove (or change) the signal's 
offset if it was coded to do so,
But in your code, DC offset removal is not shown, so it would appear that 
**no**  DC offset is being removed.
The DC Offset that is removed depends on what value that Vdp_pre is 
initialize to, before the first cycle thru the code.
If Vdp_pre and Vi are both initialized to zero then there is no offset 
removed,
and derivate, scale-factor_F then integrate exactally equals the same as 
scale-factor_F only.
If vdp_pre is initalized to the first input value Vdp(0) instead of zero, as 
is often the case, then the offset removed would be scale-factor_F x Vdp(0)


either way the code (with Vdp_pre & Vi pre-initialized to zero)


Vdf = Vdp - Vdp_pre
Vdp_pre = Vdp
Vi = Vi + I*Vdp + F*Vdf
Vf = Vi + P*Vdp



appears to produces the exact same output as the simpler code:
(when Vi is initalized to zero)

Vi = Vi +  (I * Vdp)  ;
Vf = Vi + (P+F) * Vdp

(To add offset removal, Initialize Vi to - F * First_Vdp_reading )

Also get same results from: (where Dc  =  0)
or for offset removal set Dc  to F*First_Vdp_reading

Vi = Vi +  (I * Vdp)
Vf = Vi + (P+F) * Vdp -  Dc



F and P is not equivalents, as P will not contribute to the state of
Vi, which is evident in the weak pull-in of a standard PI loop


We're going to have to disagree on that also.
The output is the sum of the P term and the I term, You end up with the 
exact same results if you take something away from one of then and apply it 
to the other.

That is what my two code examples are doing.
If you want faster pull in just increase the product of F*P, it does not 
matter which, They both give the same exact results for DC and AC.


Tom, do you want to program Gpsim1 to break this standoff?

ws

*
Warren,

On 12/04/14 21:09, WarrenS wrote:

Magnus

Interesting, Am I missing something or is there an error in your code or
logic.

Looks to me like the code is a PI controller with a added "D" term
(Vdf) of input,
and the "D" is then Integrated with a scale factor of "F" at  Vi = Vi +
F*Vdf ...
An integrated derivative is exactly equal to a P


I may appear so, but the derivate, scale-factor F and integrate does not
make the scale-factor F equalent to P, since you are forgetting that the
derivate removes the DC term and the integration forms it's own DC term.
This DC-term as scaled through oscillator gain and added to the
oscillators offset is then subtracted from the reference frequency and
thus the error frequency is input to the integrator stage.

The FLL variant model can be understood if the differentiation is pushed
to both inputs of the phase comparator, where the reference frequency
and oscillators frequency will be subtracted rather than their phase and
the only remaining integrator in the loop is that holding the Vi term.
The frequency error term will exponentially decay with the time-constant
as set by the F coefficient.

So, F and P is not equivalents, as P will not contribute to the state of
Vi, which is evident in the weak pull-in of a standard PI loop.

However, F and P will for the AC behaviour of the loop be equivalents,
so care must be taken into setting P with regard to F in order to get
the expected damping of the loop.

Anyway, this is a FLL-aided PI-loop, which looks like an incorrectly
wired PID-loop. Quite minimalistic.


Looks to me like the code is still just a standard PI controller where
Vdp is the phase error;
Vi = Vi + I*Vdp
Vf = Vi + (P+F) * Vdp

This can be simplified by dropping the F scale factor and increasing the
P a little

What am I missing?


I think I covered that above.


One thing for sure that the code is missing is a pre-filter, which is
very helpful because of the GPS phase noise.


It is missing a whole deal, but I wanted to illustrate the core.
One thing which is not covered is the un-wrapping of the phase detector
in the case that it does not wrap around binary. Another thing, the
frequency detector phase history may need to be unwrapped prior to
subtraction in order to make sure the frequency estimate becomes correct.


Turning on the "D" term in a PID with a prefilter is mostly not
recommended, They tend to just cancel each other.


I avoided the "D" coefficient name as it will be confusing to a normal
PID naming, when it will in fact does not do the normal "D".

Cheers,
Magnus 


___
tim

Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8

[Tom Miller]

Your oscillator is on its way. I set it right on 10. MHz against a 
GPSDRb house standard. You will get a better waveform out if it sees about a 
100 - 200 ohm termination, though the edge is nice and sharp with some 
peaking overshoot.


You might get a bit more stability if you can add to the thermal insulation 
around the oscillator. Also, consider using the internal reference output on 
the pin marked n/c. It runs near 4.0 volts and is stable to ambient temp 
changes. Maybe put the whole thing in a Styrofoam container that has about 
one inch wall thickness.


Regards,
Tom



- Original Message - 
From: "Chris Albertson" 
To: "Discussion of precise time and frequency measurement" 
; "Magnus Danielson" 

Sent: Sunday, April 13, 2014 12:30 AM
Subject: Re: [time-nuts] First success with very simple, very low cost 
GPSDO, under $8




On Sat, Apr 12, 2014 at 9:48 AM, Magnus Danielson <
mag...@rubidium.dyndns.org> wrote:



In fact a 5 bit counter is enough, and then a '373 to sample it. The
enable to the 373 needs to be synchronous to the 5/10 MHz clock, so a 
pair

of DFFs ('74) is needed to synchronize the PPS and another pair to create
the single cycle enable.



It turns out all of this is built into the AVR chip.   There is a counter
and logic to copy the current counter value to a register on a PPS pulse
raising edge.The counter keeps running and every second its value is
trapped.

I can connect the OCXO and the PPS directly to the AVR pin.  The AVR has
hardware (a fast comparator) to "square" a low amplitude sine wave and 
trap
the counter on a zero crossing.   So it looks like I can get rid of  ALL 
of

the external chips.   The built in DAC is working well also but it needs
some external resisters and caps.

No need for '74 FFs or '373' or counter chips.I do get precision 
timing

with no time critical software, no 74xxx chips.


--
Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to 
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there. 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8

[Chris Albertson]

On Sat, Apr 12, 2014 at 9:48 AM, Magnus Danielson <
mag...@rubidium.dyndns.org> wrote:

>
> In fact a 5 bit counter is enough, and then a '373 to sample it. The
> enable to the 373 needs to be synchronous to the 5/10 MHz clock, so a pair
> of DFFs ('74) is needed to synchronize the PPS and another pair to create
> the single cycle enable.
>
>
It turns out all of this is built into the AVR chip.   There is a counter
and logic to copy the current counter value to a register on a PPS pulse
raising edge.The counter keeps running and every second its value is
trapped.

I can connect the OCXO and the PPS directly to the AVR pin.  The AVR has
hardware (a fast comparator) to "square" a low amplitude sine wave and trap
the counter on a zero crossing.   So it looks like I can get rid of  ALL of
the external chips.   The built in DAC is working well also but it needs
some external resisters and caps.

No need for '74 FFs or '373' or counter chips.I do get precision timing
with no time critical software, no 74xxx chips.


--
Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First success with very simple, very low cost GPSDO

[WarrenS]

Magnus

I think all three below provide the exact same results.
If true, That may not be doing what you wanted.

ws



Vi = Vi +  (I * Vdp)  ; Initial Vi value =  - F * First_Vdp_reading)
Vf = Vi + (P+F) * Vdp


? same as:


Vi = Vi +  (I * Vdp)
Vf = Vi + (P+F) * Vdp -  Offset;(where Offset  =  F * 
First_Vdp_reading)



? same as:


Vdf = Vdp - Vdp_pre
Vdp_pre = Vdp
Vi = Vi + I*Vdp + F*Vdf
Vf = Vi + P*Vdp



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First success with very simple, very low cost GPSDO

[WarrenS]

Magnus

I think this is close to the exact equivalent code under all conditions and 
includes the DC offset term that is removed.

If I'm right, it may not be doing exactly what you want it to be doing.

Vi = Vi +  (I * Vdp)
Vf = Vi + (P+F) * Vdp -  Offset;(where Offset  =  F * First_Vdp_reading)

ws

*

- Original Message - 
From: "WarrenS" 
To: "Discussion of precise time and frequency measurement" 


Sent: Saturday, April 12, 2014 5:10 PM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO




Magnus

Thanks, even more interesting, I'll give it a try after I figger out under 
what conditions it should help.


You are right, I did not fully take into account the DC offset that is 
removed.
That is because it  happens only once on the very first pass the code 
loop.
Any effect that may have, goes away forever after the control loop's TC 
settling time has passed and the VI term has had time to add the removed 
DC offset back in.


Assuming there is no clipping going on, a D * I is exactly the same as a P 
with one exception, as you pointed out.
It also removes a DC offset that is equal to the very first value read. 
(but this only happens once at the first pass in the code)

So D * I == P - offset;  where Offset == the first Vdp reading.

After I term has had time to replace first Vdp reading's "offset" that was 
removed, the D * I term's effect is back to the exact same effect as an P 
term for ever more.
So does the code depend on the first Vdp error reading to contain some 
valid and useful value other than zero,
Are you suggesting this only works once during turn on and it's effects 
only apply over the loops TC time period?
(if so sounds unpredictable at best, If not I still don't know how it 
works)


I can see a few possible initial conditions that could happen: Does the 
code depend on a specific one of these to occur?
#1 the loop is started before there is any Vdp phase error, in which case 
the D * I term will == P, No removed offset, therefore no effect on 
anything but the P gain.


#2 the loop is started after the VdP error is stable, valid and non zero, 
in which case the D * I term will == P minus a fixed offset


#3 the loop is started when the Vdp error input is not yet stabilized or 
still invalid in which case the D x I term will ==P minus some random 
number (not sure that can be depended to help anything)


In any case looks to me like the code is still mostly a standard PI 
controller ,  at least after the code has been running long enough to 
settle on the Loop's TC. After that,  I can not see any further useful 
effect.

Same long term effect, Not quite the same effect short term.

Vi = Vi +  (I * Vdp)  ; Initial Vi value =  F*First_Vdp_reading)
Vf = Vi + (P+F) * Vdp

ws


Magnus Danielson wrote

Warren,
On 12/04/14 21:09, WarrenS wrote:

Magnus

Interesting, Am I missing something or is there an error in your code or
logic.

Looks to me like the code is a PI controller with a added "D" term
(Vdf) of input,
and the "D" is then Integrated with a scale factor of "F" at  Vi = Vi +
F*Vdf ...
An integrated derivative is exactly equal to a P


I may appear so, but the derivate, scale-factor F and integrate does not
make the scale-factor F equalent to P, since you are forgetting that the
derivate removes the DC term and the integration forms it's own DC term.
This DC-term as scaled through oscillator gain and added to the
oscillators offset is then subtracted from the reference frequency and
thus the error frequency is input to the integrator stage.

The FLL variant model can be understood if the differentiation is pushed
to both inputs of the phase comparator, where the reference frequency
and oscillators frequency will be subtracted rather than their phase and
the only remaining integrator in the loop is that holding the Vi term.
The frequency error term will exponentially decay with the time-constant
as set by the F coefficient.

So, F and P is not equivalents, as P will not contribute to the state of
Vi, which is evident in the weak pull-in of a standard PI loop.

However, F and P will for the AC behaviour of the loop be equivalents,
so care must be taken into setting P with regard to F in order to get
the expected damping of the loop.

Anyway, this is a FLL-aided PI-loop, which looks like an incorrectly
wired PID-loop. Quite minimalistic.


Looks to me like the code is still just a standard PI controller where
Vdp is the phase error;
Vi = Vi + I*Vdp
Vf = Vi + (P+F) * Vdp

This can be simplified by dropping the F scale factor and increasing the
P a little

What am I missing?


I think I covered that above.


One thing for sure that the code is missing is a pre-filter, which is
very helpful because of the GPS phase noise.


It is missing a whole deal, but I wanted to illustrate the core.
One thing which is not covered is the un-wrapping of the phase detector
in the case that it does not w

Re: [time-nuts] First success with very simple, very low cost GPSDO

[WarrenS]

Magnus

Thanks, even more interesting, I'll give it a try after I figger out under 
what conditions it should help.


You are right, I did not fully take into account the DC offset that is 
removed.

That is because it  happens only once on the very first pass the code loop.
Any effect that may have, goes away forever after the control loop's TC 
settling time has passed and the VI term has had time to add the removed DC 
offset back in.


Assuming there is no clipping going on, a D * I is exactly the same as a P 
with one exception, as you pointed out.
It also removes a DC offset that is equal to the very first value read. (but 
this only happens once at the first pass in the code)

So D * I == P - offset;  where Offset == the first Vdp reading.

After I term has had time to replace first Vdp reading's "offset" that was 
removed, the D * I term's effect is back to the exact same effect as an P 
term for ever more.
So does the code depend on the first Vdp error reading to contain some valid 
and useful value other than zero,
Are you suggesting this only works once during turn on and it's effects only 
apply over the loops TC time period?

(if so sounds unpredictable at best, If not I still don't know how it works)

I can see a few possible initial conditions that could happen: Does the code 
depend on a specific one of these to occur?
#1 the loop is started before there is any Vdp phase error, in which case 
the D * I term will == P, No removed offset, therefore no effect on anything 
but the P gain.


#2 the loop is started after the VdP error is stable, valid and non zero, 
in which case the D * I term will == P minus a fixed offset


#3 the loop is started when the Vdp error input is not yet stabilized or 
still invalid in which case the D x I term will ==P minus some random number 
(not sure that can be depended to help anything)


In any case looks to me like the code is still mostly a standard PI 
controller ,  at least after the code has been running long enough to settle 
on the Loop's TC. After that,  I can not see any further useful effect.

Same long term effect, Not quite the same effect short term.

Vi = Vi +  (I * Vdp)  ; Initial Vi value =  F*First_Vdp_reading)
Vf = Vi + (P+F) * Vdp

ws


Magnus Danielson wrote

Warren,
On 12/04/14 21:09, WarrenS wrote:

Magnus

Interesting, Am I missing something or is there an error in your code or
logic.

Looks to me like the code is a PI controller with a added "D" term
(Vdf) of input,
and the "D" is then Integrated with a scale factor of "F" at  Vi = Vi +
F*Vdf ...
An integrated derivative is exactly equal to a P


I may appear so, but the derivate, scale-factor F and integrate does not
make the scale-factor F equalent to P, since you are forgetting that the
derivate removes the DC term and the integration forms it's own DC term.
This DC-term as scaled through oscillator gain and added to the
oscillators offset is then subtracted from the reference frequency and
thus the error frequency is input to the integrator stage.

The FLL variant model can be understood if the differentiation is pushed
to both inputs of the phase comparator, where the reference frequency
and oscillators frequency will be subtracted rather than their phase and
the only remaining integrator in the loop is that holding the Vi term.
The frequency error term will exponentially decay with the time-constant
as set by the F coefficient.

So, F and P is not equivalents, as P will not contribute to the state of
Vi, which is evident in the weak pull-in of a standard PI loop.

However, F and P will for the AC behaviour of the loop be equivalents,
so care must be taken into setting P with regard to F in order to get
the expected damping of the loop.

Anyway, this is a FLL-aided PI-loop, which looks like an incorrectly
wired PID-loop. Quite minimalistic.


Looks to me like the code is still just a standard PI controller where
Vdp is the phase error;
Vi = Vi + I*Vdp
Vf = Vi + (P+F) * Vdp

This can be simplified by dropping the F scale factor and increasing the
P a little

What am I missing?


I think I covered that above.


One thing for sure that the code is missing is a pre-filter, which is
very helpful because of the GPS phase noise.


It is missing a whole deal, but I wanted to illustrate the core.
One thing which is not covered is the un-wrapping of the phase detector
in the case that it does not wrap around binary. Another thing, the
frequency detector phase history may need to be unwrapped prior to
subtraction in order to make sure the frequency estimate becomes correct.


Turning on the "D" term in a PID with a prefilter is mostly not
recommended, They tend to just cancel each other.


I avoided the "D" coefficient name as it will be confusing to a normal
PID naming, when it will in fact does not do the normal "D".

Cheers,
Magnus


Magnus wrote
snip

My favorite solution is to derive the phase detector and let the result
feed in

Re: [time-nuts] ARM boards for low-cost GPSDOs

[Bob Camp]

Hi

If you are doing a GPSDO, you probably are playing a lot with things like clock 
trees and PLL frequencies. There are other free toolchains (often vendor 
specific) that can make this *much* easier. Not all ARM’s are the same in terms 
of clocking, so it’s not a one size fits all sort of thing. 

Bob

On Apr 12, 2014, at 7:01 PM, Jim Lux  wrote:

> On 4/12/14, 12:50 PM, Bob Camp wrote:
>> Hi
>> 
>> I’ve been working with some friends on an ARM based Arduino project. The 
>> support for ARM in the Arduino tool chain is still not really up to speed. 
>> It’s actually been faster / easier to take the stuff we need over to another 
>> board and tool chain than to fight through all of the gotchas within the 
>> Arduino / ARM world. The stuff is free / easy just about any way you do it.
>> 
> 
> The teensyduino stuff from PJRC is adding quite a lot to the ARM world within 
> the Arduino IDE.  It is true that for some of the onchip peripherals, there 
> might not be full support, and you have to do some register writing, etc.
> 
> 
>> At the chip level, the ARM’s have already overtaken many / most of the AVR’s 
>> that you would be using.
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] ARM boards for low-cost GPSDOs

[Jim Lux]

On 4/12/14, 12:50 PM, Bob Camp wrote:

Hi

I’ve been working with some friends on an ARM based Arduino project. The 
support for ARM in the Arduino tool chain is still not really up to speed. It’s 
actually been faster / easier to take the stuff we need over to another board 
and tool chain than to fight through all of the gotchas within the Arduino / 
ARM world. The stuff is free / easy just about any way you do it.



The teensyduino stuff from PJRC is adding quite a lot to the ARM world 
within the Arduino IDE.  It is true that for some of the onchip 
peripherals, there might not be full support, and you have to do some 
register writing, etc.




At the chip level, the ARM’s have already overtaken many / most of the AVR’s 
that you would be using.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO & Crystal Aging

[Magnus Danielson]

On 11/04/14 21:38, Chris Albertson wrote:

Look at what NTP does to select "good" clocks when it has many to choose
from.   It does not simply average them.

It looks at the noise in each one and then sees which clocks have
overlapping error bars.  It assumes that all good clocks have the same time
within limits of their precision.   Then from the good clocks there is a
second level weeding out process then finally it does a weighted average of
the remainders where I think those with less jitter get more weight.

It would not be impossible to do this with 10MHz oscillators.   Certainly a
simple average is not a good idea as a broken unit can pull the entire
average way down.  I think you'd have to check reasonableness first and
eliminate outliers   I think today you might simply digitize the signals
and figure out which were best using software.

In short the output is "ensemble time" (not "average time") but there is a
careful selection of who is allowed to be  member of the ensemble.


NTP uses the ensamble clock style that Dave Allan developed for the NBS 
AT time-scale and originally programmed on a PDP-7. Applying this type 
of phase-comparison, estimate stability, weighing and updating ensamble 
stability should indeed be possible to do. You need three or more 
clocks, but one of these can be the GPS when you have it.


Jim Gray pointed out that it is important to watch your data. At 
NBS/NIST they started to see some 1/f⁴ noise on one of their standards. 
They could not figure it out. Turned out that the cleaning-lady was 
pushing the standard over the floor once a week in order to clean under 
it. This systematic "noise" where not in their standard model, but they 
learned.


A frequency jump on the crystal oscillator in a control-loop will be 
tracked in eventually, so it will look more like a phase-spike than a 
frequency jump. Atomic clock FLLs will however not track in the full 
phase difference, at least not guaranteed to do.



I used a joke last week to explain to a class why we don't use averages,
with no other qualifications.  The joke is "Bill Gates walks into a bar
  What's the average net worth of everyone in the bar?  Maybe $250 million."

My point was that it is hard to describe a population that is not Gaussian
distributed.  "Stuck" and jumping crystals are not Gaussian.  You'd have to
detect the misbehaving devices.


Indeed.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO & Crystal Aging

[Magnus Danielson]

On 11/04/14 15:33, Tom Van Baak wrote:

Brooke, Ulrich,

Keep in mind the hp SmartClock product line dated from the early-90's and it was one of 
the first GPSDO on the market. So even simple things like using timing receivers, partial 
ionospheric correction, sawtooth correction, sub-ns TIC, 1PPS filtering, high-quality 
OCXO, PIID, DAC dithering, aging history and compensation would qualify as 
"smart". That's not to say there weren't other tricks going on.

One can learn a lot by playing with SCPI and pForth commands, as has been 
discussed here over the years. But the point is what was called smart 20 years 
ago may no longer be that magic. Page 6+ of the Kusters paper is interesting 
but nothing we don't already talk about weekly here.

Still, this is guessing. How about we find out for sure? Two ideas:

As a block box, a 58503A/Z3801A has only two inputs and two outputs. One input 
is the 1PPS from the Oncore VP (along with Motorola binary messages). The other 
input is the 10811. One output is 10 MHz, the other output is 1PPS, which is 
usually just locked to the phase of the LO. Or you could argue that there is 
really only one input (GPS 1PPS) and one output (DAC setting).

I propose someone on the list take a working 58503A and replace the Oncore VP 
with a pseudo GPS timing receiver and maybe also replace the 10811 with a DDS. 
In a very controlled manner, we can then mimic SA and post-SA jitter from the 
synthetic 1PPS. We can also mimic various oscillator phase and frequency 
behavior, including offsets, drift, and jumps using the DDS. The digital input 
to the DAC/EFC can be monitored to continuously track steering attempts. Or one 
could do man-in-the-middle games on the data to the DAC and avoid the need for 
the DDS.

By precisely watching how the SmartClock reacts to precise stimulus over 
seconds to days we can infer how the algorithms work with high confidence. Any 
number of people on the list can suggest clever stimulus scenarios to try. 
Unlike the GPSDO simulator (gpsim1), which can simulate a day in a seconds, the 
SmartClock experiment would have to run in real-time. That is, to infer how it 
handles aging prediction and holdover you'd actually have to let it run for a 
week.

The other idea, which I keep hoping Magnus will do, is to run the firmware 
under 68k emulation. It would be a large project, but I know he's already spent 
time on firmware disassembly.


I have spent a lot of time figuring a whole bunch of things out with the 
firmware. Lot's of it is boring like identifying libc routines, others 
is more interesting as figuring out the complete tree of SCPI commands 
as well as all the pFORTH commands. For each round I make I discover 
more, such as the minimum square loop that estimates the linear drift.


Tossing the code into a 68k emulation would be possible, but there is a 
bunch of things to simulate in it which relates to the hardware.


There is a general lack of decompiling tools, but I have been able to 
make more and more sense of what I got with the available tools. 
Unforunatly I have not been able to get the new version of the tool do 
anything useful without crashing on me.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Frequency of LC Tank

[Magnus Danielson]

On 12/04/14 21:23, d...@irtelemetrics.com wrote:

Magnus,
  You are very much on the track that I was thinking. I belive you are
absolutly correct
in that a 90 degree phase shift would be ideal.

I did a bit more digging last night, and it turns out that an XOR phase
comparator
  looking at the tank voltage and drive voltage may be ideal, as you
have suggested here. My main concern was that I plan to adjust the pulse
width of the push-pull the drive circuit to
  adjust the power into the tank circuit. (Actually the drive will be
full bridge, transformer
coupled to the tank). That change in pulse width is where I was stuck,
mentall. However since
  I'm in the 10Khz to 100Khz range and am generating the push-pull PWM
digitally, I can
  just generate a second output at the same frequency and phase (or even
different phase)
  than the drive signal to compare to the tank voltage.  As you say
"away you go with a phase
detector"!


I propose to sample the voltage rather than just using a XOR-gate (and a 
limiter in front of it to square things up). Thing is, the voltage from 
your LC tank is very analogue, so make use of this fact.


I would put a PI-loop (one op-amp, two resistors and a cap) in there.

As for frequency, your actual drive-oscillator can run at 4 times the 
rate and then use a frequency divider to provide the phases. This can 
provide you with in-phase and quadrature signals. Look at Tayloe 
detector in a search engine near you. The driven frequency will remain 
in your range, but you now have a quadrature signal to compare with.


Cheers,
Magnus

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Frequency of LC Tank

[Richard (Rick) Karlquist]

It is very easy to make an impedance phase detector by
inserting a toroidal current transformer in series with
the load under test.  The center of the secondary is
connected to the load through a capacitor.  Each end of
the secondary goes to a diode detector.  When the
load is resistive, the DC outputs of the two detectors
are equal.  You can see this in the literature back
as far as at least the 1950's for autotuning antennas.
It is closely related to various FM discriminator circuit
like the ratio detector.

Rick

On 4/12/2014 12:23 PM, d...@irtelemetrics.com wrote:

Magnus,
  You are very much on the track that I was thinking. I belive you are
absolutly correct
in that a 90 degree phase shift would be ideal.

I did a bit more digging last night, and it turns out that an XOR phase
comparator
  looking at the tank voltage and drive voltage may be ideal, as you
have suggested here. My main concern was that I plan to adjust the pulse
width of the push-pull the drive circuit to
  adjust the power into the tank circuit. (Actually the drive will be
full bridge, transformer
coupled to the tank). That change in pulse width is where I was stuck,
mentall. However since
  I'm in the 10Khz to 100Khz range and am generating the push-pull PWM
digitally, I can
  just generate a second output at the same frequency and phase (or even
different phase)
  than the drive signal to compare to the tank voltage.  As you say
"away you go with a phase
detector"!

Didier,
I guess the thing that's different here than in most situations, is that
normally you try not to load
  the tank circuit more than necessary. Here I'm loading the tank
circuit considerablly, knowing that it
  will change frequency with the change in Q. This change in frequency
is what I need to find, track, and follow.

The tank will be very lossy (Maybe consuming 20Kw to 30Kw of power if
all goes well). I'm also certian
Q will move all over the place. I just want to stay near the peak of the
bell, even if it's a short fat bell shaped
curve. Since the frequecny is low, I was thinking that even a modern
optocoupler should get me
  phase information well. At these power levels a little loading
souldn't be a big deal! :)

Dan


As you drive it with a pulse, you induce energy to it. If you sample
the voltage (or current) 90 degrees of from your drive-pulse, that
quadrature will indicate if you are early, late or prompt. As your
sampling point is also a sign of your current rate, and the pulse
forced the LC tank and your oscillator into sync, the frequency error
will cause the phase difference and hence voltage difference to be
observeable. As you are fairly close in frequency, so will the phase
error and you can assume the phase to voltage to be almost linear and
away you go with a phase detector. Cheers,
Magnus
--
Keep in mind that anything you connect across your tank circuit will
affect its resonant frequency and Q (signal source and measuring
device). You need to make sure your equipment is very loosely coupled
to the UUT through small value capacitors for instance.



 Didier KO4BB



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First success with very simple, very low cost GPSDO

[Magnus Danielson]

Warren,

On 12/04/14 21:09, WarrenS wrote:

Magnus

Interesting, Am I missing something or is there an error in your code or
logic.

Looks to me like the code is a PI controller with a added "D" term
(Vdf) of input,
and the "D" is then Integrated with a scale factor of "F" at  Vi = Vi +
F*Vdf ...
An integrated derivative is exactly equal to a P


I may appear so, but the derivate, scale-factor F and integrate does not 
make the scale-factor F equalent to P, since you are forgetting that the 
derivate removes the DC term and the integration forms it's own DC term. 
This DC-term as scaled through oscillator gain and added to the 
oscillators offset is then subtracted from the reference frequency and 
thus the error frequency is input to the integrator stage.


The FLL variant model can be understood if the differentiation is pushed 
to both inputs of the phase comparator, where the reference frequency 
and oscillators frequency will be subtracted rather than their phase and 
the only remaining integrator in the loop is that holding the Vi term. 
The frequency error term will exponentially decay with the time-constant 
as set by the F coefficient.


So, F and P is not equivalents, as P will not contribute to the state of 
Vi, which is evident in the weak pull-in of a standard PI loop.


However, F and P will for the AC behaviour of the loop be equivalents, 
so care must be taken into setting P with regard to F in order to get 
the expected damping of the loop.


Anyway, this is a FLL-aided PI-loop, which looks like an incorrectly 
wired PID-loop. Quite minimalistic.



Looks to me like the code is still just a standard PI controller where
Vdp is the phase error;
Vi = Vi + I*Vdp
Vf = Vi + (P+F) * Vdp

This can be simplified by dropping the F scale factor and increasing the
P a little

What am I missing?


I think I covered that above.


One thing for sure that the code is missing is a pre-filter, which is
very helpful because of the GPS phase noise.


It is missing a whole deal, but I wanted to illustrate the core.
One thing which is not covered is the un-wrapping of the phase detector 
in the case that it does not wrap around binary. Another thing, the 
frequency detector phase history may need to be unwrapped prior to 
subtraction in order to make sure the frequency estimate becomes correct.



Turning on the "D" term in a PID with a prefilter is mostly not
recommended, They tend to just cancel each other.


I avoided the "D" coefficient name as it will be confusing to a normal 
PID naming, when it will in fact does not do the normal "D".


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] ARM boards for low-cost GPSDOs

[Bob Camp]

Hi

I’ve been working with some friends on an ARM based Arduino project. The 
support for ARM in the Arduino tool chain is still not really up to speed. It’s 
actually been faster / easier to take the stuff we need over to another board 
and tool chain than to fight through all of the gotchas within the Arduino / 
ARM world. The stuff is free / easy just about any way you do it.

At the chip level, the ARM’s have already overtaken many / most of the AVR’s 
that you would be using. 

Bob

On Apr 12, 2014, at 3:23 PM, Chris Albertson  wrote:

> I have to agree.  At the hobby level I've been using board level products.
> Typically some guy in China buys the chips and any needed passive parts
> and builds a PCB.  Almost always the PCB will have a row of holes on the
> edge to fit a 0.1" header strip.   The board with shipping sells cheaper
> than the price of the parts.  (The Chinese sellers are using private
> mailing brokers who can aggregate large numbers of packages onto pallets,
> ship the pallets via low cost carries to a warehouse near a US post office.
> The packages are zip-code sorted and dropped into the USPO's pre-sorted
> bulk-mail system for just a few cents per package.)
> 
> I think what prevents many people from using some uP parts is the tools.
> In the past they were complex but Arduino fixed that.  They made is VERY
> easy to get started and really set the bar for others.   Everyone else is
> catching up. There really WAS a high cost of entry back when you needed
> to know how to edit text and send it to a compiler then a loader and  burn
> PROMs using special prom burner hardware.  All that complexity is now gone.
> 
> 
> Notice that new Arduino boards are ARM based and if you were foresightful
> enough to only use the features that are documented for Arduino your
> software can move directly to the new ARM board.  Many hobby programmers
> should not notice the difference when a CPU is changed.  They are writing
> in C/C++
> 
> Today at the retail level AVR based Arduino is much less expensive.  You
> can buy one with shipping for under $4 and you can use a 9V "radio battery"
> for a power supply.   I've bought some for under $3.But, yes some day
> ARM will move down into this price point.
> 
> 
> On Sat, Apr 12, 2014 at 9:23 AM, Bob Camp  wrote:
> 
>> Hi
>> 
>> Here's the issue about "big powerful 32 bit ARM processors"
>> 
>> At the chip level (as in no board, just the bare part to solder down)
>> their are many parts below $1 and some below $0.50 in reasonable quantity
>> (say 10K).  It's hard to find a useful MCU of any sort below $0.25, so the
>> "premium" for an ARM is not very large. Depending on what you need for i/o,
>> the ARM may / may not be lower priced than the alternative. In a *lot* of
>> cases it is the low price option. There are many flavors of ARM and many
>> competing parts, so doing a full matrix to compare them all is a massive
>> undertaking. Indeed a Coretex M0 with 32K of flash is not the same thing as
>> an M4 or something bigger still. There are a lot of flavors of ARM.
>> 
>> At the semiconductor level, none of the manufacturers are going to state
>> it clearly, but it's becoming more and more clear. The support for (and
>> enhancement of) chips that are not based on ARM is going to dry up. It's
>> happening already if you watch the little details. It will be happening
>> more and more as time marches on. It will be *very* tough for an MCU over
>> about $1.00 a chip (at say 10K pcs) to compete with the ARM parts going
>> forward outside niche markets (like DSP).
>> 
>> No, it's not going to happen overnight. It will take a number of years for
>> things to work out.
>> 
>> --
>> 
>> So why do a GPSDO on an ARM - They have staying power. The bang for the
>> buck is there. There are a lot of cheap boards out there with them already
>> set up and running on them. Nobody big is going back to leaded parts.
>> Semiconductor guys follow the big users. The future of "home project" work
>> with CPU's is to use a cheap board rather than a chip. The prices of the
>> boards will just keep coming down, they are not going to go up I can't
>> buy the parts on a $10 board for $30, let alone put them all together.
>> 
>> Pick a board and go with it. Put your *stuff* on a second board and plug
>> them together. Cheaper, faster, easier than DIY. You get USB / Ethernet /
>> whatever thrown in. With the right board (chip) you get flexible clocks and
>> PLL's that make the whole process a lot easier.
>> 
>> What's not to like?
>> 
>> Well yes, you need to dig into a tool chain. They either are free, or are
>> going to be free fairly soon now. There are even web based tools to do the
>> code stuff (mbed). You can't quite write it for one chip and drop it on
>> another one blindly. You do get locked (a bit) into your chip choice.
>> 
>> All in all, far more advantages than disadvantages.
>> 
>> Bob
>> 
>> 
>> On Apr 10, 2014, at 8:11 PM, Chris Albertson 
>> wrote:
>

Re: [time-nuts] Cesium 133 on kickstarter

[Ronald Held]

http://scpnt.stanford.edu/pnt/PNT11/2011_presentation_files/18_Lutwak-PNT2011.pdf

See page 20 where the C-field coil is depicted.

I was quite sure it was there.

Cheers,
Magnus

I see. I only looked at the Physics package and forgot about the C coil. Sorry.
 Ronald
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Frequency of LC Tank

[dan]

Magnus,
 You are very much on the track that I was thinking. I belive you are 
absolutly correct

in that a 90 degree phase shift would be ideal.   

I did a bit more digging last night, and it turns out that an XOR phase 
comparator
 looking at the tank voltage and drive voltage may be ideal, as you 
have suggested here. 
My main concern was that I plan to adjust the pulse width of the 
push-pull the drive circuit to
 adjust the power into the tank circuit. (Actually the drive will be 
full bridge, transformer
coupled to the tank). That change in pulse width is where I was stuck, 
mentall. However since
 I'm in the 10Khz to 100Khz range and am generating the push-pull PWM 
digitally, I can
 just generate a second output at the same frequency and phase (or 
even different phase)
 than the drive signal to compare to the tank voltage.  As you say 
"away you go with a phase

detector"! 

Didier,
I guess the thing that's different here than in most situations, is 
that normally you try not to load
 the tank circuit more than necessary. Here I'm loading the tank 
circuit considerablly, knowing that it
 will change frequency with the change in Q. This change in frequency 
is what I need to find, track, and follow. 


The tank will be very lossy (Maybe consuming 20Kw to 30Kw of power if 
all goes well). I'm also certian
Q will move all over the place. I just want to stay near the peak of 
the bell, even if it's a short fat bell shaped
curve. Since the frequecny is low, I was thinking that even a modern 
optocoupler should get me
 phase information well. At these power levels a little loading 
souldn't be a big deal! :) 


Dan

As you drive it with a pulse, you induce energy to it. If you sample 
the voltage (or current) 90 degrees of from your drive-pulse, that 
quadrature will indicate if you are early, late or prompt. As your 
sampling point is also a sign of your current rate, and the pulse 
forced the LC tank and your oscillator into sync, the frequency error 
will cause the phase difference and hence voltage difference to be 
observeable. As you are fairly close in frequency, so will the phase 
error and you can assume the phase to voltage to be almost linear and 
away you go with a phase detector. 
Cheers,

Magnus
--
Keep in mind that anything you connect across your tank circuit will 
affect its resonant frequency and Q (signal source and measuring 
device). You need to make sure your equipment is very loosely coupled 
to the UUT through small value capacitors for instance. 



 Didier KO4BB



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] ARM boards for low-cost GPSDOs

[Chris Albertson]

I have to agree.  At the hobby level I've been using board level products.
 Typically some guy in China buys the chips and any needed passive parts
and builds a PCB.  Almost always the PCB will have a row of holes on the
edge to fit a 0.1" header strip.   The board with shipping sells cheaper
than the price of the parts.  (The Chinese sellers are using private
mailing brokers who can aggregate large numbers of packages onto pallets,
ship the pallets via low cost carries to a warehouse near a US post office.
 The packages are zip-code sorted and dropped into the USPO's pre-sorted
bulk-mail system for just a few cents per package.)

I think what prevents many people from using some uP parts is the tools.
 In the past they were complex but Arduino fixed that.  They made is VERY
easy to get started and really set the bar for others.   Everyone else is
catching up. There really WAS a high cost of entry back when you needed
to know how to edit text and send it to a compiler then a loader and  burn
PROMs using special prom burner hardware.  All that complexity is now gone.


 Notice that new Arduino boards are ARM based and if you were foresightful
enough to only use the features that are documented for Arduino your
software can move directly to the new ARM board.  Many hobby programmers
should not notice the difference when a CPU is changed.  They are writing
in C/C++

Today at the retail level AVR based Arduino is much less expensive.  You
can buy one with shipping for under $4 and you can use a 9V "radio battery"
for a power supply.   I've bought some for under $3.But, yes some day
ARM will move down into this price point.


On Sat, Apr 12, 2014 at 9:23 AM, Bob Camp  wrote:

> Hi
>
> Here's the issue about "big powerful 32 bit ARM processors"
>
> At the chip level (as in no board, just the bare part to solder down)
> their are many parts below $1 and some below $0.50 in reasonable quantity
> (say 10K).  It's hard to find a useful MCU of any sort below $0.25, so the
> "premium" for an ARM is not very large. Depending on what you need for i/o,
> the ARM may / may not be lower priced than the alternative. In a *lot* of
> cases it is the low price option. There are many flavors of ARM and many
> competing parts, so doing a full matrix to compare them all is a massive
> undertaking. Indeed a Coretex M0 with 32K of flash is not the same thing as
> an M4 or something bigger still. There are a lot of flavors of ARM.
>
> At the semiconductor level, none of the manufacturers are going to state
> it clearly, but it's becoming more and more clear. The support for (and
> enhancement of) chips that are not based on ARM is going to dry up. It's
> happening already if you watch the little details. It will be happening
> more and more as time marches on. It will be *very* tough for an MCU over
> about $1.00 a chip (at say 10K pcs) to compete with the ARM parts going
> forward outside niche markets (like DSP).
>
> No, it's not going to happen overnight. It will take a number of years for
> things to work out.
>
> --
>
> So why do a GPSDO on an ARM - They have staying power. The bang for the
> buck is there. There are a lot of cheap boards out there with them already
> set up and running on them. Nobody big is going back to leaded parts.
> Semiconductor guys follow the big users. The future of "home project" work
> with CPU's is to use a cheap board rather than a chip. The prices of the
> boards will just keep coming down, they are not going to go up I can't
> buy the parts on a $10 board for $30, let alone put them all together.
>
> Pick a board and go with it. Put your *stuff* on a second board and plug
> them together. Cheaper, faster, easier than DIY. You get USB / Ethernet /
> whatever thrown in. With the right board (chip) you get flexible clocks and
> PLL's that make the whole process a lot easier.
>
> What's not to like?
>
> Well yes, you need to dig into a tool chain. They either are free, or are
> going to be free fairly soon now. There are even web based tools to do the
> code stuff (mbed). You can't quite write it for one chip and drop it on
> another one blindly. You do get locked (a bit) into your chip choice.
>
> All in all, far more advantages than disadvantages.
>
> Bob
>
>
> On Apr 10, 2014, at 8:11 PM, Chris Albertson 
> wrote:
>
> > I'm thinking about good reasons to build a GPSDO using something as big
> and
> > powerful as a 32-bit ARM processor.I think the reason is that you are
> > not really building a GPSDO but some other device that just happens to
> have
> > a GPSDO inside of it.
> >
> > For example you want to build a laser range finder and you need to
> measure
> > time of flight delay.  You'd need a very good clock and while you are at
> it
> > why not discipline the clock with GPS.  I could think of some radio
> > experiments where I would want pairs of receivers with their local
> > oscillators running in phase but many miles apart, so I'd build a GPSDO
> > into the ra

Re: [time-nuts] First success with very simple, very low cost GPSDO

[WarrenS]

Magnus

Interesting, Am I missing something or is there an error in your code or 
logic.


Looks to me like the code is a PI controller with a added "D" term  (Vdf) 
of input,
and the "D" is then Integrated with a scale factor of "F" at  Vi = Vi + 
F*Vdf ...

An integrated derivative is exactly equal to a P

Looks to me like the code is still just a standard PI controller where Vdp 
is the phase error;

Vi = Vi + I*Vdp
Vf = Vi + (P+F) * Vdp

This can be simplified by dropping the F scale factor and increasing the P a 
little


What am I missing?

One thing for sure that the code is missing is a pre-filter, which is very 
helpful because of the GPS phase noise.
Turning on the "D" term in a PID with a prefilter is mostly not recommended, 
They tend to just cancel each other.


ws

**

Magnus Danielson wrote

On 10/04/14 20:28, Tom Van Baak wrote:
I agree with Charles. Further, you don't even have to wait a predetermined 
amount of time (this would be oscillator or environment dependent). 
Instead simply monitor the rate of frequency change. When the drift rate 
drops to the level where your PID is known to be able to track, then start 
the PID.


Realize that just 2 seconds after power-up you have your first frequency 
measurement. By 3 seconds you have your first drift measurement. Just wait 
until it falls to however few ppm/second or ppb/second you need for your 
loop to smoothly track. This avoids special case PID startup or wind-up 
code. Although you can argue it merely replaces it with special case drift 
rate code.


I'm suspicious of fast/slow tracking loops. If you want to vary the 
tracking, perhaps it is best to continuously, transparently, smoothly vary 
loop parameters according to drift rate rather than use a hardcoded 
fast/slow algorithm binary switch. I'm sure there's deep theory on this, 
which I have not read yet.


This is where many spend their time building a heuristics.

My favorite solution is to derive the phase detector and let the result
feed into the integrator through a scaling factor. This input to the
integrator is in parallel to the I factor input. Code-wise we get
something like this:

Vdf = Vdp - Vdp_pre
Vdp_pre = Vdp
Vi = Vi + I*Vdp + F*Vdf
Vf = Vi + P*Vdp

For far-out frequency errors, the PI PLL is weak, due to Bessel
coefficient, so the FLL dominates and the F factor steers the loop gain
of the FLL. It steers the Vi state of the integrator until it becomes
close, with an exponential decay into zero frequency error. When it
does, the Bessel coefficient becomes stronger and stronger and then PI
PLL starts to take over. When the gain of the PLL surpasses that of the
decaying FLL the PLL just takes over... by design. When the PLL has
locked the frequency, the FLL part just doesn't have gain, but adds a
little noise.

The benefit of this approach is that the frequency correction is kept in
the Vi state, and depending on the Vi state either the FLL or PLL
dominates, there is no hand-over, there is no external intelligence to
chose mode, it is always steered by the need from frequency-error
needing to be corrected and the current Vi, or if you so like, the
current Vi error.

Simple, relatively easy to analyse and completely linear regulation
mechanisms.

Cheers,
Magnus 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cesium 133 on kickstarter

[Magnus Danielson]

On 12/04/14 18:37, Ronald Held wrote:

A CSAC does not use magnetic field as a Cs primary frequency standard
does, AFAIK.


http://scpnt.stanford.edu/pnt/PNT11/2011_presentation_files/18_Lutwak-PNT2011.pdf

See page 20 where the C-field coil is depicted.

I was quite sure it was there.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] ARM boards for low-cost GPSDOs

[paul swed]

Bob 100% totally agree and I am seeing the same thing happening. It has to
do with the lower power consumption. When you see Intel scrambling again to
take some share thats the biggest clue there is that a shift is on the way.
But enough of that I said my piece far earlier in the chain. We sure are
lucky to have this stuff on a board to use for what I consider to be
inexpensive. And I don't have to solder the darned things!
Best regards
Paul
WB8TSL


On Sat, Apr 12, 2014 at 12:23 PM, Bob Camp  wrote:

> Hi
>
> Here's the issue about "big powerful 32 bit ARM processors"
>
> At the chip level (as in no board, just the bare part to solder down)
> their are many parts below $1 and some below $0.50 in reasonable quantity
> (say 10K).  It's hard to find a useful MCU of any sort below $0.25, so the
> "premium" for an ARM is not very large. Depending on what you need for i/o,
> the ARM may / may not be lower priced than the alternative. In a *lot* of
> cases it is the low price option. There are many flavors of ARM and many
> competing parts, so doing a full matrix to compare them all is a massive
> undertaking. Indeed a Coretex M0 with 32K of flash is not the same thing as
> an M4 or something bigger still. There are a lot of flavors of ARM.
>
> At the semiconductor level, none of the manufacturers are going to state
> it clearly, but it's becoming more and more clear. The support for (and
> enhancement of) chips that are not based on ARM is going to dry up. It's
> happening already if you watch the little details. It will be happening
> more and more as time marches on. It will be *very* tough for an MCU over
> about $1.00 a chip (at say 10K pcs) to compete with the ARM parts going
> forward outside niche markets (like DSP).
>
> No, it's not going to happen overnight. It will take a number of years for
> things to work out.
>
> --
>
> So why do a GPSDO on an ARM - They have staying power. The bang for the
> buck is there. There are a lot of cheap boards out there with them already
> set up and running on them. Nobody big is going back to leaded parts.
> Semiconductor guys follow the big users. The future of "home project" work
> with CPU's is to use a cheap board rather than a chip. The prices of the
> boards will just keep coming down, they are not going to go up I can't
> buy the parts on a $10 board for $30, let alone put them all together.
>
> Pick a board and go with it. Put your *stuff* on a second board and plug
> them together. Cheaper, faster, easier than DIY. You get USB / Ethernet /
> whatever thrown in. With the right board (chip) you get flexible clocks and
> PLL's that make the whole process a lot easier.
>
> What's not to like?
>
> Well yes, you need to dig into a tool chain. They either are free, or are
> going to be free fairly soon now. There are even web based tools to do the
> code stuff (mbed). You can't quite write it for one chip and drop it on
> another one blindly. You do get locked (a bit) into your chip choice.
>
> All in all, far more advantages than disadvantages.
>
> Bob
>
>
> On Apr 10, 2014, at 8:11 PM, Chris Albertson 
> wrote:
>
> > I'm thinking about good reasons to build a GPSDO using something as big
> and
> > powerful as a 32-bit ARM processor.I think the reason is that you are
> > not really building a GPSDO but some other device that just happens to
> have
> > a GPSDO inside of it.
> >
> > For example you want to build a laser range finder and you need to
> measure
> > time of flight delay.  You'd need a very good clock and while you are at
> it
> > why not discipline the clock with GPS.  I could think of some radio
> > experiments where I would want pairs of receivers with their local
> > oscillators running in phase but many miles apart, so I'd build a GPSDO
> > into the radio.The ARM would support running the GPSDO, the bigger
> > application and also remote access over the network or Internet.
> >
> > Today people mostly will build a stand alone GPSDO in a dedicated box and
> > then connect the 10MHZ output to whatever is needed but now as we have
> > seen, you can build a GPSDO completely in software, if your project
> already
> > has a computer then you can run a GPSDO inside an interrupt handler as a
> > background task.  Adding GPSDO functionality to an existing product is
> > almost trivially simple, just $2 in parts and some software if you
> already
> > have a CPU and OCXO as part of your system.
> >
> > Placing the GPSDO inside the product means the gpsdo can run at a
> frequency
> > that is more useful and needs no conversion.   So you can have the GPS
> > control a 23 Mhz crystal if that is what your laser rangefinder needs.
>  Now
> > that the cost of a GPSDO has fallen to $3 you can build them into
> > "everything".  It no longer needs to be a shared device.
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/tim

Re: [time-nuts] NIST Radio Station WWV now on 25 MHz

[paul swed]

Its off the air over the weekend as NIST stated.
I have no idea why, but I think Chucks near Boston.
Regards
Paul.


On Fri, Apr 11, 2014 at 11:01 PM, David McGaw  wrote:

> Easily heard on a 12 ft wire in NH this afternoon.  Chuck - You may be too
> close and it is skipping over.
>
> David N1HAC
>
>
> On 4/11/14 8:37 PM, paul swed wrote:
>
>> Chuck
>> The an/urr R1051 does not have a signal meter. It has level meters for
>> audio.
>> Those navy radios. I guess they figured the radio guys could not figure
>> out
>> signal strength. Come to think of it as I recall they could not figure out
>> ships antennas either.
>> That said I would give WWV a solid S5-S9 little QSB right now. Very
>> comfortable. I am using a multi-band beam at 90' on top of a very tall
>> hill.
>>
>> Regards
>> Paul
>> WB8TSL
>> Near Boston
>>
>>
>> On Fri, Apr 11, 2014 at 7:16 PM, Chuck Forsberg WA7KGX 
>> wrote:
>>
>>  Tried three times today to get WWV on 25, heard nothing under the power
>>> line noise.
>>> I did have a nice QSO on 12 meters with a station in Rochester, NY so the
>>> band is open.
>>> WWV is currently weak on 20, strong on 15 and 10 MHz.
>>>
>>>
>>> On 04/11/2014 12:09 PM, paul swed wrote:
>>>
>>>  Fired up the R1051 on 25 Mhz and its great to hear wwv back on the air
 in
 Boston.
 Pretty good signal.
 Regards
 Paul
 WB8TSL


 On Fri, Apr 11, 2014 at 10:12 AM, David McGaw 
 wrote:

   Yea!  I remember when they shut it down at the nadir of the sunspot

> cycle,
> saying no one was using it.  Duh!
>
> David N1HAC
>
>
>
> On 4/11/14 12:07 AM, Max Robinson wrote:
>
>   WWV used to be on 25 MHz but when the sunspot cycle hit a minimum
> they
>
>> shut it down.  That was years ago.  I'm glad to know they are bringing
>> it
>> back.
>>
>> Regards.
>>
>> Max.  K 4 O DS.
>>
>> Email: m...@maxsmusicplace.com
>>
>> Transistor site http://www.funwithtransistors.net
>> Vacuum tube site: http://www.funwithtubes.net
>> Woodworking site http://www.angelfire.com/electronic/funwithtubes/
>> Woodworking/wwindex.html
>> Music site: http://www.maxsmusicplace.com
>>
>> To subscribe to the fun with transistors group send an email to.
>> funwithtransistors-subscr...@yahoogroups.com
>>
>> To subscribe to the fun with tubes group send an email to,
>> funwithtubes-subscr...@yahoogroups.com
>>
>> To subscribe to the fun with wood group send a blank email to
>> funwithwood-subscr...@yahoogroups.com
>>
>> - Original Message - From: "Gordon Batey" <
>> gpba...@wildblue.net
>> To: "Gordon Batey" 
>> Sent: Thursday, April 10, 2014 3:01 PM
>> Subject: [time-nuts] NIST Radio Station WWV now on 25 MHz
>>
>>
>>
>>   For what it is worth a friend sent me this link.
>>
>>> WWV is now testing on 25 MHZ.
>>>
>>> >>
>>> 73 Gordon WA4FJC
>>>
>>>
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>>> mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>>   ___
>>>
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>   ___
>>
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
>   ___
>
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/
 mailman/listinfo/time-nuts
 and follow the instructions there.


  --
>>>   Chuck Forsberg WA7KGX   c...@omen.com   www.omen.com
>>> Developer of Industrial ZMODEM(Tm) for Embedded Applications
>>>Omen Technology Inc  "The High Reliability Software"
>>> 10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430
>>>
>>>
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>>> mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>>  ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nu

Re: [time-nuts] First success with very simple, very low cost GPSDO

[Magnus Danielson]

On 10/04/14 20:28, Tom Van Baak wrote:

I agree with Charles. Further, you don't even have to wait a predetermined 
amount of time (this would be oscillator or environment dependent). Instead 
simply monitor the rate of frequency change. When the drift rate drops to the 
level where your PID is known to be able to track, then start the PID.

Realize that just 2 seconds after power-up you have your first frequency 
measurement. By 3 seconds you have your first drift measurement. Just wait 
until it falls to however few ppm/second or ppb/second you need for your loop 
to smoothly track. This avoids special case PID startup or wind-up code. 
Although you can argue it merely replaces it with special case drift rate code.

I'm suspicious of fast/slow tracking loops. If you want to vary the tracking, 
perhaps it is best to continuously, transparently, smoothly vary loop 
parameters according to drift rate rather than use a hardcoded fast/slow 
algorithm binary switch. I'm sure there's deep theory on this, which I have not 
read yet.


This is where many spend their time building a heuristics.

My favorite solution is to derive the phase detector and let the result 
feed into the integrator through a scaling factor. This input to the 
integrator is in parallel to the I factor input. Code-wise we get 
something like this:


Vdf = Vdp - Vdp_pre
Vdp_pre = Vdp
Vi = Vi + I*Vdp + F*Vdf
Vf = Vi + P*Vdp

For far-out frequency errors, the PI PLL is weak, due to Bessel 
coefficient, so the FLL dominates and the F factor steers the loop gain 
of the FLL. It steers the Vi state of the integrator until it becomes 
close, with an exponential decay into zero frequency error. When it 
does, the Bessel coefficient becomes stronger and stronger and then PI 
PLL starts to take over. When the gain of the PLL surpasses that of the 
decaying FLL the PLL just takes over... by design. When the PLL has 
locked the frequency, the FLL part just doesn't have gain, but adds a 
little noise.


The benefit of this approach is that the frequency correction is kept in 
the Vi state, and depending on the Vi state either the FLL or PLL 
dominates, there is no hand-over, there is no external intelligence to 
chose mode, it is always steered by the need from frequency-error 
needing to be corrected and the current Vi, or if you so like, the 
current Vi error.


Simple, relatively easy to analyse and completely linear regulation 
mechanisms.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8

[Magnus Danielson]

Hi,

On 10/04/14 06:43, Tom Van Baak wrote:

You are right in the I don't even need data cycles.  All I want is the
error which is 5,000,000 minus the count.  this is hopefully zero.


Correct. Keep the counter running. No need to zero it, ever. Use differential 
measurements. Essentially you are using binary modulus arithmetic.


BTW a trick for zero-dead-time counters is to let the counters running 
and just sample them. This fits very well with the work description for 
the counter in a GPSDO.



This would be easier if we have a 32 bit counter that could be reset
to zero each second.   In the past I think people have built counters
like this but now I can buy a $3.80 Arduino that does the counting,
ADC and DAC and computer USB interface.  So I put up with a harder to
use 16-bit nonresetable counter


Chris,

In applications like this, never reset a counter to zero; this opens chances 
for off-by-one errors and cycle slips. Just compute differences. The start-up 
value of the timer is irrelevant.

Moreover, 32-bits is unnecessary. Perhaps you didn't understand Bob's posting. 
Even 16-bits is more than enough. Let me explain.

You only need enough bits to cover the worst case OCXO frequency drift or the 
worst case GPS jitter error, per second. For example, if your OCXO stays 
accurate to 1 ppm it can't possibly drift more than 1 us per second. Similarly, 
it's a safe assumption that your GPS 1PPS stays within 1 us of correct time. 
Therefore, the maximum number of 100 ns ticks you will be off in any second is 
+/-10. So even a 8-bit counter is enough. Does this make sense now?


In fact a 5 bit counter is enough, and then a '373 to sample it. The 
enable to the 373 needs to be synchronous to the 5/10 MHz clock, so a 
pair of DFFs ('74) is needed to synchronize the PPS and another pair to 
create the single cycle enable.



If you were building a general purpose arbitrary frequency counter, then a 
resetable 32-bit counter would be nice. But you're not. A GPSDO is a special 
case where you know the frequency will always be very close to 5 or 10 MHz 
every second. So you only need a few bits to measure the error each second.

To use your decimal example, if the measurements are mostly 500 but 
sometimes 499 or 501 you only need to look at the last digit for your 
error. In hex this would be 4C4B40, 4C4B3F, 4C4B41, only the bottom two bits 
are needed (0, F, or 1).

The bottom line is you don't need timer interrupts, you don't need time. You 
don't need 32-bits. You probably don't need 16-bits. You don't need semaphores. 
All you're interested in is how far off the oscillator is each second. One 
interrupt (for the GPS 1PPS) is all you need. If your CPU has a capture 
register you don't need interrupts at all. Then you don't need volatile either. 
Since your error is limited to +100 and -100 you can use 8-bit integers. You 
don't need to test for 30 hours; instead the code will be simple enough that it 
is air tight by design, not by luck. You will avoid interrupt collisions by not 
having more than one interrupt; you don't have to enable or disable interrupts 
either. You'll be surprised how simple it all gets.


If you use a simple SR flip-flop to hold the state if there is a new 
value or not. When a value is sampled, it is set. The software then 
polls that bit and if it is set, it reads the sampled counter, sets the 
R bit and then clears it. As long as you poll regularly you will not 
miss or double-read a value.


It's fairly easy to decouple the hard timing requirements to looser 
timing requirements if you just care about a few details.


Cheers,
Magnus

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cesium 133 on kickstarter

[Ronald Held]

A CSAC does not use magnetic field as a Cs primary frequency standard
does, AFAIK.
 Ronald
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] ARM boards for low-cost GPSDOs

[Bob Camp]

Hi

Here’s the issue about “big powerful 32 bit ARM processors”….

At the chip level (as in no board, just the bare part to solder down) their are 
many parts below $1 and some below $0.50 in reasonable quantity (say 10K).  
It’s hard to find a useful MCU of any sort below $0.25, so the “premium” for an 
ARM is not very large. Depending on what you need for i/o, the ARM may / may 
not be lower priced than the alternative. In a *lot* of cases it is the low 
price option. There are many flavors of ARM and many competing parts, so doing 
a full matrix to compare them all is a massive undertaking. Indeed a Coretex M0 
with 32K of flash is not the same thing as an M4 or something bigger still. 
There are a lot of flavors of ARM. 

At the semiconductor level, none of the manufacturers are going to state it 
clearly, but it’s becoming more and more clear. The support for (and 
enhancement of) chips that are not based on ARM is going to dry up. It’s 
happening already if you watch the little details. It will be happening more 
and more as time marches on. It will be *very* tough for an MCU over about 
$1.00 a chip (at say 10K pcs) to compete with the ARM parts going forward 
outside niche markets (like DSP). 

No, it’s not going to happen overnight. It will take a number of years for 
things to work out. 

———

So why do a GPSDO on an ARM - They have staying power. The bang for the buck is 
there. There are a lot of cheap boards out there with them already set up and 
running on them. Nobody big is going back to leaded parts. Semiconductor guys 
follow the big users. The future of “home project” work with CPU’s is to use a 
cheap board rather than a chip. The prices of the boards will just keep coming 
down, they are not going to go up…. I can’t buy the parts on a $10 board for 
$30, let alone put them all together. 

Pick a board and go with it. Put your *stuff* on a second board and plug them 
together. Cheaper, faster, easier than DIY. You get USB / Ethernet / whatever 
thrown in. With the right board (chip) you get flexible clocks and PLL’s that 
make the whole process a lot easier. 

What’s not to like?

Well yes, you need to dig into a tool chain. They either are free, or are going 
to be free fairly soon now. There are even web based tools to do the code stuff 
(mbed). You can’t quite write it for one chip and drop it on another one 
blindly. You do get locked (a bit) into your chip choice.

All in all, far more advantages than disadvantages. 

Bob


On Apr 10, 2014, at 8:11 PM, Chris Albertson  wrote:

> I'm thinking about good reasons to build a GPSDO using something as big and
> powerful as a 32-bit ARM processor.I think the reason is that you are
> not really building a GPSDO but some other device that just happens to have
> a GPSDO inside of it.
> 
> For example you want to build a laser range finder and you need to measure
> time of flight delay.  You'd need a very good clock and while you are at it
> why not discipline the clock with GPS.  I could think of some radio
> experiments where I would want pairs of receivers with their local
> oscillators running in phase but many miles apart, so I'd build a GPSDO
> into the radio.The ARM would support running the GPSDO, the bigger
> application and also remote access over the network or Internet.
> 
> Today people mostly will build a stand alone GPSDO in a dedicated box and
> then connect the 10MHZ output to whatever is needed but now as we have
> seen, you can build a GPSDO completely in software, if your project already
> has a computer then you can run a GPSDO inside an interrupt handler as a
> background task.  Adding GPSDO functionality to an existing product is
> almost trivially simple, just $2 in parts and some software if you already
> have a CPU and OCXO as part of your system.
> 
> Placing the GPSDO inside the product means the gpsdo can run at a frequency
> that is more useful and needs no conversion.   So you can have the GPS
> control a 23 Mhz crystal if that is what your laser rangefinder needs.  Now
> that the cost of a GPSDO has fallen to $3 you can build them into
> "everything".  It no longer needs to be a shared device.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Frequency of LC Tank.

[Didier Juges]

Keep in mind that anything you connect across your tank circuit will affect its 
resonant frequency and Q (signal source and measuring device). You need to make 
sure your equipment is very loosely coupled to the UUT through small value 
capacitors for instance.

 Didier KO4BB


On April 11, 2014 3:15:37 PM CDT, Dan Kemppainen  wrote:
>Hi all,
>
>I'm thinking about an upcoming project, if this is off topic please
>disregard or contact me off list. :)
>
>I have a large LC tank, with a very lossy inductor. Being driven by a
>pulse width push pull driver, that is digitally controlled. The driver
>circuit will couple through a N:1 transformer. I need to be able to
>adjust the push/pull driver frequency to match the frequency of the
>tank
>circuit. (See frequency/time is involved :) ) The tank components can
>vary and are not adjustable, so the drive frequency needs to vary.
>
>I'm thinking some sort of a phase detector may be the way to go. I'm
>just not sure were to sample the V and I signals to look for phase
>differences, or where to get a good clean reference from.
>
>So the question is, when actively driving a tank circuit, how do you
>know you are driving it with the same frequency ad the same phase it
>naturally oscillates at.
>
>Any thoughts, suggestions, or readily available papers you guy could
>point me to?
>
>Thanks!
>Dan
>___
>time-nuts mailing list -- time-nuts@febo.com
>To unsubscribe, go to
>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>and follow the instructions there.

-- 
Sent from my Motorola Droid Razr 4G LTE wireless tracker while I do other 
things.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Frequency of LC Tank.

[Magnus Danielson]

On 11/04/14 22:15, Dan Kemppainen wrote:

Hi all,

I'm thinking about an upcoming project, if this is off topic please
disregard or contact me off list. :)

I have a large LC tank, with a very lossy inductor. Being driven by a
pulse width push pull driver, that is digitally controlled. The driver
circuit will couple through a N:1 transformer. I need to be able to
adjust the push/pull driver frequency to match the frequency of the tank
circuit. (See frequency/time is involved :) ) The tank components can
vary and are not adjustable, so the drive frequency needs to vary.

I'm thinking some sort of a phase detector may be the way to go. I'm
just not sure were to sample the V and I signals to look for phase
differences, or where to get a good clean reference from.

So the question is, when actively driving a tank circuit, how do you
know you are driving it with the same frequency ad the same phase it
naturally oscillates at.

Any thoughts, suggestions, or readily available papers you guy could
point me to?


As you drive it with a pulse, you induce energy to it. If you sample the 
voltage (or current) 90 degrees of from your drive-pulse, that 
quadrature will indicate if you are early, late or prompt. As your 
sampling point is also a sign of your current rate, and the pulse forced 
the LC tank and your oscillator into sync, the frequency error will 
cause the phase difference and hence voltage difference to be 
observeable. As you are fairly close in frequency, so will the phase 
error and you can assume the phase to voltage to be almost linear and 
away you go with a phase detector.


Cheers,
Magnus

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Clock quality: alternatives to ADEV

[Magnus Danielson]

On 10/04/14 19:24, Richard (Rick) Karlquist wrote:

The trouble with ADEV is that if you average
a long time it papers over anomalous events
like crystal jumps.


ADEV is about characterizing noise powers. The better variants such as 
TOTADEV and TheoADEV will be even more efficient at suppressing a 
crystal jump. It's just not the right tool for crystal jumps.



 An alternative measure
might be to, instead of averaging, simply
keep track of the worse case change in frequency
during 1 sample period.  Sort of like peak jitter
versus rms jitter.


MAFE (Maximum Average Frequency Error) might be a suitable measure to 
apply, it's the frequency relative to MATIE (Maximum Average Time 
Interval Error).


MTIE (Maximum Time Interval Error) has been used for a long time 
characterize longer term systematics.


Maybe just doing a MFE (Maximum Frequency Error) might be the tool at hand.

Just to get the ideas rolling.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Clock quality: alternatives to ADEV

[Magnus Danielson]

On 10/04/14 00:38, Hal Murray wrote:


I've been watching the discussions and graphs for a while.  ADEV seems
appropriate for cases where the noise pattern is "nice".  How does ADEV work
if the noise isn't nice?  Are there alternatives?  What's the mathematical
term for the type of noise that works well with ADEV?


ADEV and friends is intended to handle phase-noise of 1/f³, 1/f², 1/f 
and white and aid in separating them such that the strength of the 
individual noises can be established.




I can think of 3 examples:
   Crystal jumps


Crystal jumps is rare enough to not contributing much noise power, which 
ADEV is collecting with various filters. It is however a quite annoying 
random effect. Better characterized by other means.



   GPSDOs going into holdover.


For hold-over, you need to characterize the drift of oscillator and 
other frequency controlling things (such as DAC and voltage-ref). In 
addition, environmental effects will all of a sudden be uncompensated.

ADEV isn't a good tool for systematic effects like these.


   Power lines make all sorts of interesting not-quite jumps.


This is a systematic effect for which ADEV isn't well suited.


Is there a way of characterizing that sort of event?  How do I turn a pile of
data into a useful graph or chart?


You can make a TE plot (i.e. the phase plot) which illustrate these 
properties.



What does an ADEV graph look like if the data has crystal jumps?


Depends on the length of the data, the more data before or after the 
jump, the less prominent the crystal jump polutes the ADEV plot.



I'd expect that something like crystal jumps would follow some sort of power
law: the bigger jumps would be less frequent.  But it wouldn't surprise me if
the GPS or power lines had an underlying mechanism that turned into a
different pattern.


Crystal jumps can most probably be modelled as a noise form, but the 
power will be very small, so it will not be giving much information in a 
ADEV plot. Rather, average jump length and average rate should be more 
of interest when considering their impacts.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Frequency of LC Tank.

[nuts]

Some terminology to consider. There is the natural and damped frequency
to consider. That is, as you load the circuit, the resonance changes. If
you drive it with infinite impedance, you are at the natural frequency.
Loading it will shift the frequency, hence the damped frequency. 

I would try to lose the transformer if possible. 

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cesium 133 on kickstarter

[Azelio Boriani]

C-field in the CSAC?

On Fri, Apr 11, 2014 at 3:19 PM, Gerald Chafee  wrote:
> I wonder if a CSAC used as a wristwatch would need constant C-field
> adjustment?
>
>
> On Thu, Apr 10, 2014 at 12:41 PM, Attila Kinali  wrote:
>
>> On Thu, 10 Apr 2014 10:43:13 -0400
>> Ronald Held  wrote:
>>
>> > I am curious what people think of this watch at least from the time-nut
>> POV.
>>
>> Considering that they are not the first, but at least the third with
>> that idea (see archives for other CSAC wrist watches).
>>
>> But seriously, a modern, temperature compensated quartz watch goes better
>> than +/-10s in half a year (about 1ppm), which is already about as good as
>> you
>> need for a wrist watch. Any better is just unnecessary overengineering.
>> Of course, it's a different matter if you like to show of to your peers.
>>
>> Other than that, i probably would buy a CSAC and put it into some equipment
>> instead. :-)
>>
>> Attila Kinali
>>
>> --
>> I pity people who can't find laughter or at least some bit of amusement in
>> the little doings of the day. I believe I could find something ridiculous
>> even in the saddest moment, if necessary. It has nothing to do with being
>> superficial. It's a matter of joy in life.
>> -- Sophie Scholl
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.