Re: [time-nuts] 10 MHz to 32.768 kHz converter

[Chris Albertson]

In theory what is the best you can do using division of a 10MHz signal.
It's really not very good the period of the 32768 hz output will always be
"off".

I think the best way is to divide the 10MHz signal by some power of five
(like 78125) then use that to phase lock your 32768 oscillator.  In other
words use the 10MHz signal to discipline the 32K crystal.

On Sun, Mar 20, 2016 at 3:23 PM, Vlad  wrote:

>
>
> How about Bresenham's Algorithm to alternate imperfect periods to produce
> an average that matches any "perfect" period.
>
> Refer to Bob Ammerman work to use Bresenham-type system for PIC MCU. He
> was using the counter works in the background, either by polling or
> Interrupt-Driven. So, the "SuperCycle" continues to run. The timer count
> the value is stored in a 3-byte register that is decremented by the
> software.
>
> Regards,
> Vlad
>
> On 2016-03-20 14:26, Martyn Smith wrote:
>
>> Hello,
>>
>>
>>
>> First of all quick apologies for sending an email last week without
>> deleting all the old information from previous postings.
>>
>>
>>
>> I have been playing around with producing 32.768 kHz from 10 MHz using
>> a PIC chip.
>>
>>
>>
>> I  have a real time clock calendar chip that requires a 32.768 kHz
>> crystal.  I want to feed it with 10 MHz signal instead, so it is
>> synchronised to my main 10 MHz in a frequency standard I am designing.
>>
>>
>>
>> The method I’m using has been documented before where we have two
>> loops running 9632 times through a 39 instruction loop and
>> 55904 times through a 38 instruction loop, each time toggling the output
>> pin.
>>
>>
>>
>> I have done this and am getting approximately 32.768 kHz with the FM
>> modulation as described by previous authors.
>>
>>
>>
>> My question is should I expect exactly 32.76800 kHz (obviously
>> assuming we use the same 10 MHz to drive the divider and all test
>> equipment)?
>>
>>
>>
>> The closest I can get the 32.768 kHz is within about 0.1 Hz.
>>
>>
>>
>> Does the actual model of PIC chip influence the accuracy?
>>
>>
>>
>> Regards
>>
>>
>>
>> Martyn
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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.
>>
>
> --
> WBW,
>
> V.P.
> ___
> 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.
>



-- 

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] 10 MHz to 32.768 kHz converter

[Vlad]

How about Bresenham's Algorithm to alternate imperfect periods to 
produce an average that matches any "perfect" period.


Refer to Bob Ammerman work to use Bresenham-type system for PIC MCU. He 
was using the counter works in the background, either by polling or 
Interrupt-Driven. So, the "SuperCycle" continues to run. The timer count 
the value is stored in a 3-byte register that is decremented by the 
software.


Regards,
Vlad

On 2016-03-20 14:26, Martyn Smith wrote:

Hello,



First of all quick apologies for sending an email last week without
deleting all the old information from previous postings.



I have been playing around with producing 32.768 kHz from 10 MHz using
a PIC chip.



I  have a real time clock calendar chip that requires a 32.768 kHz
crystal.  I want to feed it with 10 MHz signal instead, so it is
synchronised to my main 10 MHz in a frequency standard I am designing.



The method I’m using has been documented before where we have two
loops running 9632 times through a 39 instruction loop and
55904 times through a 38 instruction loop, each time toggling the 
output pin.




I have done this and am getting approximately 32.768 kHz with the FM
modulation as described by previous authors.



My question is should I expect exactly 32.76800 kHz (obviously
assuming we use the same 10 MHz to drive the divider and all test
equipment)?



The closest I can get the 32.768 kHz is within about 0.1 Hz.



Does the actual model of PIC chip influence the accuracy?



Regards



Martyn







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


--
WBW,

V.P.
___
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] 10 MHz to 32.768 kHz converter

[Tom Van Baak]

Martyn, Hal, Magnus,

The PIC code for perfect 10 MHz to 32768 Hz division is here:

http://leapsecond.com/pic/src/pd30.asm

For PIC division of 10 MHz to 32768 Hz, each second you want 55904 short 
half-cycles of 38 instructions (38 x 400 ns = 15.2 us) and 9632 long 
half-cycles of 39 instructions (39 x 400 ns = 15.6 us). The average is then 
exactly 65536 half-cycles per second which gives you a 32768 Hz square wave.

Now, when you write code for this, one way is to do all the short cycles and 
then do all the long cycles. The problem with this approach is that the phase 
drifts horribly within each second, by up to 3 milliseconds! It's possible the 
device you feed this signal into will not like that much drift during each 
second.

So an alternative way is to intersperse short cycles and long cycles as 
optimally as possible -- using a binary method reminiscent of the leap year 
algorithm. This keeps the jitter down to within 400 ns. Doing this all within 
38 instructions is a challenge but I came up with a way to do it. See the link 
above.

True, both methods give an average of 32 kHz over 1 second. But the leap cycle 
method has 8000 times less phase drift during each second.

I tested with three "4-pin" PIC dividers:
1) divide 10 MHz ref to 1 Hz with PD07
2) divide 10 MHz ref to 32768 Hz with PD30 and then divide that 32768 Hz to 1 
Hz with PD33
3) compare 1PPS output of PD07 with 1PPS output of PD33

Documentation / source / hex code:
http://leapsecond.com/pic/src/pd07.asm pd07.hex
http://leapsecond.com/pic/src/pd30.asm pd30.hex
http://leapsecond.com/pic/src/pd33.asm pd33.hex

/tvb
___
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] Framework for simulation of oscillators

[KA2WEU--- via time-nuts]

http://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=2270=etd
 
 
 
 
 
 
 
In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time,  
mag...@rubidium.se writes:

Ulrich  and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and  G.825 they 
will not give very detailed information, but hints. The flicker  noise 
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article  "Large 
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up  
correction. Further, they model the amount of noise and add into the  
loop in place of the oscillator, which then has a normal PI-loop. Such a  
simulation can be done fairly efficiently considering that the  
oscillator and loop is very simple linear models of phase, not too  
different to what I proposed. For the stuff that Attila needs to  
simulate, some additional thought needs to go into how to simulate the  
effect he is seeing, but a fairly simple approach should be interesting  
to try out initially.

The Barnes flicker generator  builds on a filter-bank where the 
poles and nulls is placed such that they  approximate the flicker noise 
slope of 1/tau. This is a generalized  variant of Jim Barnes PhD work 
where he had fixed relations and where  Chuck Greenhall have contributed 
significantly by providing means to setup  the state of the filter such 
that the filter will act as a filter in  equilibrium from start, rather 
than taking much time to converge,  something which may introduce a bias 
into the measurement results. I have  re-implemented their BASIC-code 
into C and run Chuck's original code  along-side to verify (just to find 
where I did my mistake in converting  it).

If this simulation approach is sufficient for either of your  efforts, or 
not, depends on what you try to capture. For instance, the  oscillators 
performance have been idealized in assuming fully linear EFC,  fully 
linear integrator of the crystal, assuming noise profile etc. This  may 
or may not be sufficient. Inherent lowpass filtering may be important  or 
not.

I've done PLL simulations many times, in fixed integer, in  floating 
point and in VHDL. It's always a challenge to model it right to  the needs.

Let me also have reader of this thread reminded of TvB's  simulator for a 
GPSDO, which is interesting as it adds real GPS PPS data  and real open 
loop oscillator data with a simple PLL oscillator core you  can then 
tweak. Great fun in all it's simplicity and nice way to do  reality 
check. I've done similar things with about the same code amount  that 
have proved very useful.

However, recall that whenever you  make a model, you do it with 
assumptions for your particular problem, so  some stuff will be left out 
and some will be particular to your problem.  One guys model may be crap 
to another ones problem. There is a few tricks  to be learned and a few 
things to recall to  include.

Cheers,
Magnus

On 03/20/2016 09:19 PM,  ka2...@aol.com wrote:
> I am interested in this topic too, thanks,  Ulrich
> In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight  Time,
> mag...@rubidium.dyndns.org writes:
>
>   Attila,
>
> On 03/17/2016 10:56  AM, Attila Kinali wrote:
>  > Moin,
>   >
>  > Measurement we recently  did showed some quite unexpected behaviour
>  >  and I am trying to figure out where this comes from. For this
>   > I would like to simulate our system, which consists of  multiple
>  > crystal oscillators that are coupled  in a non-linear way (kind of
>  > a vector-PLL  with a step transfer function) with a "loop 
bandwidth"
> > of a few 10kHz.
>  >
>   > My goal is to simulate the noise properties of the  crystal
> oscillators
>   > both short term (in the 10us range) and long term (several  1000
> seconds)
>  > in a  way that models reality closely (ie short term instability
>   is uncorrelated
>  > while long term  instability is correlated through 
temp/humidity/...)
> >
>  > As I am pretty sure not the first  one to attempt something like 
this,
>  > I would  like to ask whether someone has already some software
>   framework
>  > around for this kind  of simulation?
>  >
>   > If not, does someone have pointers how to write realistic
>   oscillator models
>  > for this kind  of short and long term simulation?
>
> It is a  large field that you tries to cover. What you need to do is
>   actually find the model that models the behavior of your physical  
setup.
>
> You need to have white and flicker  noises, there is a few ways to get
> the flicker  coloring. I did some hacking of the setup, and ran tests
>   against Chuck Greenhalls original BASIC  code.
>
> You probably want a systematic effect  model of phase, frequency and
> drift. Also a cubic  frequency vs. temperature. All the properties 
needs
>  to be different for each instance. Similarly, the flicker filter  
needs
> to be independent for each  

Re: [time-nuts] Framework for simulation of oscillators

[KA2WEU--- via time-nuts]

http://joerg-berkner.de/Fachartikel/pdf/2000_AKB_Berkner_1f_noise.pdf
 
 
 
 
 
 
 
 
In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time,  
mag...@rubidium.se writes:

Ulrich  and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and  G.825 they 
will not give very detailed information, but hints. The flicker  noise 
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article  "Large 
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up  
correction. Further, they model the amount of noise and add into the  
loop in place of the oscillator, which then has a normal PI-loop. Such a  
simulation can be done fairly efficiently considering that the  
oscillator and loop is very simple linear models of phase, not too  
different to what I proposed. For the stuff that Attila needs to  
simulate, some additional thought needs to go into how to simulate the  
effect he is seeing, but a fairly simple approach should be interesting  
to try out initially.

The Barnes flicker generator  builds on a filter-bank where the 
poles and nulls is placed such that they  approximate the flicker noise 
slope of 1/tau. This is a generalized  variant of Jim Barnes PhD work 
where he had fixed relations and where  Chuck Greenhall have contributed 
significantly by providing means to setup  the state of the filter such 
that the filter will act as a filter in  equilibrium from start, rather 
than taking much time to converge,  something which may introduce a bias 
into the measurement results. I have  re-implemented their BASIC-code 
into C and run Chuck's original code  along-side to verify (just to find 
where I did my mistake in converting  it).

If this simulation approach is sufficient for either of your  efforts, or 
not, depends on what you try to capture. For instance, the  oscillators 
performance have been idealized in assuming fully linear EFC,  fully 
linear integrator of the crystal, assuming noise profile etc. This  may 
or may not be sufficient. Inherent lowpass filtering may be important  or 
not.

I've done PLL simulations many times, in fixed integer, in  floating 
point and in VHDL. It's always a challenge to model it right to  the needs.

Let me also have reader of this thread reminded of TvB's  simulator for a 
GPSDO, which is interesting as it adds real GPS PPS data  and real open 
loop oscillator data with a simple PLL oscillator core you  can then 
tweak. Great fun in all it's simplicity and nice way to do  reality 
check. I've done similar things with about the same code amount  that 
have proved very useful.

However, recall that whenever you  make a model, you do it with 
assumptions for your particular problem, so  some stuff will be left out 
and some will be particular to your problem.  One guys model may be crap 
to another ones problem. There is a few tricks  to be learned and a few 
things to recall to  include.

Cheers,
Magnus

On 03/20/2016 09:19 PM,  ka2...@aol.com wrote:
> I am interested in this topic too, thanks,  Ulrich
> In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight  Time,
> mag...@rubidium.dyndns.org writes:
>
>   Attila,
>
> On 03/17/2016 10:56  AM, Attila Kinali wrote:
>  > Moin,
>   >
>  > Measurement we recently  did showed some quite unexpected behaviour
>  >  and I am trying to figure out where this comes from. For this
>   > I would like to simulate our system, which consists of  multiple
>  > crystal oscillators that are coupled  in a non-linear way (kind of
>  > a vector-PLL  with a step transfer function) with a "loop 
bandwidth"
> > of a few 10kHz.
>  >
>   > My goal is to simulate the noise properties of the  crystal
> oscillators
>   > both short term (in the 10us range) and long term (several  1000
> seconds)
>  > in a  way that models reality closely (ie short term instability
>   is uncorrelated
>  > while long term  instability is correlated through 
temp/humidity/...)
> >
>  > As I am pretty sure not the first  one to attempt something like 
this,
>  > I would  like to ask whether someone has already some software
>   framework
>  > around for this kind  of simulation?
>  >
>   > If not, does someone have pointers how to write realistic
>   oscillator models
>  > for this kind  of short and long term simulation?
>
> It is a  large field that you tries to cover. What you need to do is
>   actually find the model that models the behavior of your physical  
setup.
>
> You need to have white and flicker  noises, there is a few ways to get
> the flicker  coloring. I did some hacking of the setup, and ran tests
>   against Chuck Greenhalls original BASIC  code.
>
> You probably want a systematic effect  model of phase, frequency and
> drift. Also a cubic  frequency vs. temperature. All the properties 
needs
>  to be different for each instance. Similarly, the flicker filter  
needs
> to be independent for each  

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

Goder afton Attila,

On 03/20/2016 10:20 PM, Attila Kinali wrote:

God kväll Magnus,

On Sun, 20 Mar 2016 20:43:00 +0100
Magnus Danielson  wrote:


If not, does someone have pointers how to write realistic oscillator models
for this kind of short and long term simulation?


It is a large field that you tries to cover. What you need to do is
actually find the model that models the behavior of your physical setup.


Yes, there is quite a bit I need to cover. I started out to put some stuff
together yesterday, but I guess it will take me two or three weeks until
i have something half way usable.


You need to have white and flicker noises, there is a few ways to get
the flicker coloring. I did some hacking of the setup, and ran tests
against Chuck Greenhalls original BASIC code.


I'm currently using the code from Brooker and Inggs[1,2], but the code
is quite convoluted and it will take me some time to extract it and
get it working properly. (but then, it's the only piece of code
that I found that does seem to be viable at all)


Could not get to the article. Looking at the code, it honestly does not 
seem to be very different to that of Barnes


Correction: The generalized method was Barnes (NBS TN604), where 
Greenhall presented a paper on init and then Barnes did an 
aggregated article at PTTI 19, with a correction in PTTI 24.



You probably want a systematic effect model of phase, frequency and
drift. Also a cubic frequency vs. temperature. All the properties needs
to be different for each instance. Similarly, the flicker filter needs
to be independent for each oscillator.


What do you mean with "the flicker filter needs to be independent"?
Each oscillator will get its own noise source, if you mean that.


Yes. When you have a white noise-source, you can take all your samples 
from the same source. With non-white sources, you take white noise and 
filter it, that filtering mechanism holds a state, and if you need two 
or more independent sources, then that state would make the assumption 
of independent sources invalid.



Similar enough things have been tried when simulating the jitter and
wander in the G.823-825 specs.


Thanks, i will have a look at those.


ITU-T G.810-813 is also kind of interesting, with ITU-T G.810 in 
particular. There is a correction for G.810, as I reported a typo in one 
of the formulas. ITU-T G.701 can be also interesting to read and 
contemplate over alongside G.810.



An aspect you need to include is the filtering properties of the EFC
input, it acts like a low-pass filter, and the Q of the resonator is
another catch-point.


The low pass filter is easy to implement, and yes, this will be one
of the first things i need to implement. One of our guesses is, that
this low pass filtering helps us getting the high performance we saw.


I think you should try that first, in a fairly linear model. It should 
help explain the locking at least, which is a good start.



I am not sure yet, how to model the Q, or whether that actually needs
to be modelled with anything else but the proper noise/stability
characteristics and the low pass on the EFC.


Consider that you have an integrator for the oscillator, and a null due 
to the Q. Look at the Leeson model (Feb 1966), see also Enrico's book on 
phase noise.



I wonder how complex model you need to build before you have catched the
characteristics you are after.


The current plan is to implement an oscillator model that mimics the
correct stability i'm seeing, then add EFC (first w/o low pass filtering).
This should already work "properly" and give a first indication on how
the system behaves. Then step by step add the non-idealities, like the
low pass filter on the EFC, the high DNL of the TDC, the noise on the
pulse output and the TDC input, ... until I get close to what we measure.


Just being able to simulate the locking mechanism should be a good 
start. Then you should try to get it to simulate the noise-curves you're 
seeing.





The EFC measures you have done so far indicate that your steering
essentially operates as if you do where doing something similar to
charge-pump operation.


Hmm.. can you elaborate a bit on why you think so?


The correction pulse every now and then is how a charge-pump PLL 
operates. In between the corrections the oscillator coasts undiciplined 
with the filters state as memory. The 4046 charge-pump has a dead-band 
which was very annoying as it was only as the phase coasted outside of 
the dead-band that a correction to go back occurred. The pulses you 
mentioned sounds like quite similar. For higher frequencies, they will 
be uncorrected, so only at about the rate of the corrections will the 
oscillators cooperate and lower the performance, and only the ones being 
outside of the limits will experience this push inwards.


Something according to those lines might be where your systems behavior 
can be explained.


Gardner would be a good reference. He was not so 

Re: [time-nuts] 10 MHz to 32.768 kHz converter

[Tom Van Baak]

Hi Martyn,

> I have been playing around with producing 32.768 kHz from 10 MHz using a PIC 
> chip.
> I have a real time clock calendar chip that requires a 32.768 kHz crystal.  I 
> want to feed it with 10 MHz
> signal instead, so it is synchronised to my main 10 MHz in a frequency 
> standard I am designing.

This thread may also be of interest:
https://www.febo.com/pipermail/time-nuts/2008-October/034020.html
https://www.febo.com/pipermail/time-nuts/2012-February/063557.html


> The method I’m using has been documented before where we have two loops 
> running 9632 times through
> a 39 instruction loop and 55904 times through a 38 instruction loop, each 
> time toggling the output pin.

That's one way. Here two methods are tested, both on a PC and on a PIC:
http://www.leapsecond.com/tools/10m32k.c


> I have done this and am getting approximately 32.768 kHz with the FM 
> modulation as described by previous authors.
> My question is should I expect exactly 32.76800 kHz
> (obviously assuming we use the same 10 MHz to drive the divider and all test 
> equipment)?
> The closest I can get the 32.768 kHz is within about 0.1 Hz.

When the PIC is in its 38 instruction loop the instantaneous output frequency 
is 32894.736842 Hz.
When the PIC is in its 39 instruction loop the instantaneous output frequency 
is 32051.282051 Hz.

Over exactly 1 second the average loop is 38.14697265625 instructions so the 
average frequency is 32768.00 Hz. However, because of the PWM-like output, 
and depending on your gate time, your frequency counter may get confused and 
give readings between 32.1 kHz and 32.8 kHz, depending on which loop it sees at 
any given moment. If your frequency counter can generate exactly 1 second gate 
time in theory you should see an output of 32.76800 kHz. What gate time are 
you using? What counter are you using? For testing a chip like this it's much 
better to use a totalizing or time interval counter instead of a frequency 
counter.

But here's an easier way to test your 10 MHz-to-32768 Hz divider:

1) divide your 10 MHz to 1 Hz with my PD07 
(http://leapsecond.com/pic/src/pd07.asm)
2) divide same 10 MHz to 32768 Hz with your divider
3) divide said 32768 Hz to 1 Hz with my PD33 
(http://leapsecond.com/pic/src/pd33.asm).
4) use a TIC to compare both 1 Hz signals

If the TI readings are constant you're done. If there's drift, then you have a 
cycle counting error.


> Does the actual model of PIC chip influence the accuracy?

No. I use PIC12F675 for all my dividers, but any PIC will work. You could use 
AVR too, adjusting the loop timings accordingly.

/tvb



- Original Message - 
From: "Martyn Smith" 
To: 
Cc: "'DM'" 
Sent: Sunday, March 20, 2016 11:26 AM
Subject: [time-nuts] 10 MHz to 32.768 kHz converter


Hello,

 

First of all quick apologies for sending an email last week without deleting 
all the old information from previous postings.  

 

I have been playing around with producing 32.768 kHz from 10 MHz using a PIC 
chip.

 

I  have a real time clock calendar chip that requires a 32.768 kHz crystal.  I 
want to feed it with 10 MHz signal instead, so it is synchronised to my main 10 
MHz in a frequency standard I am designing.

 

The method I’m using has been documented before where we have two loops running 
9632 times through a 39 instruction loop and 
55904 times through a 38 instruction loop, each time toggling the output pin.

 

I have done this and am getting approximately 32.768 kHz with the FM modulation 
as described by previous authors.

 

My question is should I expect exactly 32.76800 kHz (obviously assuming we 
use the same 10 MHz to drive the divider and all test equipment)?

 

The closest I can get the 32.768 kHz is within about 0.1 Hz.

 

Does the actual model of PIC chip influence the accuracy?

 

Regards

 

Martyn

 

 

 

___
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] 10 MHz to 32.768 kHz converter

[Hal Murray]

mar...@ptsyst.com said:
> My question is should I expect exactly 32.76800 kHz (obviously assuming
> we use the same 10 MHz to drive the divider and all test equipment)?

Yes, as long as you are feeding the same reference to your counter and your 
divider you should get an exact answer.

> The closest I can get the 32.768 kHz is within about 0.1 Hz.

How accurate is your counter?

Do the arithmetic and count cycles.  You may be able to figure out how many 
cycles you are off.  You can try different chunks of code to verify that they 
are doing what you expect.  Or put trigger a scope on a PPS and see if the 32 
KHz is drifting.

> Does the actual model of PIC chip influence the accuracy?

Compare the cycle counts on the instructions.  I expect them to be the same, 
but I haven't compared various PIC versions in a long time.



-- 
These are my opinions.  I hate spam.



___
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] 10 MHz to 32.768 kHz converter

[Magnus Danielson]

Martyn,

On 03/20/2016 07:26 PM, Martyn Smith wrote:

Hello,

First of all quick apologies for sending an email last week without deleting 
all the old information from previous postings.

I have been playing around with producing 32.768 kHz from 10 MHz using a PIC 
chip.

I  have a real time clock calendar chip that requires a 32.768 kHz crystal.  I 
want to feed it with 10 MHz signal instead, so it is synchronised to my main 10 
MHz in a frequency standard I am designing.

The method I’m using has been documented before where we have two loops running 
9632 times through a 39 instruction loop and
55904 times through a 38 instruction loop, each time toggling the output pin.

I have done this and am getting approximately 32.768 kHz with the FM modulation 
as described by previous authors.

My question is should I expect exactly 32.76800 kHz (obviously assuming we 
use the same 10 MHz to drive the divider and all test equipment)?

The closest I can get the 32.768 kHz is within about 0.1 Hz.

Does the actual model of PIC chip influence the accuracy?


10 MHz and 32,768 kHz does not have an easy relationship.

10 MHz = 10^7 = 2^7 * 5^7 Hz
32768 Hz = 2^15

So, for 5^7 10 MHz cycles you will run 2^8 32,768 kHz cycles.

There is no way to divide down straight, and most DDSes only operates on 
2^n basis which does not resolve the 5^7 factor accurately.


So, what you have to do is to use your divider (PIC in this case) to 
consume an extra cycle here and there, with some logic to decide when.
Then you can accurately produce the frequency. A DDS with length being 
10^7 (or at least have a length being multiple of 5^7) can produce it 
directly. The alternating division factor can be made to work correctly, 
but it will produce phase deviations, being up to a 32,768 kHz cycle 
(more if you do it sloppy).


Think of it as accumulating the error and correct for it as you go, both 
approaches do that.


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] Framework for simulation of oscillators

[Attila Kinali]

God kväll Magnus,

On Sun, 20 Mar 2016 20:43:00 +0100
Magnus Danielson  wrote:

> > If not, does someone have pointers how to write realistic oscillator models
> > for this kind of short and long term simulation?
> 
> It is a large field that you tries to cover. What you need to do is 
> actually find the model that models the behavior of your physical setup.

Yes, there is quite a bit I need to cover. I started out to put some stuff
together yesterday, but I guess it will take me two or three weeks until
i have something half way usable.
 
> You need to have white and flicker noises, there is a few ways to get 
> the flicker coloring. I did some hacking of the setup, and ran tests 
> against Chuck Greenhalls original BASIC code.

I'm currently using the code from Brooker and Inggs[1,2], but the code
is quite convoluted and it will take me some time to extract it and
get it working properly. (but then, it's the only piece of code
that I found that does seem to be viable at all)

> You probably want a systematic effect model of phase, frequency and 
> drift. Also a cubic frequency vs. temperature. All the properties needs 
> to be different for each instance. Similarly, the flicker filter needs 
> to be independent for each oscillator.

What do you mean with "the flicker filter needs to be independent"?
Each oscillator will get its own noise source, if you mean that.

> Similar enough things have been tried when simulating the jitter and 
> wander in the G.823-825 specs.

Thanks, i will have a look at those.


> An aspect you need to include is the filtering properties of the EFC 
> input, it acts like a low-pass filter, and the Q of the resonator is 
> another catch-point.

The low pass filter is easy to implement, and yes, this will be one
of the first things i need to implement. One of our guesses is, that
this low pass filtering helps us getting the high performance we saw.
I am not sure yet, how to model the Q, or whether that actually needs
to be modelled with anything else but the proper noise/stability
characteristics and the low pass on the EFC.
 
> I wonder how complex model you need to build before you have catched the 
> characteristics you are after.

The current plan is to implement an oscillator model that mimics the
correct stability i'm seeing, then add EFC (first w/o low pass filtering).
This should already work "properly" and give a first indication on how
the system behaves. Then step by step add the non-idealities, like the
low pass filter on the EFC, the high DNL of the TDC, the noise on the
pulse output and the TDC input, ... until I get close to what we measure.


> The EFC measures you have done so far indicate that your steering 
> essentially operates as if you do where doing something similar to 
> charge-pump operation.

Hmm.. can you elaborate a bit on why you think so?



Attila Kinali


[1] "Efficient Generation of f^a Noise Sequences for Pulsed Radar Simulation",
by Brooker, Inggs, 2010
http://dx.doi.org/10.1109/TAES.2010.5461653

[2] http://rrsg.ee.uct.ac.za/fers/

-- 
Reading can seriously damage your ignorance.
-- unknown
___
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] Framework for simulation of oscillators

[KA2WEU--- via time-nuts]

Thanks, Ulrich
 
 
In a message dated 3/20/2016 5:33:21 P.M. Eastern Daylight Time,  
mag...@rubidium.se writes:

Ulrich  and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and  G.825 they 
will not give very detailed information, but hints. The flicker  noise 
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article  "Large 
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up  
correction. Further, they model the amount of noise and add into the  
loop in place of the oscillator, which then has a normal PI-loop. Such a  
simulation can be done fairly efficiently considering that the  
oscillator and loop is very simple linear models of phase, not too  
different to what I proposed. For the stuff that Attila needs to  
simulate, some additional thought needs to go into how to simulate the  
effect he is seeing, but a fairly simple approach should be interesting  
to try out initially.

The Barnes flicker generator  builds on a filter-bank where the 
poles and nulls is placed such that they  approximate the flicker noise 
slope of 1/tau. This is a generalized  variant of Jim Barnes PhD work 
where he had fixed relations and where  Chuck Greenhall have contributed 
significantly by providing means to setup  the state of the filter such 
that the filter will act as a filter in  equilibrium from start, rather 
than taking much time to converge,  something which may introduce a bias 
into the measurement results. I have  re-implemented their BASIC-code 
into C and run Chuck's original code  along-side to verify (just to find 
where I did my mistake in converting  it).

If this simulation approach is sufficient for either of your  efforts, or 
not, depends on what you try to capture. For instance, the  oscillators 
performance have been idealized in assuming fully linear EFC,  fully 
linear integrator of the crystal, assuming noise profile etc. This  may 
or may not be sufficient. Inherent lowpass filtering may be important  or 
not.

I've done PLL simulations many times, in fixed integer, in  floating 
point and in VHDL. It's always a challenge to model it right to  the needs.

Let me also have reader of this thread reminded of TvB's  simulator for a 
GPSDO, which is interesting as it adds real GPS PPS data  and real open 
loop oscillator data with a simple PLL oscillator core you  can then 
tweak. Great fun in all it's simplicity and nice way to do  reality 
check. I've done similar things with about the same code amount  that 
have proved very useful.

However, recall that whenever you  make a model, you do it with 
assumptions for your particular problem, so  some stuff will be left out 
and some will be particular to your problem.  One guys model may be crap 
to another ones problem. There is a few tricks  to be learned and a few 
things to recall to  include.

Cheers,
Magnus

On 03/20/2016 09:19 PM,  ka2...@aol.com wrote:
> I am interested in this topic too, thanks,  Ulrich
> In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight  Time,
> mag...@rubidium.dyndns.org writes:
>
>   Attila,
>
> On 03/17/2016 10:56  AM, Attila Kinali wrote:
>  > Moin,
>   >
>  > Measurement we recently  did showed some quite unexpected behaviour
>  >  and I am trying to figure out where this comes from. For this
>   > I would like to simulate our system, which consists of  multiple
>  > crystal oscillators that are coupled  in a non-linear way (kind of
>  > a vector-PLL  with a step transfer function) with a "loop 
bandwidth"
> > of a few 10kHz.
>  >
>   > My goal is to simulate the noise properties of the  crystal
> oscillators
>   > both short term (in the 10us range) and long term (several  1000
> seconds)
>  > in a  way that models reality closely (ie short term instability
>   is uncorrelated
>  > while long term  instability is correlated through 
temp/humidity/...)
> >
>  > As I am pretty sure not the first  one to attempt something like 
this,
>  > I would  like to ask whether someone has already some software
>   framework
>  > around for this kind  of simulation?
>  >
>   > If not, does someone have pointers how to write realistic
>   oscillator models
>  > for this kind  of short and long term simulation?
>
> It is a  large field that you tries to cover. What you need to do is
>   actually find the model that models the behavior of your physical  
setup.
>
> You need to have white and flicker  noises, there is a few ways to get
> the flicker  coloring. I did some hacking of the setup, and ran tests
>   against Chuck Greenhalls original BASIC  code.
>
> You probably want a systematic effect  model of phase, frequency and
> drift. Also a cubic  frequency vs. temperature. All the properties 
needs
>  to be different for each instance. Similarly, the flicker filter  
needs
> to be independent for each  oscillator.
>
> Similar enough things have been  tried when 

Re: [time-nuts] Framework for simulation of oscillators

[Magnus Danielson]

Ulrich and Attila,

As you read the appendixes of ITU-T Rec. G.823, G.824 and G.825 they 
will not give very detailed information, but hints. The flicker noise 
model comes from Jim Barnes and Chuck Greenhalls PTTI 19 article "Large 
Sample Simulation of Flicker Noise". Be aware of Chuck's follow-up 
correction. Further, they model the amount of noise and add into the 
loop in place of the oscillator, which then has a normal PI-loop. Such a 
simulation can be done fairly efficiently considering that the 
oscillator and loop is very simple linear models of phase, not too 
different to what I proposed. For the stuff that Attila needs to 
simulate, some additional thought needs to go into how to simulate the 
effect he is seeing, but a fairly simple approach should be interesting 
to try out initially.


The Barnes flicker generator builds on a filter-bank where the 
poles and nulls is placed such that they approximate the flicker noise 
slope of 1/tau. This is a generalized variant of Jim Barnes PhD work 
where he had fixed relations and where Chuck Greenhall have contributed 
significantly by providing means to setup the state of the filter such 
that the filter will act as a filter in equilibrium from start, rather 
than taking much time to converge, something which may introduce a bias 
into the measurement results. I have re-implemented their BASIC-code 
into C and run Chuck's original code along-side to verify (just to find 
where I did my mistake in converting it).


If this simulation approach is sufficient for either of your efforts, or 
not, depends on what you try to capture. For instance, the oscillators 
performance have been idealized in assuming fully linear EFC, fully 
linear integrator of the crystal, assuming noise profile etc. This may 
or may not be sufficient. Inherent lowpass filtering may be important or 
not.


I've done PLL simulations many times, in fixed integer, in floating 
point and in VHDL. It's always a challenge to model it right to the needs.


Let me also have reader of this thread reminded of TvB's simulator for a 
GPSDO, which is interesting as it adds real GPS PPS data and real open 
loop oscillator data with a simple PLL oscillator core you can then 
tweak. Great fun in all it's simplicity and nice way to do reality 
check. I've done similar things with about the same code amount that 
have proved very useful.


However, recall that whenever you make a model, you do it with 
assumptions for your particular problem, so some stuff will be left out 
and some will be particular to your problem. One guys model may be crap 
to another ones problem. There is a few tricks to be learned and a few 
things to recall to include.


Cheers,
Magnus

On 03/20/2016 09:19 PM, ka2...@aol.com wrote:

I am interested in this topic too, thanks, Ulrich
In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time,
mag...@rubidium.dyndns.org writes:

Attila,

On 03/17/2016 10:56 AM, Attila Kinali wrote:
 > Moin,
 >
 > Measurement we recently did showed some quite unexpected behaviour
 > and I am trying to figure out where this comes from. For this
 > I would like to simulate our system, which consists of multiple
 > crystal oscillators that are coupled in a non-linear way (kind of
 > a vector-PLL with a step transfer function) with a "loop bandwidth"
 > of a few 10kHz.
 >
 > My goal is to simulate the noise properties of the crystal
oscillators
 > both short term (in the 10us range) and long term (several 1000
seconds)
 > in a way that models reality closely (ie short term instability
is uncorrelated
 > while long term instability is correlated through temp/humidity/...)
 >
 > As I am pretty sure not the first one to attempt something like this,
 > I would like to ask whether someone has already some software
framework
 > around for this kind of simulation?
 >
 > If not, does someone have pointers how to write realistic
oscillator models
 > for this kind of short and long term simulation?

It is a large field that you tries to cover. What you need to do is
actually find the model that models the behavior of your physical setup.

You need to have white and flicker noises, there is a few ways to get
the flicker coloring. I did some hacking of the setup, and ran tests
against Chuck Greenhalls original BASIC code.

You probably want a systematic effect model of phase, frequency and
drift. Also a cubic frequency vs. temperature. All the properties needs
to be different for each instance. Similarly, the flicker filter needs
to be independent for each oscillator.

Similar enough things have been tried when simulating the jitter and
wander in the G.823-825 specs.

An aspect you need to include is the filtering properties of the EFC
input, it acts like a low-pass filter, and the Q of the resonator is
another catch-point.

I wonder how 

Re: [time-nuts] Framework for simulation of oscillators

[KA2WEU--- via time-nuts]

 
I am interested in this topic too, thanks, Ulrich 

 
 
In a message dated 3/20/2016 4:10:12 P.M. Eastern Daylight Time,  
mag...@rubidium.dyndns.org writes:

Attila,

On 03/17/2016 10:56 AM, Attila Kinali wrote:
>  Moin,
>
> Measurement we recently did showed some quite unexpected  behaviour
> and I am trying to figure out where this comes from. For  this
> I would like to simulate our system, which consists of  multiple
> crystal oscillators that are coupled in a non-linear way  (kind of
> a vector-PLL with a step transfer function) with a "loop  bandwidth"
> of a few 10kHz.
>
> My goal is to simulate the  noise properties of the crystal oscillators
> both short term (in the  10us range) and long term (several 1000 seconds)
> in a way that models  reality closely (ie short term instability is 
uncorrelated
> while long  term instability is correlated through temp/humidity/...)
>
> As I  am pretty sure not the first one to attempt something like this,
> I  would like to ask whether someone has already some software framework
>  around for this kind of simulation?
>
> If not, does someone have  pointers how to write realistic oscillator 
models
> for this kind of  short and long term simulation?

It is a large field that you tries to  cover. What you need to do is 
actually find the model that models the  behavior of your physical setup.

You need to have white and flicker  noises, there is a few ways to get 
the flicker coloring. I did some  hacking of the setup, and ran tests 
against Chuck Greenhalls original  BASIC code.

You probably want a systematic effect model of phase,  frequency and 
drift. Also a cubic frequency vs. temperature. All the  properties needs 
to be different for each instance. Similarly, the flicker  filter needs 
to be independent for each oscillator.

Similar enough  things have been tried when simulating the jitter and 
wander in the  G.823-825 specs.

An aspect you need to include is the filtering  properties of the EFC 
input, it acts like a low-pass filter, and the Q of  the resonator is 
another catch-point.

I wonder how complex model  you need to build before you have catched the 
characteristics you are  after.

The EFC measures you have done so far indicate that your  steering 
essentially operates as if you do where doing something similar  to 
charge-pump  operation.

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.

___
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] 10 MHz to 32.768 kHz converter

[Martyn Smith]

Hello,

 

First of all quick apologies for sending an email last week without deleting 
all the old information from previous postings.  

 

I have been playing around with producing 32.768 kHz from 10 MHz using a PIC 
chip.

 

I  have a real time clock calendar chip that requires a 32.768 kHz crystal.  I 
want to feed it with 10 MHz signal instead, so it is synchronised to my main 10 
MHz in a frequency standard I am designing.

 

The method I’m using has been documented before where we have two loops running 
9632 times through a 39 instruction loop and 
55904 times through a 38 instruction loop, each time toggling the output pin.

 

I have done this and am getting approximately 32.768 kHz with the FM modulation 
as described by previous authors.

 

My question is should I expect exactly 32.76800 kHz (obviously assuming we 
use the same 10 MHz to drive the divider and all test equipment)?

 

The closest I can get the 32.768 kHz is within about 0.1 Hz.

 

Does the actual model of PIC chip influence the accuracy?

 

Regards

 

Martyn

 

 

 

___
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] Framework for simulation of oscillators

[Magnus Danielson]

Attila,

On 03/17/2016 10:56 AM, Attila Kinali wrote:

Moin,

Measurement we recently did showed some quite unexpected behaviour
and I am trying to figure out where this comes from. For this
I would like to simulate our system, which consists of multiple
crystal oscillators that are coupled in a non-linear way (kind of
a vector-PLL with a step transfer function) with a "loop bandwidth"
of a few 10kHz.

My goal is to simulate the noise properties of the crystal oscillators
both short term (in the 10us range) and long term (several 1000 seconds)
in a way that models reality closely (ie short term instability is uncorrelated
while long term instability is correlated through temp/humidity/...)

As I am pretty sure not the first one to attempt something like this,
I would like to ask whether someone has already some software framework
around for this kind of simulation?

If not, does someone have pointers how to write realistic oscillator models
for this kind of short and long term simulation?


It is a large field that you tries to cover. What you need to do is 
actually find the model that models the behavior of your physical setup.


You need to have white and flicker noises, there is a few ways to get 
the flicker coloring. I did some hacking of the setup, and ran tests 
against Chuck Greenhalls original BASIC code.


You probably want a systematic effect model of phase, frequency and 
drift. Also a cubic frequency vs. temperature. All the properties needs 
to be different for each instance. Similarly, the flicker filter needs 
to be independent for each oscillator.


Similar enough things have been tried when simulating the jitter and 
wander in the G.823-825 specs.


An aspect you need to include is the filtering properties of the EFC 
input, it acts like a low-pass filter, and the Q of the resonator is 
another catch-point.


I wonder how complex model you need to build before you have catched the 
characteristics you are after.


The EFC measures you have done so far indicate that your steering 
essentially operates as if you do where doing something similar to 
charge-pump operation.


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] Thunderbolt Serial Port Shutdown

[Artek Manuals]

On 3/20/2016 2:10 AM, Dave Brown wrote:

Are there any circumstances when the Thunderbolt serial port is disabled
by firmware?  My TB runs 24/7 but stopped the night before last for no
apparent reason.   I only discoverd this when I checked Lady Heather
early yesterday.(19 March) LH had stopped with a 'no data' warning late
on the 18th Feb. I initially restarted LH but to no avail, then powered
off the Thunderbolt briefly-again to no avail. I then left it powered
off for over 24 hrs and restarted it around mid-afternoon today (20
March) and now, after about four hours running normally, it seems like
all is back to normal. Just running Tboltmon at present but will go back
to LH later tonight.
DaveB, NZ


DaveB

If I read this correctly . You restarted the program and you power 
cycled the T-Bolt ?


What does your serial computer interface look like? is it an older style 
dedicated DB9 port on the computer or are you using a USB/Serial interface?


. If this occurs again I would also try rebooting the computer  before I 
power cycled the T-Bolt


Dave
NR1DX

--
Dave
manu...@artekmanuals.com
www.ArtekManuals.com

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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] Thunderbolt Serial Port Shutdown

[Tom Van Baak]

Dave,

Make sure your -12 volt supply is valid. It's used by the UART. Anything from 
-7 to -12 should be ok.

Here's the wiring diagram:

http://www.leapsecond.com/pages/tbolt/power.htm

/tvb

- Original Message - 
From: "Dave Brown" 
To: "Discussion of precise time and frequency measurement" 
Sent: Saturday, March 19, 2016 11:10 PM
Subject: [time-nuts] Thunderbolt Serial Port Shutdown


> Are there any circumstances when the Thunderbolt serial port is disabled by 
> firmware?  My TB runs 24/7 but stopped the night before last for no apparent 
> reason.   I only discoverd this when I checked Lady Heather early 
> yesterday.(19 March) LH had stopped with a 'no data' warning late on the 
> 18th Feb. I initially restarted LH but to no avail, then powered off the 
> Thunderbolt briefly-again to no avail. I then left it powered off for over 
> 24 hrs and restarted it around mid-afternoon today (20 March) and now, after 
> about four hours running normally, it seems like all is back to normal. Just 
> running Tboltmon at present but will go back to LH later tonight.
> DaveB, NZ
> 
> 
> 
> 
> 
> ___
> 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] Thunderbolt Serial Port Shutdown

[Mike Naruta AA8K]

I have seen something similar with one of my Trimble 
Thunderbolts that I got through this group.  After weeks of 
operation, the serial port stops responding and a power-cycle 
has it communicating again.


Firmware A002206.G1  Rev E

Running on OpenHPSDR LPU analog power supply that gets 13.6 
volts from a pair of 6 volt golf cart batteries in series that 
are charged from AC mains.


Serial port is normally disconnected; attached to MS Windows PC 
with Lady Heather when I am interested in data.


I bought a third Thunderbolt on eBay and it does not fail.  The 
second of the two Thunderbolts I got through this group in 2008 
does not fail either (same firmware).



On 03/20/2016 02:10 AM, Dave Brown wrote:

Are there any circumstances when the Thunderbolt serial port is
disabled by firmware?  My TB runs 24/7 but stopped the night
before last for no apparent reason.   I only discovered this when
I checked Lady Heather early yesterday.(19 March) LH had stopped
with a 'no data' warning late on the 18th Feb. I initially
restarted LH but to no avail, then powered off the Thunderbolt
briefly-again to no avail. I then left it powered off for over
24 hrs and restarted it around mid-afternoon today (20 March)
and now, after about four hours running normally, it seems like
all is back to normal. Just running Tboltmon at present but will
go back to LH later tonight.
DaveB, NZ



___
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] Thunderbolt Serial Port Shutdown

[Bob Camp]

Hi

Check the solder joints on the 9 pin serial connector. Your TBolt would not be 
the first to come back to live after a questionable joint on the PC board was 
touched up.

Bob


> On Mar 20, 2016, at 2:10 AM, Dave Brown  wrote:
> 
> Are there any circumstances when the Thunderbolt serial port is disabled by 
> firmware?  My TB runs 24/7 but stopped the night before last for no apparent 
> reason.   I only discoverd this when I checked Lady Heather early 
> yesterday.(19 March) LH had stopped with a 'no data' warning late on the 18th 
> Feb. I initially restarted LH but to no avail, then powered off the 
> Thunderbolt briefly-again to no avail. I then left it powered off for over 24 
> hrs and restarted it around mid-afternoon today (20 March) and now, after 
> about four hours running normally, it seems like all is back to normal. Just 
> running Tboltmon at present but will go back to LH later tonight.
> DaveB, NZ
> 
> 
> 
> 
> 
> ___
> 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] Thunderbolt Serial Port Shutdown

[Dave Brown]

Are there any circumstances when the Thunderbolt serial port is disabled by 
firmware?  My TB runs 24/7 but stopped the night before last for no apparent 
reason.   I only discoverd this when I checked Lady Heather early 
yesterday.(19 March) LH had stopped with a 'no data' warning late on the 
18th Feb. I initially restarted LH but to no avail, then powered off the 
Thunderbolt briefly-again to no avail. I then left it powered off for over 
24 hrs and restarted it around mid-afternoon today (20 March) and now, after 
about four hours running normally, it seems like all is back to normal. Just 
running Tboltmon at present but will go back to LH later tonight.

DaveB, NZ





___
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] Microsonics TCXO

[Gary Woods]

On Sun, 20 Mar 2016 08:47:01 -0500, you wrote:

>An even better solution would have been to put them on the 'exact' same
>frequency and phase, but the digital electronics and GPS frequency/timing
>systems that could enable that, had not been deployed yet.

Which gets you major nulls, assuming the receiver is moving.  See also:
WBZ/WBZA back in the day.


-- 
Gary Woods AKA K2AHC- PGP key on request, or at home.earthlink.net/~garygarlic
Zone 5/4 in upstate New York, 1420' elevation. NY WO G
___
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] plug: SDGPS on Kickstarter

[jimlux]

On 3/19/16 3:08 AM, j...@jks.com wrote:

I'll adopt Didier's notation here


Although it's marketed as an SDR for the BeagleBone, this project contains an 
open source 12+ channel software-defined GPS receiver:
https://www.kickstarter.com/projects/1575992013/kiwisdr-beaglebone-software-defined-radio-sdr-with/

It's very easy to experiment with GPS signal processing by changing the C++ code on 
the Beagle or the Verilog on the FPGA (provided you have the stomach to install the 
Xilinx Vivado design tools). For example, I learned a lot by adding decimation to the 
correlation code. This speeds up strong signal acquisition because the FFTs can be 
smaller. The SDGPS is from Andrew Holme's Homemade GPS Receiver project 




and jks.com appears to be slashdotted, very, very slow response 
downloading the design doc.


Good luck to you folks with the board.


___
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] Microsonics TCXO

[Graham / KE9H]

Joe:

In that time frame, there were a lot of "simulcast" analog radio, police,
pager,
and TV systems, where different broadcast transmitter locations transmitted
the
same information on the same frequencies.  The goal was to have strong
signals
across a large (overlapping) combined coverage area.

For the systems to work with minimum interference in the RF signal overlap
zones, the transmitters needed to be at slight, but precision offsets.
These
could have been master oscillators for those systems.

An even better solution would have been to put them on the 'exact' same
frequency and phase, but the digital electronics and GPS frequency/timing
systems that could enable that, had not been deployed yet.

1979 ::   No PC's, no cell systems deployed, microprocessors were eight bit,
with clock speeds below 10 MHz, communication systems were mostly analog.
Long time ago according to Moore's Law.

https://upload.wikimedia.org/wikipedia/commons/0/00/Transistor_Count_and_Moore's_Law_-_2011.svg

--- Graham / KE9H

==

On Sun, Mar 20, 2016 at 12:42 AM, Joseph Gray  wrote:

> I got my hands on some of these.
>
> https://dl.dropboxusercontent.com/u/19599147/TCXO%20Top.jpg
>
> https://dl.dropboxusercontent.com/u/19599147/TCXO%20Bottom.jpg
>
> A search finds other Microsonics units, but not this one. I can't find
> any information on what voltage to feed this. Does anyone know?
>
> I know that these aren't Time Nuts grade, but I am curious to see how
> good/bad they are. They look to be NOS from 1979.
>
> Some of the other samples are marked as being set to anywhere from 1
> Hz to 7 Hz high or low. Why would they have been factory adjusted high
> or low?
>
>
> Joe Gray
> W5JG
> ___
> 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] Fw: 5065

[Oz-in-DFW]

On 3/19/2016 1:43 AM, tim...@timeok.it wrote:
>
>
>
> Tom,
> it is not, see the Farnell code below followed by Amphenol part number:
>
>
> Farnell code: 1914117 pn 97-3106A18-22S connector
> Farnell code: 1654733 pn 9779-513-8 plastic ring
> Farnell code: 151628 pn 97-3057-1010-1 cable clamp and bush
>
> see also: 
> http://canada.newark.com/amphenol-industrial/97-3106a-18-22s/circular-connector-plug-3-position/dp/74C6856
>
> Luciano
> www.timeok.it
>
> Message sent via Atmail Open - http://atmail.org/
> ___
> 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.

If you are in the US, Mouser's price and delivery for these is MUCH
better. They show 7 in stock. Mouser also has a presence in the EU and
some places in Asia, but I can't see the pricing or availability

-- 
mailto:o...@ozindfw.net
Oz
POB 93167 
Southlake, TX 76092 (Near DFW Airport) 



___
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] Microsonics TCXO

[Bob Camp]

HI

The parts would have been set to the offset marked on the can. In the case of 
the one in the picture that would have been dead on frequency. The offset is 
used
to center up the frequency vs temperature curve. Since they are a TCXO, that 
curve 
may be as high as a 6th or 8th order curve. There was no practical way to get 
it 
to go through zero at 25C. If the offsets spread over +/- 7 Hz at 10 MHz, it’s 
a pretty 
good bet that you have 1 ppm TCXO’s. 

Bob


> On Mar 20, 2016, at 1:42 AM, Joseph Gray  wrote:
> 
> I got my hands on some of these.
> 
> https://dl.dropboxusercontent.com/u/19599147/TCXO%20Top.jpg
> 
> https://dl.dropboxusercontent.com/u/19599147/TCXO%20Bottom.jpg
> 
> A search finds other Microsonics units, but not this one. I can't find
> any information on what voltage to feed this. Does anyone know?
> 
> I know that these aren't Time Nuts grade, but I am curious to see how
> good/bad they are. They look to be NOS from 1979.
> 
> Some of the other samples are marked as being set to anywhere from 1
> Hz to 7 Hz high or low. Why would they have been factory adjusted high
> or low?
> 
> 
> Joe Gray
> W5JG
> ___
> 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] Difference between Oncore models

[Joseph Gray]

Thanks to all for the comments. I recently traded for another Z3801A
that I was told didn't work. I don't know what is wrong with it, as I
haven't had time to put it on the bench yet. I understand that the
OCXO is putting out a decent 10 MHz, so perhaps it also has a bad
Oncore.

Joe Gray
W5JG


On Wed, Mar 16, 2016 at 3:56 PM, Artek Manuals  wrote:
> Joe
>
> The newer Motorola VP-Oncore  receivers are known to be an improved design
> over the original Oncores that came with the Z3801A's .
>
> I have recently done some  side by side comparison's with two z3801A's on
> the same antenna the newer Vp-Oncore's ran SS numbers 15-30 points higher on
> the same bird than the older receiver. In all fairness the older receiver is
> on its last legs (see last paragraph below)
>
> I also found out that there are two versions of the newer VP-Oncore. These
> can be distinguished by the antenna connector, One version has a right-angle
> chassis mounted connector like the original 6CH Oncore, the 2nd version has
> a straight on antenna connector. This 2nd version while they will work in a
> Z3801A, have an interference fit problem with a an IC  on the board below
> when the antenna cable is plugged in and you can't tighten down all the
> receiver board mounting screws. I am told that the straight on version fits
> the Z3816A with no problem. I have not verified this since I don't have a
> Z3816. I have no info  on the other Z38xx models and the fit of the later
> VP-Oncore
>
> The older 6ch Oncore receivers receivers are beginning to die apparently.  I
> have had one fail here a few months ago and recently acquired a 2nd Z3801A
> that is displaying similar symptoms to the first failure in that the
> receiver just stops working after a few hours...over time the symptom  are
> the receiver drops out for no apparent reason then revives if the unit is
> powered off for a while. Over time the time to receiver drop out gets
> shorter and shorter after each successive power cycle, I have one receiver
> that will now fail within 20 minutes predictably.
>
> Dave
> NR1DX
>
>
>
>
> On 3/16/2016 7:03 AM, Joseph Gray wrote:
>>
>> I understand that the Oncore GPS in the Lucent units is a newer module
>> that tracks eight satellites, vs the older Oncore in the Z3801A that
>> only tracks six satellites.
>>
>> I decided to do a re-survey with my Z3801A that has been in holdover
>> for some time, just as a test. Watching the status screens from both
>> GPSDOs, both are seeing the same number of satellites, however, the
>> Z3801A is consistently locking to 3-4 fewer than the Lucent.
>>
>> This begs the question, is the older Oncore module that deaf, or is
>> mine defective. BTW, same antenna on a 4-port splitter, same elevation
>> mask.
>>
>> Joe Gray
>> W5JG
>> ___
>> 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.
>>
>
>
> --
> Dave
> manu...@artekmanuals.com
> www.ArtekManuals.com
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> 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] Lucent GPS UTC confusion

[Joseph Gray]

Hal,

I did the "*TST?" command, which seemed to do a power cycle. The
Status screen shows "GPS 1PPS Synchronized to UTC".

Joe Gray
W5JG


On Wed, Mar 16, 2016 at 11:30 PM, Hal Murray  wrote:
>
> jg...@zianet.com said:
>> I noticed on the Status screen that the Lucent unit said the PPS was locked
>> to GPS, not UTC, as the Z3801A is. So, I issued ":DIAG:GPS:UTC 1" and "TST?"
>> to correct this.
>
>> But things are not as I expected. Displaying the clock for both GPSDO's in
>> Z38xx now shows them to be 17 seconds different, which is of course the leap
>> seconds.
>
>> This seems backwards. With both units set to UTC, why are they showing
>> different times?
>
> My notes about that include "needs power cycle"
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> 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] Z3801A recovering

[Artek Manuals]

Joe

I am confused by the fact that it shows the unit has been in HOLDOVER 
for 496 hours if you did a fresh survey


Did you do a SYSTEM:PRESET: and GPS:POS:SURVEY:ONCE commands to initiate 
the new survey or just the survey command or  What software are you 
running?


I would power the unit down and let it sit for 24 hours and then do the 
two commands above.


What software are you running?

Dave
NR1DX




On 3/16/2016 7:38 PM, Joseph Gray wrote:

As I mentioned a while back, my trusty Z3801A, which has worked well
for several years, went into holdover some time ago and stayed there.
Until recently, I haven't had time to look into this. About 20 days
ago, I did power cycle it to see if that made a difference. It did
not.

In the middle of the night, last night (couldn't sleep), I decided to
see what initiating a new survey would do. Since the unit doesn't lock
to as many satellites as my Lucent with the newer Oncore, it took
quite a while for the survey to finish.

I just got home from work and this is what I am seeing:

https://dl.dropboxusercontent.com/u/19599147/Z3801A.png

The good news is that the unit no longer telling me the PPS is
invalid. It looks like it will be another long while before it comes
out of Recovery (assuming the PPS stays locked).

I'm not the best at interpreting these graphs. At this point, should I
be concerned abouth the spikey nature of the EFC graph, or will things
calm down eventually? I assume that the PPS graph won't show until
Recovery is done?

If this unit loses PPS lock again, or otherwise acts up, then I would
assume it is a hardware problem, and I'll have to put it on the bench.

Joe Gray
W5JG
___
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.




--
Dave
manu...@artekmanuals.com
www.ArtekManuals.com

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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] Microsonics TCXO

[Joseph Gray]

I got my hands on some of these.

https://dl.dropboxusercontent.com/u/19599147/TCXO%20Top.jpg

https://dl.dropboxusercontent.com/u/19599147/TCXO%20Bottom.jpg

A search finds other Microsonics units, but not this one. I can't find
any information on what voltage to feed this. Does anyone know?

I know that these aren't Time Nuts grade, but I am curious to see how
good/bad they are. They look to be NOS from 1979.

Some of the other samples are marked as being set to anywhere from 1
Hz to 7 Hz high or low. Why would they have been factory adjusted high
or low?


Joe Gray
W5JG
___
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] Serial-Ethernet

[Paul]

On Thu, Mar 17, 2016 at 10:00 AM, Tom Van Baak  wrote:

> this feature should be in every GPSDO, but I think it's unique to the
> TBolt.
>

I was under the impression that SYNChronization:HOLDover:INITiate did this
on the Fury.
Of course I'm used to embarrassing misapprehensions.

--
Paul
___
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] plug: SDGPS on Kickstarter

[jks]

I'll adopt Didier's notation here


Although it's marketed as an SDR for the BeagleBone, this project contains an 
open source 12+ channel software-defined GPS receiver:
https://www.kickstarter.com/projects/1575992013/kiwisdr-beaglebone-software-defined-radio-sdr-with/

It's very easy to experiment with GPS signal processing by changing the C++ 
code on the Beagle or the Verilog on the FPGA (provided you have the stomach to 
install the Xilinx Vivado design tools). For example, I learned a lot by adding 
decimation to the correlation code. This speeds up strong signal acquisition 
because the FFTs can be smaller. The SDGPS is from Andrew Holme's Homemade GPS 
Receiver project 



___
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] Electronic Goldmine ===> was: Re: DC-DC Converters

[Daniel Watson]

Hi,

The "Electronic Surprise Boxes" they sell are fun to sort through. You will
end up with a huge pile of junk resistors and such, but I have never been
disappointed in the other goodies I found. One box I received contained
about 40 oscillators in various frequencies. You often get a lot of random
crystals as well.

Dan

On Sat, Mar 19, 2016 at 10:18 PM, Mike Feher  wrote:

> I too have bought from them on several occasions. Always found their
> shipping rates high, although nothing as ridiculous like Dave M reported.
> What irks me more, is that often they have something I want on sale but
> they limit your purchase to a single item or very small quantity. 73 - Mike
>
> Mike B. Feher, EOZ Inc.
> 89 Arnold Blvd.
> Howell, NJ, 07731
> 732-886-5960 office
> 908-902-3831 cell
>
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Graham
> Sent: Saturday, March 19, 2016 9:01 PM
> To: time-nuts@febo.com
> Subject: [time-nuts] Electronic Goldmine ===> was: Re: DC-DC Converters
>
> I find Electronic Goldmine shipping quite reasonable and I am in Canada,
> perhaps a wee bit high but not overly.
>
> The sometimes have flat rate or free shipping specials to the US.
>
> Sign up for their email news letter. You will get notice of new items and
> special deals; some special deals are only made notice of too subscribers.
>
> cheers, Graham ve3gtc
>
>
> On 2016-03-19 21:19, Dave M wrote:
> > Goldmine has been around for a bunch of years.  I've bought lots of
> > stuff from them. Most of the time, their prices are significantly
> > below MSRP. They sell first class stuff, usually discontinued items
> > and retailers' clearance items.
> >
> > Great folks to buy from.  My only heartburn with them is their
> > shipping charges.  They don't seem to have any cut-rate deals with any
> > of the major shippers, but it's not like a bunch of Ebay sellers, that
> > make their money with exhorbitant shipping charges. $50 to ship a 1/2
> > lb. item to the next state is a bit rediculous.
> >
> > Overall, a good source of good stuff at good prices.
> >
> > Cheers,
> > Dave M
>
> ___
> 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.