Re: [time-nuts] Question about AD9832 "I out Full Scale" (what does it mean?)

[Bruce Griffiths]

With no internal PLL to generate a higher internal frequency than the 25MHz 
MCLK, that 1MHz waveform looks a bit too smooth for an unfiltered 1MHz output.
Bruce 

On Friday, 18 November 2016 5:12 PM, Richard (Rick) Karlquist 
 wrote:
 

 Trying to figure out what "Iout Full Scale" means on the AD9832.
Some time nuts may have used this one.

On page 7 of this doc:

http://www.analog.com/media/en/technical-documentation/user-guides/UG-313.pdf

It shows the AD9832 output as 572 mV peak to peak
across 300 ohms.  This works out to 1.9 mA peak to
peak current through the resistor.  But Rset on the
board is 3.9K, which is supposed to give a value
for so-called "Iout Full Scale" of 3.878 mA.

I would have thought (just guessing) that peak to
peak output current would be equal to Iout Full
Scale, but it appears to be only half of that.

Can anyone clarify this?

Rick
___
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] Question about AD9832 "I out Full Scale" (what does it mean?)

[Richard (Rick) Karlquist]

Trying to figure out what "Iout Full Scale" means on the AD9832.
Some time nuts may have used this one.

On page 7 of this doc:

http://www.analog.com/media/en/technical-documentation/user-guides/UG-313.pdf

It shows the AD9832 output as 572 mV peak to peak
across 300 ohms.  This works out to 1.9 mA peak to
peak current through the resistor.  But Rset on the
board is 3.9K, which is supposed to give a value
for so-called "Iout Full Scale" of 3.878 mA.

I would have thought (just guessing) that peak to
peak output current would be equal to Iout Full
Scale, but it appears to be only half of that.

Can anyone clarify this?

Rick
___
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] precision timing pulse

[Gerhard Hoffmann]

Am 18.11.2016 um 02:18 schrieb Bob Camp:


If you head of into ARM land (or even FPGA’s) there is a bit of a gotcha. If you
want to run a 10 MHz input and a PPS output, you need a counter with at least
24 bits. The peripherals on ARM chips are all over the place. Some have very
fancy timers, but only go to 16 bits. Some have 32 bit timers that aren’t very 
fancy.
Some timers will clock at the input clock frequency. Others have weird pre-scale
rules on them. Since the pre-scaler is a “can’t get at it” device in terms of 
restarting,
it puts some limits on what you can do.  With FPGA’s it’s rare to get a 1 pps 
divider
and all of the other stuff you want to do in less than about 64 flip flops. 
That’s not
a crazy thing on modern parts. It can be an issue on older parts.


The Xilinx XC2064 with 64 FlipFlops is 30 years old or so, RIP!
I don't think that you get FPGAs with less than 1 flip flops nowadays.


(copy/paste:)

 Design Name ocxo_carrier
 Fitting Status  Successful
 Software Version   P.20131013
 Device Used  XC2C64A-5-VQ44
 Date  10-30-2016, 12:51PM


RESOURCES SUMMARY
Macrocells Used PtermsUsed Registers   Used 
PinsUsed Function Block Inputs
50/64  (79%) 157/224  (71%) 50/64  (79%)  7/33 (22%) 
87/160  (55%)


That is about the smallest thing made by Xilinx that you can buy.
It's a CPLD, not even a FPGA.  It runs at 100 MHz, with some care at 200 
MHz,

and provides the 1pps on my crystal oven carrier board. It also has the
phase detector to lock the oscillator to an incoming 1pps when locking to
a 5/10 MHz reference frequency   or running free   is not wanted.

Source code is about one page all in all.

< 
https://www.flickr.com/photos/137684711@N07/30952263115/in/album-72157662535945536/ 
>

and the picture to the right.

In the top left corner of the board is some space for an alternate PICDIV.

(For 200 MHz the CPLD needs a beautiful clock signal.)


I have made a design with 2 of these (or one 2C128) that produces one 
fixed 1pps
from a 200 MHz clock and another 1pps that can be shifted over > 1 
second in 5 ns steps,
with an interface to a BeagleBoneBlack to receive control  and enough 
outputs to

steer some switchable ECL delay lines for 5 ps fine steps.

A 2C64 is $1.50 or so.

regards, Gerhard

___
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] precision timing pulse

[Bob Camp]

Hi

If you head of into ARM land (or even FPGA’s) there is a bit of a gotcha. If 
you 
want to run a 10 MHz input and a PPS output, you need a counter with at least 
24 bits. The peripherals on ARM chips are all over the place. Some have very
fancy timers, but only go to 16 bits. Some have 32 bit timers that aren’t very 
fancy. 
Some timers will clock at the input clock frequency. Others have weird pre-scale
rules on them. Since the pre-scaler is a “can’t get at it” device in terms of 
restarting, 
it puts some limits on what you can do.  With FPGA’s it’s rare to get a 1 pps 
divider
and all of the other stuff you want to do in less than about 64 flip flops. 
That’s not
a crazy thing on modern parts. It can be an issue on older parts. 

Bob


> On Nov 17, 2016, at 5:45 PM, Chris Albertson  
> wrote:
> 
> For counting and timing the ARM has hardware counbter/timmer that is made
> with logic gates so you don't need software or to disable interrupts.
> Most modern uP has loads and loads of peripheral hardware built-in.   With
> the ARM there is a lot more of these peripheral devices than there are pins
> on the chip so the hard part is learning how to configure the chip (each is
> different)
> 
> So rather then doing like the PicDiv does, counting cycles in software you
> would load up a bunch of config registers to set up a hardware divide by N
> counter.
> 
> The little AVR chip on the Arduino also has built-in counter but that ARV
> chip is pretty low-end so the counter has not the best specs and there are
> not so many independent counters
> 
> With these counters we could build a scintillation counter that is as good
> as you can build using logic gates and not have to resort to assembly
> language.   We can program counters to do things like latch their contents
> so that if the interrupt handler takes some time to read a value it is OK
> because we have a hardware latch.
> 
> It takes time to learn to use this, but there are library functions to call
> that provide a standard API across several different processors.
> 
> From a software developer's point of view one of the biggest reasons for
> using a modern uP is debugging.  Many times we can step through code, line
> by line as it executes inside the chip.  Unfortunately the Arduino
> environment does not take advantage of this but most professional level
> IDEs do.  If time is money source level debugging in C is worth a mint.
> 
> Again, you really can get accurate counting, that function in moved to
> specialized hardware now that is built into the uP chip.
> 
> 
> 
> On Wed, Nov 16, 2016 at 7:17 PM, Hal Murray  wrote:
> 
>> 
>> t...@leapsecond.com said:
>>> Arduino probably uses compiled code, external libraries, and interrupts
>> so
>>> that also is a no-no for precise time.
>> 
>> There are two parts to the Arduino ecosystem.  One is low cost hardware.
>> The
>> other is a software package that is easy for non-wizards to use.
>> 
>> I'd be very surprised if somebody hasn't figured out how to call
>> subroutines
>> coded in assembly language.  If so, you can use their hardware and their
>> software environment and write your code like it was running on a bare
>> machine as long as you add a wrapper to call it from their environment and
>> start your code with a disable interrupts.
>> 
>> 
>> --
>> 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.
>> 
> 
> 
> 
> -- 
> 
> 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] precision timing pulse

[Adrian Godwin]

Tom describes the PIC as a 'poor man's FPGA'. And I'm aware of how they're
programmed - I agree they're a good choice for this sort of device.

However, even poor men can use FPGAs now. I'm following with interest the
open-source toolchain available for the Lattice ice40,
http://www.clifford.at/icestorm/

There are, of course, other cheap FPGAs and free-to-use vendor tools. I've
always found the vendor tools horrendous, with huge overheads and
complicated licensing, so something a bit more manageable is attractive.


On Thu, Nov 17, 2016 at 10:07 PM, Bob Camp  wrote:

> Hi
>
> There are a number of us on the list who code on ARM MCU’s. Doing the
> same thing on one of them is *not* a trivial undertaking. Making sure that
> it does what it should simply is not worth the effort. The PIC 12 is a low
> cost
> solution and has been extensively tested to show that it does what it
> should
> under a range of conditions ….
>
> Bob
>
>
>
> > On Nov 17, 2016, at 4:26 PM, Bryan _  wrote:
> >
> > Tom:
> >
> >
> > As you were gracious to release the source code for these excellent
> little dividers, I would suspect someone who is somewhat fluent in assembly
> could just modify so it counts a specific number of pulses and then toggles
> a output off. The ARM could be used to restart etc. Although I think the OP
> wanted to know the time taken between a run of a number of cycles.
> >
> >
> > Been playing around with the PD15 to replace 2 -14 pin clock dividers
> and it seems to work like a charm, although I can't seem to find any
> information if the inputs on a 12F675 are Schmitt trigger inputs. Can't
> seem to find anything in the datasheet.
> >
> >
> > -=Bryan=-
> >
> >
> > 
> > From: time-nuts  on behalf of Tom Van Baak
> 
> > Sent: November 16, 2016 3:27 PM
> > To: Discussion of precise time and frequency measurement
> > Subject: Re: [time-nuts] precision timing pulse
> >
> > Chris & Chris,
> >
> > Yes the "TVB dividers" are instruction loops where every cycle is
> counted by hand, and then verified with a simulator, and then checked with
> a time interval counter. All the code is out there at
> www.leapsecond.com/pic/
> >
> >
> > I use PIC's for historical and technical reasons. Modern CPU's and MCU's
> have so many layers of optimization that they are no longer deterministic
> at the cycle level. This makes them worthless for precise time
> applications. In addition many of them use clock edge or PLL tricks to
> increase speed, but this introduces jitter. Or they enable interrupts which
> kills precise timing. The PIC's are old-school, fully synchronous and use
> only one clock edge so the jitter is down at the picosecond level. My code
> is isochronous and doesn't use interrupts for timing. It acts like a poor
> man's FPGA.
> >
> > Arduino probably uses compiled code, external libraries, and interrupts
> so that also is a no-no for precise time. I'm not sure about bare metal
> AVR. I hope someone can do measurements on an AVR divider one day so we can
> compare PIC and AVR jitter. I worry about how AVR implements the clock. So
> this is an open question. But I know how PIC's work so that's what I use.
> BTW, these are "ancient" PIC 12F parts. It's possible modern 16- and 32-bit
> PIC's also go to the dark side and optimize for performance rather than
> picosecond determinism. Another open question.
> >
> > Realize that using a MCU for a frequency divider is a weird niche use of
> the chip, so none of what I say applies if you plan to use any of these as
> a general purpose computing system.
> >
> > Also, we don't know if OP is looking for microsecond, nanosecond, or
> picosecond precision in his timing pulses.
> >
> > /tvb
> >
> > Chris Albertson:
> >> I'm wondering why everyone seems to be assuming a PIC is the right
> >> processor.   Of course it could work for this but I'd select whatever is
> >> the easiest to program and debug.   Those tend to the they little single
> >> board development systems that sell for under $10.  They typically have
> USB
> >> connections to a computer and don't require any specialized equipment to
> >> program.   The Arduino is the prime example of these although I've
> moved to
> >> ARM based uP because they can be less expensive with an order of
> magnitude
> >> better performance and can use the same Arduino IDE and run Arduino
> >> sketches.The PIC is not so beginner friendly and requires some study
> >> before it can be used.But if you as said of course a PIC could work,
> >> this is a pretty simple application
> >
> > Chris Caudle:
> >> You could use AVR (arduino), but once you get to most of the ARM
> >> processors it is harder to make them deterministic because of caches.
> You
> >> want a processor where the number of clocks is constant for all or
> almost
> >> all instructions, and is easy enough that you can code the 

Re: [time-nuts] precision timing pulse

[Bryan _]

Sorry, meant the ARM pin on the picdiv not the ARM MCU's


-=Bryan=-



From: time-nuts  on behalf of Bob Camp 

Sent: November 17, 2016 2:07 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] precision timing pulse

Hi

There are a number of us on the list who code on ARM MCU’s. Doing the
same thing on one of them is *not* a trivial undertaking. Making sure that
it does what it should simply is not worth the effort. The PIC 12 is a low cost
solution and has been extensively tested to show that it does what it should
under a range of conditions ….

Bob



> On Nov 17, 2016, at 4:26 PM, Bryan _  wrote:
>
> Tom:
>
>
> As you were gracious to release the source code for these excellent little 
> dividers, I would suspect someone who is somewhat fluent in assembly could 
> just modify so it counts a specific number of pulses and then toggles a 
> output off. The ARM could be used to restart etc. Although I think the OP 
> wanted to know the time taken between a run of a number of cycles.
>
>
> Been playing around with the PD15 to replace 2 -14 pin clock dividers and it 
> seems to work like a charm, although I can't seem to find any information if 
> the inputs on a 12F675 are Schmitt trigger inputs. Can't seem to find 
> anything in the datasheet.
>
>
> -=Bryan=-
>
>
> 
> From: time-nuts  on behalf of Tom Van Baak 
> 
> Sent: November 16, 2016 3:27 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] precision timing pulse
>
> Chris & Chris,
>
> Yes the "TVB dividers" are instruction loops where every cycle is counted by 
> hand, and then verified with a simulator, and then checked with a time 
> interval counter. All the code is out there at 
> www.leapsecond.com/pic/>
>
>
> I use PIC's for historical and technical reasons. Modern CPU's and MCU's have 
> so many layers of optimization that they are no longer deterministic at the 
> cycle level. This makes them worthless for precise time applications. In 
> addition many of them use clock edge or PLL tricks to increase speed, but 
> this introduces jitter. Or they enable interrupts which kills precise timing. 
> The PIC's are old-school, fully synchronous and use only one clock edge so 
> the jitter is down at the picosecond level. My code is isochronous and 
> doesn't use interrupts for timing. It acts like a poor man's FPGA.
>
> Arduino probably uses compiled code, external libraries, and interrupts so 
> that also is a no-no for precise time. I'm not sure about bare metal AVR. I 
> hope someone can do measurements on an AVR divider one day so we can compare 
> PIC and AVR jitter. I worry about how AVR implements the clock. So this is an 
> open question. But I know how PIC's work so that's what I use. BTW, these are 
> "ancient" PIC 12F parts. It's possible modern 16- and 32-bit PIC's also go to 
> the dark side and optimize for performance rather than picosecond 
> determinism. Another open question.
>
> Realize that using a MCU for a frequency divider is a weird niche use of the 
> chip, so none of what I say applies if you plan to use any of these as a 
> general purpose computing system.
>
> Also, we don't know if OP is looking for microsecond, nanosecond, or 
> picosecond precision in his timing pulses.
>
> /tvb
>
> Chris Albertson:
>> I'm wondering why everyone seems to be assuming a PIC is the right
>> processor.   Of course it could work for this but I'd select whatever is
>> the easiest to program and debug.   Those tend to the they little single
>> board development systems that sell for under $10.  They typically have USB
>> connections to a computer and don't require any specialized equipment to
>> program.   The Arduino is the prime example of these although I've moved to
>> ARM based uP because they can be less expensive with an order of magnitude
>> better performance and can use the same Arduino IDE and run Arduino
>> sketches.The PIC is not so beginner friendly and requires some study
>> before it can be used.But if you as said of course a PIC could work,
>> this is a pretty simple application
>
> Chris Caudle:
>> You could use AVR (arduino), but once you get to most of the ARM
>> processors it is harder to make them deterministic because of caches.  You
>> want a processor where the number of clocks is constant for all or almost
>> all instructions, and is easy enough that you can code the loops by hand.
>> Code like TVB's divider probably doesn't even use interrupts, it's just a
>> tight loop where the number of instructions is counted to give the
>> behavior wanted.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to 

Re: [time-nuts] precision timing pulse

[Chris Albertson]

On Wed, Nov 16, 2016 at 8:52 PM, jimlux  wrote:

> On 11/16/16 7:17 PM, Hal Murray wrote:
>
>>
>> t...@leapsecond.com said:
>>
>>> Arduino probably uses compiled code, external libraries, and interrupts
>>> so
>>> that also is a no-no for precise time.
>>>
>>
>> There are two parts to the Arduino ecosystem.  One is low cost hardware.
>> The
>> other is a software package that is easy for non-wizards to use.
>>
>> I'd be very surprised if somebody hasn't figured out how to call
>> subroutines
>> coded in assembly language.
>>
>
It is using the same gcc compiler as "everyone" uses including gcc on PC
hardware.  There is no special trick.  gcc always accepts inline assembly.
  just do this  __asm__ (your asm code here);  You can Google "gcc inline
assembly" and find tutorials and examples

But WHY?  Critical timing should likely go on a hardware counter/timer And
I doubt except for tiny examples most developers could write better code
than a modern optimizing compiler

If you are looking for the most bang per buck for Arduino compatible
hardware go to eBay and search for "minimum arm" and you get a bout 1,000
items like this one
http://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System...


>
Then using Google you find there exists an Arduino boot loader you can
install.   If you don't like Arduino then rather then a boot loader load
any binary file you like

What's nice about these boards is they really ARE minimal.  The chip's
leads are just run out to 0.1 headers and other connectors and passives.
You can assign most functions to most pins and the CPU is roughly an order
of magnitude better then Arduino   With Arduino it is easy to run out of
(say) analog inputs or especially external interrupts but with this ARM you
don't run out of anything until basically you run of of pins.  There ARE
better boards but not for under $3.
-- 

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] precision timing pulse

[Chris Albertson]

For counting and timing the ARM has hardware counbter/timmer that is made
with logic gates so you don't need software or to disable interrupts.
Most modern uP has loads and loads of peripheral hardware built-in.   With
the ARM there is a lot more of these peripheral devices than there are pins
on the chip so the hard part is learning how to configure the chip (each is
different)

So rather then doing like the PicDiv does, counting cycles in software you
would load up a bunch of config registers to set up a hardware divide by N
counter.

The little AVR chip on the Arduino also has built-in counter but that ARV
chip is pretty low-end so the counter has not the best specs and there are
not so many independent counters

With these counters we could build a scintillation counter that is as good
as you can build using logic gates and not have to resort to assembly
language.   We can program counters to do things like latch their contents
so that if the interrupt handler takes some time to read a value it is OK
because we have a hardware latch.

It takes time to learn to use this, but there are library functions to call
that provide a standard API across several different processors.

>From a software developer's point of view one of the biggest reasons for
using a modern uP is debugging.  Many times we can step through code, line
by line as it executes inside the chip.  Unfortunately the Arduino
environment does not take advantage of this but most professional level
IDEs do.  If time is money source level debugging in C is worth a mint.

Again, you really can get accurate counting, that function in moved to
specialized hardware now that is built into the uP chip.



On Wed, Nov 16, 2016 at 7:17 PM, Hal Murray  wrote:

>
> t...@leapsecond.com said:
> > Arduino probably uses compiled code, external libraries, and interrupts
> so
> > that also is a no-no for precise time.
>
> There are two parts to the Arduino ecosystem.  One is low cost hardware.
> The
> other is a software package that is easy for non-wizards to use.
>
> I'd be very surprised if somebody hasn't figured out how to call
> subroutines
> coded in assembly language.  If so, you can use their hardware and their
> software environment and write your code like it was running on a bare
> machine as long as you add a wrapper to call it from their environment and
> start your code with a disable interrupts.
>
>
> --
> 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.
>



-- 

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] precision timing pulse

[Tom Van Baak]

If the OP would contact me I would be happy to make a new PIC divider for his 
specific purpose. I do this all the time. It usually only takes a few minutes.

On the PIC 12F675, pin5 / GP2 is Schmitt trigger. See page 8 of 
41190F-PIC-12F629-675.pdf

But for push-button-start sorts of things input conditioning is unnecessary. 
It's only when a button is both start and stop or increment or decrement that 
you need to debounce and all that stuff.

/tvb

- Original Message - 
From: "Bryan _" 
To: "Discussion of precise time and frequency measurement" 
Sent: Thursday, November 17, 2016 1:26 PM
Subject: Re: [time-nuts] precision timing pulse


> Tom:
> 
> 
> As you were gracious to release the source code for these excellent little 
> dividers, I would suspect someone who is somewhat fluent in assembly could 
> just modify so it counts a specific number of pulses and then toggles a 
> output off. The ARM could be used to restart etc. Although I think the OP 
> wanted to know the time taken between a run of a number of cycles.
> 
> 
> Been playing around with the PD15 to replace 2 -14 pin clock dividers and it 
> seems to work like a charm, although I can't seem to find any information if 
> the inputs on a 12F675 are Schmitt trigger inputs. Can't seem to find 
> anything in the datasheet.
> 
> 
> -=Bryan=-

___
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] precision timing pulse

[Bob Camp]

Hi

There are a number of us on the list who code on ARM MCU’s. Doing the 
same thing on one of them is *not* a trivial undertaking. Making sure that 
it does what it should simply is not worth the effort. The PIC 12 is a low cost
solution and has been extensively tested to show that it does what it should
under a range of conditions ….

Bob



> On Nov 17, 2016, at 4:26 PM, Bryan _  wrote:
> 
> Tom:
> 
> 
> As you were gracious to release the source code for these excellent little 
> dividers, I would suspect someone who is somewhat fluent in assembly could 
> just modify so it counts a specific number of pulses and then toggles a 
> output off. The ARM could be used to restart etc. Although I think the OP 
> wanted to know the time taken between a run of a number of cycles.
> 
> 
> Been playing around with the PD15 to replace 2 -14 pin clock dividers and it 
> seems to work like a charm, although I can't seem to find any information if 
> the inputs on a 12F675 are Schmitt trigger inputs. Can't seem to find 
> anything in the datasheet.
> 
> 
> -=Bryan=-
> 
> 
> 
> From: time-nuts  on behalf of Tom Van Baak 
> 
> Sent: November 16, 2016 3:27 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] precision timing pulse
> 
> Chris & Chris,
> 
> Yes the "TVB dividers" are instruction loops where every cycle is counted by 
> hand, and then verified with a simulator, and then checked with a time 
> interval counter. All the code is out there at 
> www.leapsecond.com/pic/
> 
> 
> I use PIC's for historical and technical reasons. Modern CPU's and MCU's have 
> so many layers of optimization that they are no longer deterministic at the 
> cycle level. This makes them worthless for precise time applications. In 
> addition many of them use clock edge or PLL tricks to increase speed, but 
> this introduces jitter. Or they enable interrupts which kills precise timing. 
> The PIC's are old-school, fully synchronous and use only one clock edge so 
> the jitter is down at the picosecond level. My code is isochronous and 
> doesn't use interrupts for timing. It acts like a poor man's FPGA.
> 
> Arduino probably uses compiled code, external libraries, and interrupts so 
> that also is a no-no for precise time. I'm not sure about bare metal AVR. I 
> hope someone can do measurements on an AVR divider one day so we can compare 
> PIC and AVR jitter. I worry about how AVR implements the clock. So this is an 
> open question. But I know how PIC's work so that's what I use. BTW, these are 
> "ancient" PIC 12F parts. It's possible modern 16- and 32-bit PIC's also go to 
> the dark side and optimize for performance rather than picosecond 
> determinism. Another open question.
> 
> Realize that using a MCU for a frequency divider is a weird niche use of the 
> chip, so none of what I say applies if you plan to use any of these as a 
> general purpose computing system.
> 
> Also, we don't know if OP is looking for microsecond, nanosecond, or 
> picosecond precision in his timing pulses.
> 
> /tvb
> 
> Chris Albertson:
>> I'm wondering why everyone seems to be assuming a PIC is the right
>> processor.   Of course it could work for this but I'd select whatever is
>> the easiest to program and debug.   Those tend to the they little single
>> board development systems that sell for under $10.  They typically have USB
>> connections to a computer and don't require any specialized equipment to
>> program.   The Arduino is the prime example of these although I've moved to
>> ARM based uP because they can be less expensive with an order of magnitude
>> better performance and can use the same Arduino IDE and run Arduino
>> sketches.The PIC is not so beginner friendly and requires some study
>> before it can be used.But if you as said of course a PIC could work,
>> this is a pretty simple application
> 
> Chris Caudle:
>> You could use AVR (arduino), but once you get to most of the ARM
>> processors it is harder to make them deterministic because of caches.  You
>> want a processor where the number of clocks is constant for all or almost
>> all instructions, and is easy enough that you can code the loops by hand.
>> Code like TVB's divider probably doesn't even use interrupts, it's just a
>> tight loop where the number of instructions is counted to give the
>> behavior wanted.
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> time-nuts Info Page - American Febo 
> Enterprises
> www.febo.com
> time-nuts is a low volume, high SNR list for the discussion of precise time 
> and frequency measurement and related topics. To see the collection of prior 
> postings to ...
> 
> 
> 
> and 

Re: [time-nuts] precision timing pulse

[Bryan _]

Tom:


As you were gracious to release the source code for these excellent little 
dividers, I would suspect someone who is somewhat fluent in assembly could just 
modify so it counts a specific number of pulses and then toggles a output off. 
The ARM could be used to restart etc. Although I think the OP wanted to know 
the time taken between a run of a number of cycles.


Been playing around with the PD15 to replace 2 -14 pin clock dividers and it 
seems to work like a charm, although I can't seem to find any information if 
the inputs on a 12F675 are Schmitt trigger inputs. Can't seem to find anything 
in the datasheet.


-=Bryan=-



From: time-nuts  on behalf of Tom Van Baak 

Sent: November 16, 2016 3:27 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] precision timing pulse

Chris & Chris,

Yes the "TVB dividers" are instruction loops where every cycle is counted by 
hand, and then verified with a simulator, and then checked with a time interval 
counter. All the code is out there at 
www.leapsecond.com/pic/


I use PIC's for historical and technical reasons. Modern CPU's and MCU's have 
so many layers of optimization that they are no longer deterministic at the 
cycle level. This makes them worthless for precise time applications. In 
addition many of them use clock edge or PLL tricks to increase speed, but this 
introduces jitter. Or they enable interrupts which kills precise timing. The 
PIC's are old-school, fully synchronous and use only one clock edge so the 
jitter is down at the picosecond level. My code is isochronous and doesn't use 
interrupts for timing. It acts like a poor man's FPGA.

Arduino probably uses compiled code, external libraries, and interrupts so that 
also is a no-no for precise time. I'm not sure about bare metal AVR. I hope 
someone can do measurements on an AVR divider one day so we can compare PIC and 
AVR jitter. I worry about how AVR implements the clock. So this is an open 
question. But I know how PIC's work so that's what I use. BTW, these are 
"ancient" PIC 12F parts. It's possible modern 16- and 32-bit PIC's also go to 
the dark side and optimize for performance rather than picosecond determinism. 
Another open question.

Realize that using a MCU for a frequency divider is a weird niche use of the 
chip, so none of what I say applies if you plan to use any of these as a 
general purpose computing system.

Also, we don't know if OP is looking for microsecond, nanosecond, or picosecond 
precision in his timing pulses.

/tvb

Chris Albertson:
> I'm wondering why everyone seems to be assuming a PIC is the right
> processor.   Of course it could work for this but I'd select whatever is
> the easiest to program and debug.   Those tend to the they little single
> board development systems that sell for under $10.  They typically have USB
> connections to a computer and don't require any specialized equipment to
> program.   The Arduino is the prime example of these although I've moved to
> ARM based uP because they can be less expensive with an order of magnitude
> better performance and can use the same Arduino IDE and run Arduino
> sketches.The PIC is not so beginner friendly and requires some study
> before it can be used.But if you as said of course a PIC could work,
> this is a pretty simple application

Chris Caudle:
> You could use AVR (arduino), but once you get to most of the ARM
> processors it is harder to make them deterministic because of caches.  You
> want a processor where the number of clocks is constant for all or almost
> all instructions, and is easy enough that you can code the loops by hand.
> Code like TVB's divider probably doesn't even use interrupts, it's just a
> tight loop where the number of instructions is counted to give the
> behavior wanted.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
time-nuts Info Page - American Febo 
Enterprises
www.febo.com
time-nuts is a low volume, high SNR list for the discussion of precise time and 
frequency measurement and related topics. To see the collection of prior 
postings to ...



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] Thermal impact on OCXO

[Bob Camp]

Hi

The advent of welded packages for OCXO’s started to make the “blowtorch” 
approach obsolete back in the 1990’s. The
real problem, even backing in the 1980’s is that there is no market for 
rejects. The only high value part in an OCXO is the
crystal. It is the cause of the performance reject, so any “repair” is more 
expensive than the parts you save.

Bob

> On Nov 17, 2016, at 1:15 PM, Bob Stewart  wrote:
> 
> Hi Bob,
> said:  "Most (> 99%) OCXO’s are made to custom specs for large OEM’s. The sort
> consists of “ship these” and “send these to the crusher”.  Needless to say,
> the emphasis is on a process that throws out as few as possible. "
> 
> We've seen a serious improvement in manufacturing yields at close tolerances 
> for small components.  IOW, they can make gazillions of 1% resistors and caps 
> today, whereas back when I was born they had to do some serious sorting to 
> just get a few.  Did this improvement in manufacturing technique carry over 
> to OCXOs such that the units we see on ebay benefited from improved 
> manufacturing ability, or was sorting still a major part of getting usable 
> yield when they were made?  This, of course, avoids the impact of using a 
> blowtorch to remove them from a board that has been removed from a larger 
> board with a bandsaw.
> 
> thanks,
> Bob - AE6RV
>  -
> AE6RV.com
> 
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
> 
>  From: Bob Camp 
> To: Discussion of precise time and frequency measurement  
> Sent: Thursday, November 17, 2016 11:39 AM
> Subject: Re: [time-nuts] Thermal impact on OCXO
> 
> Hi
> 
> 
> Most (> 99%) OCXO’s are made to custom specs for large OEM’s. The sort
> consists of “ship these” and “send these to the crusher”.  Needless to say,
> the emphasis is on a process that throws out as few as possible. 
> 
> Bob
> 
> 
>> 
>> On Wed, Nov 16, 2016 at 8:06 PM, Bob Camp  wrote:
>>> Hi
>>> 
>>> The issue in fitting over short time periods is that the noise is very much
>>> *not* gaussian. You have effects from things like temperature and warmup
>>> that *do* have trends to them. They will lead you off into all sorts of dark
>>> holes fit wise.
>>> 
>>> Bob
>>> 
 On Nov 16, 2016, at 6:48 PM, Scott Stobbe  wrote:
 
 A few different plots. I didn't have an intuitive feel for what the B
 coefficient in log term looks like on a plot, so that is the first
 plot. The same aging curve is plotted three times, with the exception
 of the B coefficient being scaled by 1/10, 1, 10 respectively. In hand
 waving terms, it does have an enormous impact during the first 30 days
 (or until Bt >>1), but from then on, it is just an additive offset.
 
 The next 4 plots are just sample fits with noise added.
 
 Finally the 6th plot is of just the first 30 days, the data would seem
 to be cleaner than what was shown as a sample in the paper, but the
 stability of the B coefficient in 10 monte-carlo runs is not great.
 But when plotted over a year the results are minimal.
 
 A1  A2A3
 0.022914  6.8459  0.00016743
 0.022932  6.6702  0.00058768
 0.023206  5.79690.0026103
 0.023219  4.31270.0093793
 0.02374  2.83090.016838
 0.023119  5.02140.0061557
 0.023054  5.83990.0031886
 0.022782  9.8582  -0.0074089
 0.023279  3.73920.012161
 0.02345  4.10620.0095448
 
 The only other thing to point out from this, is that the A2 and A3
 coefficients are highly non-orthogonal, as A2 increases, A3 drops to
 make up the difference.
 
 On Wed, Nov 16, 2016 at 7:38 AM, Bob Camp  wrote:
> Hi
> 
> The original introduction of 55310 written by a couple of *very* good 
> guys:
> 
> http://tycho.usno.navy.mil/ptti/1987papers/Vol%2019_16.pdf
> 
> A fairly current copy of 55310:
> 
> https://nepp.nasa.gov/DocUploads/1F3275A6-9140-4C0C-864542DBF16EB1CC/MIL-PRF-55310.pdf
> 
> The “right” equation is on page 47. It’s the “Bt+1” in the log that 
> messes up the fit. If you fit it without
> the +1, the fit is *much* easier to do. The result isn’t quite right.
> 
> Bob
> 
> 
>> On Nov 15, 2016, at 11:58 PM, Scott Stobbe  
>> wrote:
>> 
>> Hi Bob,
>> 
>> Do you recall if you fitted with true ordinary least squares, or fit 
>> with a
>> recursive/iterative approach in a least squares sense. If the aging curve
>> is linearizable, it isn't jumping out at me.
>> 
>> If the model was hypothetically:
>>   F = A ln( B*t )
>> 
>>   F = A ln(t) + Aln(B)
>> 
>> which could easily be fit 

Re: [time-nuts] precision timing pulse

[David]

On Wed, 16 Nov 2016 11:14:59 -0800, you wrote:

>albertson.ch...@gmail.com said:
>> I'm wondering why everyone seems to be assuming a PIC is the right processor
>
>If you want cycle-accurate timing, one approach is to count cycles.  If you 
>have an assembly level background, the PIC is as good as any small chip.  
>Yes, it's a pain to get started if you don't have a working setup or a friend 
>with one you can copy.

Even when not counting cycles, there are other considerations.

1. PIC (and AVR and some others) are available in small DIP packages
making prototyping or one shot projects easy.

2. PIC is the least expensive followed by RS08 from NXP/Freescale, eZ8
from Zilog, and finally AVR from Atmel.

3. PIC and AVR have the most support.  I would probably prefer the AVR
ISA but PIC is 1/3rd the cost and seems to have better peripherals and
documentation.  Since Microchip bought Atmel, I worry that AVR will be
effectively discontinued.
___
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] Thermal impact on OCXO

[Bob Stewart]

Hi Bob,
said:  "Most (> 99%) OCXO’s are made to custom specs for large OEM’s. The sort
consists of “ship these” and “send these to the crusher”.  Needless to say,
the emphasis is on a process that throws out as few as possible. "

We've seen a serious improvement in manufacturing yields at close tolerances 
for small components.  IOW, they can make gazillions of 1% resistors and caps 
today, whereas back when I was born they had to do some serious sorting to just 
get a few.  Did this improvement in manufacturing technique carry over to OCXOs 
such that the units we see on ebay benefited from improved manufacturing 
ability, or was sorting still a major part of getting usable yield when they 
were made?  This, of course, avoids the impact of using a blowtorch to remove 
them from a board that has been removed from a larger board with a bandsaw.

thanks,
Bob - AE6RV
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp 
 To: Discussion of precise time and frequency measurement  
 Sent: Thursday, November 17, 2016 11:39 AM
 Subject: Re: [time-nuts] Thermal impact on OCXO
   
Hi


Most (> 99%) OCXO’s are made to custom specs for large OEM’s. The sort
consists of “ship these” and “send these to the crusher”.  Needless to say,
the emphasis is on a process that throws out as few as possible. 

Bob


> 
> On Wed, Nov 16, 2016 at 8:06 PM, Bob Camp  wrote:
>> Hi
>> 
>> The issue in fitting over short time periods is that the noise is very much
>> *not* gaussian. You have effects from things like temperature and warmup
>> that *do* have trends to them. They will lead you off into all sorts of dark
>> holes fit wise.
>> 
>> Bob
>> 
>>> On Nov 16, 2016, at 6:48 PM, Scott Stobbe  wrote:
>>> 
>>> A few different plots. I didn't have an intuitive feel for what the B
>>> coefficient in log term looks like on a plot, so that is the first
>>> plot. The same aging curve is plotted three times, with the exception
>>> of the B coefficient being scaled by 1/10, 1, 10 respectively. In hand
>>> waving terms, it does have an enormous impact during the first 30 days
>>> (or until Bt >>1), but from then on, it is just an additive offset.
>>> 
>>> The next 4 plots are just sample fits with noise added.
>>> 
>>> Finally the 6th plot is of just the first 30 days, the data would seem
>>> to be cleaner than what was shown as a sample in the paper, but the
>>> stability of the B coefficient in 10 monte-carlo runs is not great.
>>> But when plotted over a year the results are minimal.
>>> 
>>>        A1              A2            A3
>>>    0.022914      6.8459  0.00016743
>>>    0.022932      6.6702  0.00058768
>>>    0.023206      5.7969    0.0026103
>>>    0.023219      4.3127    0.0093793
>>>    0.02374      2.8309    0.016838
>>>    0.023119      5.0214    0.0061557
>>>    0.023054      5.8399    0.0031886
>>>    0.022782      9.8582  -0.0074089
>>>    0.023279      3.7392    0.012161
>>>    0.02345      4.1062    0.0095448
>>> 
>>> The only other thing to point out from this, is that the A2 and A3
>>> coefficients are highly non-orthogonal, as A2 increases, A3 drops to
>>> make up the difference.
>>> 
>>> On Wed, Nov 16, 2016 at 7:38 AM, Bob Camp  wrote:
 Hi
 
 The original introduction of 55310 written by a couple of *very* good guys:
 
 http://tycho.usno.navy.mil/ptti/1987papers/Vol%2019_16.pdf
 
 A fairly current copy of 55310:
 
 https://nepp.nasa.gov/DocUploads/1F3275A6-9140-4C0C-864542DBF16EB1CC/MIL-PRF-55310.pdf
 
 The “right” equation is on page 47. It’s the “Bt+1” in the log that messes 
 up the fit. If you fit it without
 the +1, the fit is *much* easier to do. The result isn’t quite right.
 
 Bob
 
 
> On Nov 15, 2016, at 11:58 PM, Scott Stobbe  
> wrote:
> 
> Hi Bob,
> 
> Do you recall if you fitted with true ordinary least squares, or fit with 
> a
> recursive/iterative approach in a least squares sense. If the aging curve
> is linearizable, it isn't jumping out at me.
> 
> If the model was hypothetically:
>  F = A ln( B*t )
> 
>  F = A ln(t) + Aln(B)
> 
> which could easily be fit as
>  F  = A' X + B', where X = ln(t)
> 
> It would appear stable32 uses an iterative approach for the non-linear
> problem
> 
> "y(t) = a·ln(bt+1), where slope = y'(t) = ab/(bt+1) Determining the
> nonlinear log fit coefficients requires an iterative procedure. This
> involves setting b to an in initial value, linearizing the equation,
> solving for the other coefficients and the sum of the squared error,
> comparing that with an error criterion, and iterating until a satisfactory
> result is found. The key aspects to this numerical analysis process 

Re: [time-nuts] Thermal impact on OCXO

[Bob Camp]

Hi

> On Nov 17, 2016, at 10:34 AM, Scott Stobbe  wrote:
> 
> I couldn't agree more, that, once you add a correlated disturbance or
> 1/f^a power law noise, things get even messier. Gaussian is just the
> easiest to toss in.
> 
> I once herd a story from once upon a time that, if you bought a 10%
> resistor, what you ended up with is something like this in the figure
> attached.
> 
> Of course 1% percent resistors (EIA96) are manufactured in high yield
> today, but I would guess some of this still applies to OCXOs, you
> aren't likely to find a gem in the D grade parts. After pre-aging for
> a couple of weeks they are either binned, labeled D, or the ones that
> show promise are left to age some more before being tested to C grade,
> etc, etc.

Most (> 99%) OCXO’s are made to custom specs for large OEM’s. The sort
consists of “ship these” and “send these to the crusher”.  Needless to say,
the emphasis is on a process that throws out as few as possible. 

Bob


> 
> On Wed, Nov 16, 2016 at 8:06 PM, Bob Camp  wrote:
>> Hi
>> 
>> The issue in fitting over short time periods is that the noise is very much
>> *not* gaussian. You have effects from things like temperature and warmup
>> that *do* have trends to them. They will lead you off into all sorts of dark
>> holes fit wise.
>> 
>> Bob
>> 
>>> On Nov 16, 2016, at 6:48 PM, Scott Stobbe  wrote:
>>> 
>>> A few different plots. I didn't have an intuitive feel for what the B
>>> coefficient in log term looks like on a plot, so that is the first
>>> plot. The same aging curve is plotted three times, with the exception
>>> of the B coefficient being scaled by 1/10, 1, 10 respectively. In hand
>>> waving terms, it does have an enormous impact during the first 30 days
>>> (or until Bt >>1), but from then on, it is just an additive offset.
>>> 
>>> The next 4 plots are just sample fits with noise added.
>>> 
>>> Finally the 6th plot is of just the first 30 days, the data would seem
>>> to be cleaner than what was shown as a sample in the paper, but the
>>> stability of the B coefficient in 10 monte-carlo runs is not great.
>>> But when plotted over a year the results are minimal.
>>> 
>>> A1  A2A3
>>>0.022914   6.8459   0.00016743
>>>0.022932   6.6702   0.00058768
>>>0.023206   5.79690.0026103
>>>0.023219   4.31270.0093793
>>> 0.02374   2.8309 0.016838
>>>0.023119   5.02140.0061557
>>>0.023054   5.83990.0031886
>>>0.022782   9.8582   -0.0074089
>>>0.023279   3.7392 0.012161
>>> 0.02345   4.10620.0095448
>>> 
>>> The only other thing to point out from this, is that the A2 and A3
>>> coefficients are highly non-orthogonal, as A2 increases, A3 drops to
>>> make up the difference.
>>> 
>>> On Wed, Nov 16, 2016 at 7:38 AM, Bob Camp  wrote:
 Hi
 
 The original introduction of 55310 written by a couple of *very* good guys:
 
 http://tycho.usno.navy.mil/ptti/1987papers/Vol%2019_16.pdf
 
 A fairly current copy of 55310:
 
 https://nepp.nasa.gov/DocUploads/1F3275A6-9140-4C0C-864542DBF16EB1CC/MIL-PRF-55310.pdf
 
 The “right” equation is on page 47. It’s the “Bt+1” in the log that messes 
 up the fit. If you fit it without
 the +1, the fit is *much* easier to do. The result isn’t quite right.
 
 Bob
 
 
> On Nov 15, 2016, at 11:58 PM, Scott Stobbe  
> wrote:
> 
> Hi Bob,
> 
> Do you recall if you fitted with true ordinary least squares, or fit with 
> a
> recursive/iterative approach in a least squares sense. If the aging curve
> is linearizable, it isn't jumping out at me.
> 
> If the model was hypothetically:
>   F = A ln( B*t )
> 
>   F = A ln(t) + Aln(B)
> 
> which could easily be fit as
>   F  = A' X + B', where X = ln(t)
> 
> It would appear stable32 uses an iterative approach for the non-linear
> problem
> 
> "y(t) = a·ln(bt+1), where slope = y'(t) = ab/(bt+1) Determining the
> nonlinear log fit coefficients requires an iterative procedure. This
> involves setting b to an in initial value, linearizing the equation,
> solving for the other coefficients and the sum of the squared error,
> comparing that with an error criterion, and iterating until a satisfactory
> result is found. The key aspects to this numerical analysis process are
> establishing a satisfactory iteration factor and error criterion to assure
> both convergence and small residuals."
> 
> http://www.stable32.com/Curve%20Fitting%20Features%20in%20Stable32.pdf
> 
> Not sure what others do.
> 
> 
> On Mon, Nov 14, 2016 at 7:15 AM, Bob Camp  wrote:
> 
>> Hi
>> 
>> If you already *have* data over a year (or multiple years) the fit 

Re: [time-nuts] Thermal impact on OCXO

[Attila Kinali]

On Thu, 17 Nov 2016 10:34:06 -0500
Scott Stobbe  wrote:

> I couldn't agree more, that, once you add a correlated disturbance or
> 1/f^a power law noise, things get even messier. Gaussian is just the
> easiest to toss in.

Side note: 1/f^a noise is (usually) Gaussian.
It's not white Gaussian, but it's still Gaussian[1].


Attila Kinali

[1] "Statistics of 1/f Noise", by Brophy, 1967
https://doi.org/10.1103/PhysRev.166.827

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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] A (slightly) different apu2 question

[Wojciech Owczarek]

>
>
> NTP does not require softstamps.  NTP can be (and I believe it has been in
> a product) modified to use "PTP" hardware (hardstamps) and  reasonably
> current releases can run with "drivestamps" (sampled in the NIC driver)
> between cooperating endpoints.


Of course it does not *require* software timestamps, I never said that, it
is just the fact that most people use it with software timestamps, even if
the NIC permits hardware timestamps. You need a secondary servo to sync the
NIC to O/S clock if you want to serve that (or consume that) - or sync the
NIC to external 1PPS. What you call a "drivestamp", I call a software
timestamp. If it's not a function of the silicon, it's software. All I
meant was that there is some unexploited potential.

-- 
-

Wojciech Owczarek
___
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] A (slightly) different apu2 question

[Paul]

On Thu, Nov 17, 2016 at 9:42 AM, Wojciech Owczarek 
wrote:

> ... waste what's
> left by then retransmitting it via NTP with software timestamping. I am not
> saying that there is anything wrong with NTP, just that software packet
> transmission and receipt timestamps ruin both precision and accuracy.
>

NTP does not require softstamps.  NTP can be (and I believe it has been in
a product) modified to use "PTP" hardware (hardstamps) and  reasonably
current releases can run with "drivestamps" (sampled in the NIC driver)
between cooperating endpoints.
___
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] Thermal impact on OCXO

[Scott Stobbe]

I couldn't agree more, that, once you add a correlated disturbance or
1/f^a power law noise, things get even messier. Gaussian is just the
easiest to toss in.

I once herd a story from once upon a time that, if you bought a 10%
resistor, what you ended up with is something like this in the figure
attached.

Of course 1% percent resistors (EIA96) are manufactured in high yield
today, but I would guess some of this still applies to OCXOs, you
aren't likely to find a gem in the D grade parts. After pre-aging for
a couple of weeks they are either binned, labeled D, or the ones that
show promise are left to age some more before being tested to C grade,
etc, etc.

On Wed, Nov 16, 2016 at 8:06 PM, Bob Camp  wrote:
> Hi
>
> The issue in fitting over short time periods is that the noise is very much
> *not* gaussian. You have effects from things like temperature and warmup
> that *do* have trends to them. They will lead you off into all sorts of dark
> holes fit wise.
>
> Bob
>
>> On Nov 16, 2016, at 6:48 PM, Scott Stobbe  wrote:
>>
>> A few different plots. I didn't have an intuitive feel for what the B
>> coefficient in log term looks like on a plot, so that is the first
>> plot. The same aging curve is plotted three times, with the exception
>> of the B coefficient being scaled by 1/10, 1, 10 respectively. In hand
>> waving terms, it does have an enormous impact during the first 30 days
>> (or until Bt >>1), but from then on, it is just an additive offset.
>>
>> The next 4 plots are just sample fits with noise added.
>>
>> Finally the 6th plot is of just the first 30 days, the data would seem
>> to be cleaner than what was shown as a sample in the paper, but the
>> stability of the B coefficient in 10 monte-carlo runs is not great.
>> But when plotted over a year the results are minimal.
>>
>>  A1  A2A3
>> 0.022914   6.8459   0.00016743
>> 0.022932   6.6702   0.00058768
>> 0.023206   5.79690.0026103
>> 0.023219   4.31270.0093793
>>  0.02374   2.8309 0.016838
>> 0.023119   5.02140.0061557
>> 0.023054   5.83990.0031886
>> 0.022782   9.8582   -0.0074089
>> 0.023279   3.7392 0.012161
>>  0.02345   4.10620.0095448
>>
>> The only other thing to point out from this, is that the A2 and A3
>> coefficients are highly non-orthogonal, as A2 increases, A3 drops to
>> make up the difference.
>>
>> On Wed, Nov 16, 2016 at 7:38 AM, Bob Camp  wrote:
>>> Hi
>>>
>>> The original introduction of 55310 written by a couple of *very* good guys:
>>>
>>> http://tycho.usno.navy.mil/ptti/1987papers/Vol%2019_16.pdf
>>>
>>> A fairly current copy of 55310:
>>>
>>> https://nepp.nasa.gov/DocUploads/1F3275A6-9140-4C0C-864542DBF16EB1CC/MIL-PRF-55310.pdf
>>>
>>> The “right” equation is on page 47. It’s the “Bt+1” in the log that messes 
>>> up the fit. If you fit it without
>>> the +1, the fit is *much* easier to do. The result isn’t quite right.
>>>
>>> Bob
>>>
>>>
 On Nov 15, 2016, at 11:58 PM, Scott Stobbe  
 wrote:

 Hi Bob,

 Do you recall if you fitted with true ordinary least squares, or fit with a
 recursive/iterative approach in a least squares sense. If the aging curve
 is linearizable, it isn't jumping out at me.

 If the model was hypothetically:
F = A ln( B*t )

F = A ln(t) + Aln(B)

 which could easily be fit as
F  = A' X + B', where X = ln(t)

 It would appear stable32 uses an iterative approach for the non-linear
 problem

 "y(t) = a·ln(bt+1), where slope = y'(t) = ab/(bt+1) Determining the
 nonlinear log fit coefficients requires an iterative procedure. This
 involves setting b to an in initial value, linearizing the equation,
 solving for the other coefficients and the sum of the squared error,
 comparing that with an error criterion, and iterating until a satisfactory
 result is found. The key aspects to this numerical analysis process are
 establishing a satisfactory iteration factor and error criterion to assure
 both convergence and small residuals."

 http://www.stable32.com/Curve%20Fitting%20Features%20in%20Stable32.pdf

 Not sure what others do.


 On Mon, Nov 14, 2016 at 7:15 AM, Bob Camp  wrote:

> Hi
>
> If you already *have* data over a year (or multiple years) the fit is
> fairly easy.
> If you try to do this with data from a few days or less, the whole fit
> process is
> a bit crazy. You also have *multiple* time constants involved on most
> OCXO’s.
> The result is that an earlier fit will have a shorter time constant (and
> will ultimately
> die out). You may not be able to separate the 25 year curve from the 3
> month
> curve with only 3 months of data.
>
> Bob
>

Re: [time-nuts] Thermal impact on OCXO

[Scott Stobbe]

It sounds like you knew what I meant by linearization, but I really
should have wrote linearize in parameters. Of course functions like

F = Ax^2 + Bx + C
F = Asin(omega t) + Bcos(omega t)

fit extremely well with ordinary least squares.

Well there is no free lunch, nlsq has its own challenges, the results
you get depends on the initial conditions you provide, and can also
completely diverge, or converge on a local minima which isn't the best
fit. There don't seem to be a lot of worked examples out there so for
someone one day in the future here is some sample octave/matlab code
for nlsq.

A1 = 0.0233;
A2 = 4.4583;
A3 = 0.0082;

A = [ A1 A2 A3 ];

ts = (1:(30))';

Fage = @(A,x) A(1).*log(A(2).*x + 1) + A(3)

F = Fage(A,ts);

% Add Gaussian measurement noise
F_pn = F + 1E6*0.5e-9*randn(size(ts));

% Fit F_pn to non-linear function Fage
Ainit = [ 1 1 1 ];

options = optimset('Display','on','TolFun',1e-12, 'TolX', 1e-12);
[Aest,resnorm, e, o] = lsqcurvefit(Fage,Ainit,ts,F_pn,[],[],options);


On Thu, Nov 17, 2016 at 8:24 AM, Attila Kinali  wrote:
> On Tue, 15 Nov 2016 23:58:31 -0500
> Scott Stobbe  wrote:
>
>> Do you recall if you fitted with true ordinary least squares, or fit with a
>> recursive/iterative approach in a least squares sense. If the aging curve
>> is linearizable, it isn't jumping out at me.
>
> Least square fits to non-linear functions are almost always iterative.
> There are only very few functions for which closed formulas are known.
> Quite a few people do "linearization", but in general this does not
> work well or leads to sub-optimal solutions (aka not an least squares fit)
> without people realizing it.
>
> An alternative method that works for some functions are state-space
> methods. But I barely know about them, so I cannot really comment on them.
>
>
> Attila Kinali
> --
> It is upon moral qualities that a society is ultimately founded. All
> the prosperity and technological sophistication in the world is of no
> use without that foundation.
>  -- Miss Matheson, The Diamond Age, Neil Stephenson
> ___
> 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] A (slightly) different apu2 question

[Wojciech Owczarek]

...do excuse the slightly off-topic 5(insert your preferred sub-currency
here).

I think many people put a significant effort into getting a precise pulse
into a board like the APU2, losing a lot of precision and accuracy by
getting it into the O/S software clock, and then perfectly waste what's
left by then retransmitting it via NTP with software timestamping. I am not
saying that there is anything wrong with NTP, just that software packet
transmission and receipt timestamps ruin both precision and accuracy.

The APU2 is a real gem for many reasons, but one is of significance for
time sync. The board uses discrete i210 PHY/MAC chips which support
hardware timestamping (of all packets, not just PTP) - rather than using an
in-SOC Intel MAC paired with a different PHY like Marvell or, diety forbid,
Realtek. When designing the board, Pascal did the time nuts a huge favour
by presenting pins 60-63 of each i210 as test pads on the board, four per
chip. These pins are software-defined I/O pins which can be used for 1PPS
output, arbitrary square wave output, and input event timestamping - all
tied to the i210 hardware clocks.

I have exchanged a few e-mails with Pascal and he hinted that he will
consider breaking those i210 pads either as a pin header or possibly as
u.FL connectors - maybe not all, but say two per NIC. The only thing that
could make this board better (but then it would be a different board) is if
it used the latest generation of Intel Atom, where they implemented counter
correlation between the CPU and NICs, allowing for very tight O/S clock to
NIC clock sync. But that Atom was only recently announced (Skylake CPUs do
this already), and an AMD CPU was selected for the APU2 for specific
reasons.

Another small board with similar potential is the upcoming Minnowboard
Turbot Dual-E (
http://www.adiengineering.com/products/minnowboard-turbot-duale/):
Atom-based, small, with two i211 right on the board.

Cheers,
Wojciech


On 17 November 2016 at 13:04, Attila Kinali  wrote:

> On Wed, 16 Nov 2016 15:24:06 -0800
> Jay Grizzard  wrote:
>
> > On the apu2, this crystal is easily accessible (at least as easy as
> > anything SMD is). Can anyone think of a reason that it wouldn't be
> > feasible to replace this crystal with an external reference, à la the
> > widely known clockblock + Soekris net4501 hack (but with 64x the RAM)? I
> > figure the higher frequency might make it a bit trickier to get the
> > signal to the board intact, but is there any other good reason this
> > wouldn't work?
>
> You should check with Pascal Dornier (the guy behind pc-engines).
> He can exactly tell you what would work and what wouldn't.
> And he is generally very very helpful.
>
> Attila Kinali
> --
> It is upon moral qualities that a society is ultimately founded. All
> the prosperity and technological sophistication in the world is of no
> use without that foundation.
>  -- Miss Matheson, The Diamond Age, Neil Stephenson
> ___
> 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.
>



-- 
-

Wojciech Owczarek
___
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] precision timing pulse

[jimlux]

On 11/17/16 4:45 AM, Bob Camp wrote:

Hi



On Nov 16, 2016, at 11:52 PM, jimlux  wrote:

On 11/16/16 7:17 PM, Hal Murray wrote:


t...@leapsecond.com said:

Arduino probably uses compiled code, external libraries, and interrupts so
that also is a no-no for precise time.


There are two parts to the Arduino ecosystem.  One is low cost hardware.  The
other is a software package that is easy for non-wizards to use.

I'd be very surprised if somebody hasn't figured out how to call subroutines
coded in assembly language.


Lots of this around


It’s around, but unless you *only* use assembly, there is no way to be sure of 
what is happening
on a cycle by cycle basis. Once you put that restriction on things, the whole 
“cute IDE” part of it
becomes more of a problem than part of the solution. Since the dividers are 
always in divide mode
(there are no spare cycles) you don’t have some part of the process that does 
not matter ….


I think I would advocate using the hardware devices, and make the 
software part that uses the hardware "non-timing-critical".






That is only part of the problem. The other part is working out just how the 
i/o pins get done.
One thing about even the M series Arm’s … you still get the bus arbitration and 
cycle
interleaving stuff. It makes them faster by a noticeable amount. The ones with 
bus
cache (M4’s etc) get even more “interesting” when you try to work out exactly 
which cycle
the pin toggles on.  They have to do something there (even on simple parts)  
since flash runs
at one speed, I/O at another speed, CPU at yet another clock speed, and RAM 
tied to either
CPU or (yikes!!) I/O. The same Teensy board line also has < $30 boards in it 
with all the
cache and bus stuff (180 MHz CPU and 26 MHz flash …).


True, but with some time with the processor manual(s), you can figure 
out which clocks are running which parts.   I will say that those little 
parts have an enormous amount of flexibility - there are clock 
generators and muxes here, there, and everywhere.  You really need to 
dig into the docs to figure out exactly how the clocks have been configured.



I suppose this sort of just shifts the time required from "write in 
assembler and count cycles" to "read the 1000 page processor manual and 
look at someone else's library code to figure out what's really going 
on", as well as a "hook it up and write some test programs"


Maybe, like everything, it's a de gustibus non disputandum situation
___
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] Thermal impact on OCXO

[Attila Kinali]

On Tue, 15 Nov 2016 23:58:31 -0500
Scott Stobbe  wrote:

> Do you recall if you fitted with true ordinary least squares, or fit with a
> recursive/iterative approach in a least squares sense. If the aging curve
> is linearizable, it isn't jumping out at me.

Least square fits to non-linear functions are almost always iterative.
There are only very few functions for which closed formulas are known.
Quite a few people do "linearization", but in general this does not
work well or leads to sub-optimal solutions (aka not an least squares fit)
without people realizing it.

An alternative method that works for some functions are state-space
methods. But I barely know about them, so I cannot really comment on them.


Attila Kinali
-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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] precision timing pulse

[Attila Kinali]

On Wed, 16 Nov 2016 20:47:52 -0800
jimlux  wrote:

> The BeagleBoard Black is a bigger, more capable example.. You can 
> actually run a *nix on it, but has device drivers and such for lots of 
> GPIO and timers.

And additionally has two PRU units, which are basically uC's with
cycle exact execution, that can toggle all their GPIO (up to 16 IIRC)
at each cycle and run with up to 200MHz.

But then, for most things, the BBB is a bit of an overkill :-)

Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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] A (slightly) different apu2 question

[Attila Kinali]

On Wed, 16 Nov 2016 15:24:06 -0800
Jay Grizzard  wrote:

> On the apu2, this crystal is easily accessible (at least as easy as 
> anything SMD is). Can anyone think of a reason that it wouldn't be 
> feasible to replace this crystal with an external reference, à la the 
> widely known clockblock + Soekris net4501 hack (but with 64x the RAM)? I 
> figure the higher frequency might make it a bit trickier to get the 
> signal to the board intact, but is there any other good reason this 
> wouldn't work?

You should check with Pascal Dornier (the guy behind pc-engines).
He can exactly tell you what would work and what wouldn't.
And he is generally very very helpful.

Attila Kinali
-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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] precision timing pulse

[Bob Camp]

Hi


> On Nov 16, 2016, at 11:52 PM, jimlux  wrote:
> 
> On 11/16/16 7:17 PM, Hal Murray wrote:
>> 
>> t...@leapsecond.com said:
>>> Arduino probably uses compiled code, external libraries, and interrupts so
>>> that also is a no-no for precise time.
>> 
>> There are two parts to the Arduino ecosystem.  One is low cost hardware.  The
>> other is a software package that is easy for non-wizards to use.
>> 
>> I'd be very surprised if somebody hasn't figured out how to call subroutines
>> coded in assembly language.
> 
> Lots of this around

It’s around, but unless you *only* use assembly, there is no way to be sure of 
what is happening
on a cycle by cycle basis. Once you put that restriction on things, the whole 
“cute IDE” part of it
becomes more of a problem than part of the solution. Since the dividers are 
always in divide mode
(there are no spare cycles) you don’t have some part of the process that does 
not matter ….

That is only part of the problem. The other part is working out just how the 
i/o pins get done. 
One thing about even the M series Arm’s … you still get the bus arbitration and 
cycle 
interleaving stuff. It makes them faster by a noticeable amount. The ones with 
bus 
cache (M4’s etc) get even more “interesting” when you try to work out exactly 
which cycle
the pin toggles on.  They have to do something there (even on simple parts)  
since flash runs 
at one speed, I/O at another speed, CPU at yet another clock speed, and RAM 
tied to either 
CPU or (yikes!!) I/O. The same Teensy board line also has < $30 boards in it 
with all the 
cache and bus stuff (180 MHz CPU and 26 MHz flash …).

Bob

> 
> 
> If so, you can use their hardware and their
>> software environment and write your code like it was running on a bare
>> machine as long as you add a wrapper to call it from their environment and
>> start your code with a disable interrupts.
> 
> ANd many "supported by Arduino environment" hardware platforms have hardware 
> that can do the timing.. the teensy alluded to before has hardware timers 
> that are trivially accessible from the Arduino dev environment, because Paul 
> at PJRC (or other folks, too) has built APIs/libraries to get access to the 
> capabilities of the chip.
> 
> So you can use the "timer0" library, which is software on a vanilla Arduino, 
> and hardware on the Freescale processor used on the teensy.
> 
> 
> 
> 
> 
>> 
>> 
> 
> ___
> 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] A (slightly) different apu2 question

[Mike Cook]

Sorry if this is a dup. I had accidentally left the « SPAM » prefix on my first 
reply.

> Le 17 nov. 2016 à 00:24, Jay Grizzard  a écrit :
> 
> So there's been a lot of discussion going around on how to do GPS foo on 
> pcengines.ch's apu2 hardware, but there's one question I haven't seen 
> discussed ... which I'm now going to discuss. Or at least ask about.
> 
> I can't find a public datasheet for the actual processor in these (a AMD 
> GX-412TC SOC), but looking at datasheets for similar AMD chips, this SOC 
> seems to use a single 48MHz external crystal from which all the other system 
> clocks are derived (save for the 32.768kHz RTC).

The principle should be applicable…. BUT you had better look closely at the 
schematics. There are some very low voltages in there.

> On the apu2, this crystal is easily accessible (at least as easy as anything 
> SMD is). Can anyone think of a reason that it wouldn't be feasible to replace 
> this crystal with an external reference, à la the widely known clockblock + 
> Soekris net4501 hack (but with 64x the RAM)? I figure the higher frequency 
> might make it a bit trickier to get the signal to the board intact, but is 
> there any other good reason this wouldn't work?
> 
> The CPU itself is four cores (no hyperthreading), so I'm figuring dedicate 
> one core to PPS handling (should give really low-jitter interrupt handling), 
> maybe one to ntpd, and combined with that precision reference, a pretty nice 
> NTP/PTP server should pop out the other side. The ethernet on the apu2 even 
> does hardware timestamping.
> 
> Can anyone think of a reason this wouldn't work, before I break out the 
> rework gear?
> 
> -j
> 
> ___
> 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.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

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