Re: [time-nuts] Help Identifying this surplus Timing Module

[CubeCentral]

Bob, thank you so very much for this - I will share it with the owner of the 
module and let you know what he decides to do with it!
I so very much appreciate being able to pick y'all brains from time to time, 
and I just wanted to be sure to thank you!
Cheers!

-Randal   (at CubeCentral)

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob kb8tq
Sent: Saturday, May 12, 2018 08:39
To: Discussion of precise time and frequency measurement 
Subject: Re: [time-nuts] Help Identifying this surplus Timing Module

Hi

Ok, the gizmo on the front it an Altera CPLD. Not a lot of gates, so not a lot 
going on there. Whatever the real functions are, they are in the chip with no 
labeling. 

Even with the full information (let’s say): 

Takes in a 16 stream OC-blah blah and provides the following alarms on the 
status channel. Hookup up the data stream and backup to pins X and Y. Status 
alarms also come out on A, B, and C. Power is 12 V +/- 10% on pin M. Enable and 
control are on pins E,F,G. 

Unless you happen to be building an OC-3 system in the basement and have all 
the optical fiber stuff to do it …. not a lot of use. It is very similar to a 
lot of product I designed over the years. It likely does a great job in it’s 
intended OEM application.
It’s pretty much useless for anything more general purpose as it is right now.

Without a schematic, the source code for the DSP and CPLD  and the proper tool 
sets, not much you can modify it to do. Even with all that stuff, probably the 
best you could do is a fairly basic 1 pps in. to  38.88 MHz) / M  out PLL. 

Indeed this *is* where timing has gone over the last few decades. TimeNuts 
normally may not look at telecom timing as an exciting thing. There is a vast 
amount of gear that has been built to distribute signals inside these networks. 
As far as Crazy Bob at home is concerned, it’s all out of reach. It also is all 
designed for maintenance of data sync rather than time of day. It’s still very 
much time, just a different way of looking at it. 

Bob

> On May 11, 2018, at 11:45 PM, CubeCentral  wrote:
> 
> Thank you bob and Gary for your investigations!  I appreciate it!  Here are a 
> couple more views:
> 
> https://imgur.com/a/auWdXvq
> 
> "This is the picture with sticker removed.   The large IC at the back has its 
> label scratched off.  ... that was intentional, but he has a note saying it 
> is a member of Motorola DSP56300 family. It was likely purchased in 2010 
> based on an eBay invoice which has no date on it, but the scanned date was 
> Feb 2011."
> 
> If anyone else has any more ideas, I would gladly hear them!  Thanks again!
> 
>   -Randal   (at CubeCentral)
> 
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Gary 
> Chatters
> Sent: Friday, May 11, 2018 19:07
> To: time-nuts@febo.com
> Subject: Re: [time-nuts] Help Identifying this surplus Timing Module
> 
> A little Googling found a two page datasheet.  It doesn't tell you much more 
> than what you already found out, but does have specifications.
> 
> I can't figure out the correct link to include here, but a Google search with 
> the string "ATiMe-s 38.88" (don't include the quotes) should bring up the 
> link in the first couple of hits.  It is a PDF at the www.sbtron.co.kr 
> website.
> 
> gc
> 
> On 05/11/2018 07:16 PM, CubeCentral wrote:
>> Hello All!
>> 
>> 
>> 
>> I would like to enlist your help in identifying this "surplus Timing
>> Module":  https://imgur.com/a/Psw8gP7
>> 
>> 
>> 
>> All the hints I've been given are:
>> 
>> - Purchased about a decade ago
>> 
>> - Might use a Motorola DSP as the processor
>> 
>> 
>> 
>> A quick google search lead me to a possible description:
>> 
>> "High speed, hitless, ultra low jitter timing module for OC-N line
>> interfaces:  The TF Systems / ATiMe-LC is a timing reference source 
>> for OC-N and STM-N interfaces. It complements TeraSync's central 
>> timing modules to provide a complete and redundant timing solution at the 
>> system level."
>> 
>> 
>> 
>> ...but I'm unsure if that is 100% the same module.  If you would like 
>> to get some different photos, please let me know and I will see what 
>> I can do.  Any thoughts or ideas would be greatly appreciated!  Thanks!
>> 
>> 
>> 
>> -Randal   (at CubeCentral)
>> 
> ___
> 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] Help Identifying this surplus Timing Module

[Bob kb8tq]

Hi

Ok, the gizmo on the front it an Altera CPLD. Not a lot of gates, so not a lot 
going 
on there. Whatever the real functions are, they are in the chip with no 
labeling. 

Even with the full information (let’s say): 

Takes in a 16 stream OC-blah blah and provides the following alarms on the 
status
channel. Hookup up the data stream and backup to pins X and Y. Status alarms 
also come
out on A, B, and C. Power is 12 V +/- 10% on pin M. Enable and control are on 
pins
E,F,G. 

Unless you happen to be building an OC-3 system in the basement and have all
the optical fiber stuff to do it …. not a lot of use. It is very similar to a 
lot of product
I designed over the years. It likely does a great job in it’s intended OEM 
application.
It’s pretty much useless for anything more general purpose as it is right now.

Without a schematic, the source code for the DSP and CPLD  and the proper tool 
sets, not much you can modify it to do. Even with all that stuff, probably the 
best you 
could do is a fairly basic 1 pps in. to  38.88 MHz) / M  out PLL. 

Indeed this *is* where timing has gone over the last few decades. TimeNuts 
normally may 
not look at telecom timing as an exciting thing. There is a vast amount of gear 
that 
has been built to distribute signals inside these networks. As far as Crazy Bob 
at
home is concerned, it’s all out of reach. It also is all designed for 
maintenance of 
data sync rather than time of day. It’s still very much time, just a different 
way of
looking at it. 

Bob

> On May 11, 2018, at 11:45 PM, CubeCentral  wrote:
> 
> Thank you bob and Gary for your investigations!  I appreciate it!  Here are a 
> couple more views:
> 
> https://imgur.com/a/auWdXvq
> 
> "This is the picture with sticker removed.   The large IC at the back has its 
> label scratched off.  ... that was intentional, but he has a note saying it 
> is a member of Motorola DSP56300 family. It was likely purchased in 2010 
> based on an eBay invoice which has no date on it, but the scanned date was 
> Feb 2011."
> 
> If anyone else has any more ideas, I would gladly hear them!  Thanks again!
> 
>   -Randal   (at CubeCentral)
> 
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Gary Chatters
> Sent: Friday, May 11, 2018 19:07
> To: time-nuts@febo.com
> Subject: Re: [time-nuts] Help Identifying this surplus Timing Module
> 
> A little Googling found a two page datasheet.  It doesn't tell you much more 
> than what you already found out, but does have specifications.
> 
> I can't figure out the correct link to include here, but a Google search with 
> the string "ATiMe-s 38.88" (don't include the quotes) should bring up the 
> link in the first couple of hits.  It is a PDF at the www.sbtron.co.kr 
> website.
> 
> gc
> 
> On 05/11/2018 07:16 PM, CubeCentral wrote:
>> Hello All!
>> 
>> 
>> 
>> I would like to enlist your help in identifying this "surplus Timing
>> Module":  https://imgur.com/a/Psw8gP7
>> 
>> 
>> 
>> All the hints I've been given are:
>> 
>> - Purchased about a decade ago
>> 
>> - Might use a Motorola DSP as the processor
>> 
>> 
>> 
>> A quick google search lead me to a possible description:
>> 
>> "High speed, hitless, ultra low jitter timing module for OC-N line
>> interfaces:  The TF Systems / ATiMe-LC is a timing reference source for OC-N
>> and STM-N interfaces. It complements TeraSync's central timing modules to
>> provide a complete and redundant timing solution at the system level."
>> 
>> 
>> 
>> ...but I'm unsure if that is 100% the same module.  If you would like to get
>> some different photos, please let me know and I will see what I can do.  Any
>> thoughts or ideas would be greatly appreciated!  Thanks!
>> 
>> 
>> 
>> -Randal   (at CubeCentral)
>> 
> ___
> 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.

Re: [time-nuts] Help Identifying this surplus Timing Module

[CubeCentral]

Thank you bob and Gary for your investigations!  I appreciate it!  Here are a 
couple more views:

https://imgur.com/a/auWdXvq

"This is the picture with sticker removed.   The large IC at the back has its 
label scratched off.  ... that was intentional, but he has a note saying it is 
a member of Motorola DSP56300 family. It was likely purchased in 2010 based on 
an eBay invoice which has no date on it, but the scanned date was Feb 2011."

If anyone else has any more ideas, I would gladly hear them!  Thanks again!

-Randal   (at CubeCentral)


-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Gary Chatters
Sent: Friday, May 11, 2018 19:07
To: time-nuts@febo.com
Subject: Re: [time-nuts] Help Identifying this surplus Timing Module

A little Googling found a two page datasheet.  It doesn't tell you much more 
than what you already found out, but does have specifications.

I can't figure out the correct link to include here, but a Google search with 
the string "ATiMe-s 38.88" (don't include the quotes) should bring up the link 
in the first couple of hits.  It is a PDF at the www.sbtron.co.kr website.

gc

On 05/11/2018 07:16 PM, CubeCentral wrote:
> Hello All!
> 
>   
> 
> I would like to enlist your help in identifying this "surplus Timing
> Module":  https://imgur.com/a/Psw8gP7
> 
>   
> 
> All the hints I've been given are:
> 
> - Purchased about a decade ago
> 
> - Might use a Motorola DSP as the processor
> 
>   
> 
> A quick google search lead me to a possible description:
> 
> "High speed, hitless, ultra low jitter timing module for OC-N line
> interfaces:  The TF Systems / ATiMe-LC is a timing reference source for OC-N
> and STM-N interfaces. It complements TeraSync's central timing modules to
> provide a complete and redundant timing solution at the system level."
> 
>   
> 
> ...but I'm unsure if that is 100% the same module.  If you would like to get
> some different photos, please let me know and I will see what I can do.  Any
> thoughts or ideas would be greatly appreciated!  Thanks!
> 
>   
> 
>  -Randal   (at CubeCentral)
> 
___
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] Help Identifying this surplus Timing Module

[Gary Chatters]

A little Googling found a two page datasheet.  It doesn't tell you much 
more than what you already found out, but does have specifications.


I can't figure out the correct link to include here, but a Google search 
with the string "ATiMe-s 38.88" (don't include the quotes) should bring 
up the link in the first couple of hits.  It is a PDF at the 
www.sbtron.co.kr website.


gc

On 05/11/2018 07:16 PM, CubeCentral wrote:

Hello All!

  


I would like to enlist your help in identifying this "surplus Timing
Module":  https://imgur.com/a/Psw8gP7

  


All the hints I've been given are:

- Purchased about a decade ago

- Might use a Motorola DSP as the processor

  


A quick google search lead me to a possible description:

"High speed, hitless, ultra low jitter timing module for OC-N line
interfaces:  The TF Systems / ATiMe-LC is a timing reference source for OC-N
and STM-N interfaces. It complements TeraSync's central timing modules to
provide a complete and redundant timing solution at the system level."

  


...but I'm unsure if that is 100% the same module.  If you would like to get
some different photos, please let me know and I will see what I can do.  Any
thoughts or ideas would be greatly appreciated!  Thanks!

  


 -Randal   (at CubeCentral)


___
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] Help Identifying this surplus Timing Module

[Bob kb8tq]

Hi

The big chip with the sticker on it is an Altera FPGA. A picture of the back
side might help a little (if there is anything on the back side …).

Simple answer - it’s a nice source of parts ….

Bob

> On May 11, 2018, at 7:16 PM, CubeCentral  wrote:
> 
> Hello All!
> 
> 
> 
> I would like to enlist your help in identifying this "surplus Timing
> Module":  https://imgur.com/a/Psw8gP7 
> 
> 
> 
> All the hints I've been given are:
> 
> - Purchased about a decade ago
> 
> - Might use a Motorola DSP as the processor
> 
> 
> 
> A quick google search lead me to a possible description:
> 
> "High speed, hitless, ultra low jitter timing module for OC-N line
> interfaces:  The TF Systems / ATiMe-LC is a timing reference source for OC-N
> and STM-N interfaces. It complements TeraSync's central timing modules to
> provide a complete and redundant timing solution at the system level."
> 
> 
> 
> ...but I'm unsure if that is 100% the same module.  If you would like to get
> some different photos, please let me know and I will see what I can do.  Any
> thoughts or ideas would be greatly appreciated!  Thanks!
> 
> 
> 
>-Randal   (at CubeCentral)
> 
> ___
> 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] Help Identifying this surplus Timing Module

[Bob kb8tq]

Hi

Given the frequency of the oscillator, it’s some sort of sync module for a 
telecom system. What data rate and what sort of coding …. who knows …

Bob

> On May 11, 2018, at 7:16 PM, CubeCentral  wrote:
> 
> Hello All!
> 
> 
> 
> I would like to enlist your help in identifying this "surplus Timing
> Module":  https://imgur.com/a/Psw8gP7 
> 
> 
> 
> All the hints I've been given are:
> 
> - Purchased about a decade ago
> 
> - Might use a Motorola DSP as the processor
> 
> 
> 
> A quick google search lead me to a possible description:
> 
> "High speed, hitless, ultra low jitter timing module for OC-N line
> interfaces:  The TF Systems / ATiMe-LC is a timing reference source for OC-N
> and STM-N interfaces. It complements TeraSync's central timing modules to
> provide a complete and redundant timing solution at the system level."
> 
> 
> 
> ...but I'm unsure if that is 100% the same module.  If you would like to get
> some different photos, please let me know and I will see what I can do.  Any
> thoughts or ideas would be greatly appreciated!  Thanks!
> 
> 
> 
>-Randal   (at CubeCentral)
> 
> ___
> 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] Help improving impedance measurement by having a better clock

[Bob kb8tq]

Hi

I believe we are talking about material impedances here rather than electrical 
impedance. One of the 
weird things about this is that frequency (as in frequency accuracy) *can* be a 
contributor to the resultant
error. Thus my original question about just what the concern actually is…..

Bob

> On Apr 8, 2018, at 4:52 PM, Brooke Clarke  wrote:
> 
> Hi Daniel:
> 
> If you're concerned with accuracy of impedance measurements you might want to 
> spent a lot of time studying "The Impedance Measurement Handbook", it's the 
> bible for this.  The way the measurement is made has a huge impact on the 
> accuracy.  For example using a vector network analyzer to measure an 
> impedance that's not near 50 Ohms causes poor results.
> http://prc68.com/I/Z.shtml#KeyDocs
> For frequencies low enough to use 4 Terminal Pair, that's the way to go.
> http://www.prc68.com/I/HP4274_4275_LCR.shtml#MeasMtd
> 
> -- 
> Have Fun,
> 
> Brooke Clarke
> http://www.PRC68.com
> http://www.end2partygovernment.com/2012Issues.html
> 
>  Original Message 
>> I´m a long time time-nuts lurker (I posted here just a dozen times). I make
>> a few impedance measurement systems for material analysis (i´m a single man
>> shop doing custom hardware for clients). Usually they´re based around a
>> STM32F4 / F7 microprocessor: DAC generates sine signal (1-400KHz), ADCs
>> measure them back, a few calculations later we have modulus / phase. I
>> always used internal ADCs and DACs (12 bits each).
>> 
>> I now want to use external ADCs and DACs with more bits to push the limits,
>> but i´m afraid that the poor performance of the STM32 PLL that drives the
>> clock will get in the way, so I plan to drive the "load" of both DAC and
>> ADCs from an external signal derived from a TCXO using a clock divider.
>> 
>> To get some sense of how much things are improving (or not) I need to
>> somehow measure these clocks and get a meaningfull measurement about how
>> good (or bad) they are.
>> 
>> The tools I have are a Hameg HM8123 with a 10MHz OCXO I shoehorned inside
>> and a Picotest U6200A with original OCXO. I can log period information from
>> both using serial/USB port. I can make a histogram of the data. I don´t
>> have any better idea about what to do and would like to hear from you :)
>> 
>> Daniel
>> ___
>> 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.

Re: [time-nuts] Help improving impedance measurement by having a better clock

[Brooke Clarke]

Hi Daniel:

If you're concerned with accuracy of impedance measurements you might want to spent a lot of time studying "The 
Impedance Measurement Handbook", it's the bible for this.  The way the measurement is made has a huge impact on the 
accuracy.  For example using a vector network analyzer to measure an impedance that's not near 50 Ohms causes poor results.

http://prc68.com/I/Z.shtml#KeyDocs
For frequencies low enough to use 4 Terminal Pair, that's the way to go.
http://www.prc68.com/I/HP4274_4275_LCR.shtml#MeasMtd

--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html

 Original Message 

I´m a long time time-nuts lurker (I posted here just a dozen times). I make
a few impedance measurement systems for material analysis (i´m a single man
shop doing custom hardware for clients). Usually they´re based around a
STM32F4 / F7 microprocessor: DAC generates sine signal (1-400KHz), ADCs
measure them back, a few calculations later we have modulus / phase. I
always used internal ADCs and DACs (12 bits each).

I now want to use external ADCs and DACs with more bits to push the limits,
but i´m afraid that the poor performance of the STM32 PLL that drives the
clock will get in the way, so I plan to drive the "load" of both DAC and
ADCs from an external signal derived from a TCXO using a clock divider.

To get some sense of how much things are improving (or not) I need to
somehow measure these clocks and get a meaningfull measurement about how
good (or bad) they are.

The tools I have are a Hameg HM8123 with a 10MHz OCXO I shoehorned inside
and a Picotest U6200A with original OCXO. I can log period information from
both using serial/USB port. I can make a histogram of the data. I don´t
have any better idea about what to do and would like to hear from you :)

Daniel
___
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] Help improving impedance measurement by having a better clock

[Attila Kinali]

On Sat, 7 Apr 2018 22:54:42 -0300
Daniel Mendes  wrote:

> I´m a long time time-nuts lurker (I posted here just a dozen times). I make
> a few impedance measurement systems for material analysis (i´m a single man
> shop doing custom hardware for clients). Usually they´re based around a
> STM32F4 / F7 microprocessor: DAC generates sine signal (1-400KHz), ADCs
> measure them back, a few calculations later we have modulus / phase. I
> always used internal ADCs and DACs (12 bits each).

The STM32's are known for their poorly performing ADCs and DACs,
even using an external one with the same bit width will increase
your performance. That said, what is your actual sample rate?
I would guess, if you use the timer unit to generate the pulses,
your jitter would be less than 10ps rms, probably even less than 1ps rms.
10ps rms limits your resolution to something like 14-15bit @500kHz,
1ps rms should be around 18bits, if I'm not mistaken. 

To measure the performance, I would just build the device and feed it
with an appropriate sine wave. Then analyze the SNR and spurs of the
sampled signal.

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] Help improving impedance measurement by having a better clock

[Bob kb8tq]

Hi

I’m not at all sure that the clocks will really get into the measurements. The 
PLL does 
have jitter, but it has zero frequency error. 

One way to get around the whole issue is to use an outboard device with its own 
clock. 
400 KHz is a bit high for the integrated audio ADC / DAC parts. Drop down a bit 
and 
they will do quite well. Interface with an I2S port and away you go.

That said, are you concerned about frequency error or jitter? If it’s frequency 
error, you 
can get that pretty well a number of ways. The gotcha is an accurate reference. 
A GPSDO
is by far the cheapest way to solve that problem.

If you are concerned about jitter, the next question is: over what range? It is 
reasonable 
to guess that the PLL follows the input to a pretty good degree for long time 
periods. At
some point the PLL loop filter allows it to move around a bit. The issue here 
is that the loop 
filter likely is in the audio range. You are after jitter at time periods << 1 
second. That gets
a bit gear specific. You also are after numbers in the nanosecond (or sub 
nanosecond) range.
That increases the complexity. 

So - what are you after? 

Bob

> On Apr 7, 2018, at 9:54 PM, Daniel Mendes  wrote:
> 
> I´m a long time time-nuts lurker (I posted here just a dozen times). I make
> a few impedance measurement systems for material analysis (i´m a single man
> shop doing custom hardware for clients). Usually they´re based around a
> STM32F4 / F7 microprocessor: DAC generates sine signal (1-400KHz), ADCs
> measure them back, a few calculations later we have modulus / phase. I
> always used internal ADCs and DACs (12 bits each).
> 
> I now want to use external ADCs and DACs with more bits to push the limits,
> but i´m afraid that the poor performance of the STM32 PLL that drives the
> clock will get in the way, so I plan to drive the "load" of both DAC and
> ADCs from an external signal derived from a TCXO using a clock divider.
> 
> To get some sense of how much things are improving (or not) I need to
> somehow measure these clocks and get a meaningfull measurement about how
> good (or bad) they are.
> 
> The tools I have are a Hameg HM8123 with a 10MHz OCXO I shoehorned inside
> and a Picotest U6200A with original OCXO. I can log period information from
> both using serial/USB port. I can make a histogram of the data. I don´t
> have any better idea about what to do and would like to hear from you :)
> 
> Daniel
> ___
> 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] help

[Adrian Godwin]

Since you have an impulse clock system, you could use that to fire the bell
- you could modify a slave clock or use one of these :

http://www.ebay.co.uk/itm/111982558390

or possibly this one :

http://www.ebay.co.uk/itm/291730808914

The first seems rather expensive to me, I've more commonly seen them at
more like the second price. You can probably find one nearer to you.

You still then have the problem that you want to drive the impulse from an
accurate time source. There are impulse drivers that operate from a cheap
crystal available on ebay. I don't think we want to talk about those here.

A nicer solution would be to transform the 1pps signal from a gps receiver
into a suitable pulse : again, this is easy to do with a microcontroller
and a small amount of electronics, but it seems like a useful idea. Perhaps
worth working out properly and publishing.

I have in the past run a slave clock from an RS232 port : it needs a small
circuit to generate the current pulse (powered by the RS232 port itself)
and operated by a small script program on a computer, so locked to NTP.
However, it needs a computer (preferably Unix) running 24/7.




On Mon, May 2, 2016 at 7:11 PM, Mark Sims  wrote:

> If you want to get fancy you could modify Lady Heather to do the deed.
> Heather has a "singing clock" mode and a cuckoo/chime clock mode for
> playing sound files at various times.  It also has routines for controlling
> the serial port DTR and RTS lines (currently used for PWMing a fan if
> temperature control mode is enabled).   You could add some code to the
> program to pulse the DTR or RTS line... these can easily drive a solid
> state relay.
>
>
> ___
> 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] help

[Tom Van Baak]

It turns out OP (Bill Baker) is using a very nice GMR1000 GPS time standard:

http://www.masterclock.com/products/master-clocks/gmr1000/

So that's why he was asking about an off-the-shelf device to turn SMPTE into an 
hourly switch for his fog bell.

Since the GMR1000 also has a network connection, the proposed Raspberry Pi 
solutions will work. In addition, the GMR1000 has a serial port that will 
output NMEA (GPZDA), so even a simple PIC or Arduino solution is possible.

Given a choice between RS232 + Arduino on the one hand and LAN + Raspberry Pi + 
Linux + NTP on the other, I'd pick Arduino. But I know people that would throw 
Linux at this; everyone has their favorite hammer. In fact, I bet Walter 
Shawlee could design a simple TTL shift-register circuit that would parse the 
RS232 GPZDA bitstream and drive the fog bell on the hour. And a hundred years 
from now his TTL board and the bell would be the only parts still working.

/tvb

For more information read GMR1000.pdf and GMR+Series+User+Manual.pdf from the 
site above.


> - Original Message - 
> From: "Bill Baker via time-nuts" 
> Sent: Sunday, May 01, 2016 12:26 PM
> Subject: [time-nuts] help
>
> My problem:  I'd like some kind of off-the-shelf device that can take the 
> time code
> and switch on or impulse another circuit-- specifically  I'd like to trigger 
> a 180 year-old
> fog bell (I'm a lighthouse nut as well, www.henryisland.com) on the hour and 
> maybe
> be able to impulse my minute school clocks.  I'm not at this group's 
> technical level,
> so it's got to be pretty easy to program. So I need a box that I can program 
> with
> SMPTE time in and a timed switch impulse out.  Any ideas?
>Many thanks,
>W1BKR

___
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] help

[albertson . chris]

You don't care about the lag in cron. You care about the variation of the lag.  
 

Then again. The main cause of lag in a fog horn is the speed of sound  

You set cron to fire at T minus the average lag time. 

> On May 2, 2016, at 2:36 PM, Nick Sayer via time-nuts  
> wrote:
> 
> 
>> On May 2, 2016, at 9:51 AM, jimlux  wrote:
>> 
>> 
>> The real question is whether "cron" is timely enough.  No matter, just write 
>> a script (or python) that reads time in a loop (and you can put a sleep in 
>> there) and pulses the GPIO when needed.
> 
> A Raspberry Pi with nothing else on its plate will have a cron-to-shell 
> script latency easily under 100 ms, possibly under 10.
> 
> If it were me and I were triggering a relay for some sort of external 
> circuit, I’d probably be happy it was on the right side of 500 ms. If I cared 
> more than that, then step 1 would be to do as others have suggested and come 
> up with a microcontroller + GPS solution instead of NTP + cron. Ironically, 
> that’d be around the same price (albeit more engineering work).
> ___
> 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] help

[Martin Burnicki]

Am 3. Mai 2016 18:06:49 MESZ, schrieb Hendrik Dietrich :
>
>Picking up the time from a DAYTIME Server is easier to implement than 
>NTP, these respond just with a string containing date and time.

If you don't want to run NTP then eventually you sould use the "time" protocol 
rather than daytime . 

"time" returns UTC,  but IIRC then daytime can even return some local time,  
and the string format may depend on / vary wit the server you are contacting. 
It's more for human interaction. 

Martin 

___
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] help

[Bob Camp]

Hi

A cheap GPS module and any of the nearly infinite number of sub $20 “demo 
boards” would make 
short work of looking at the pps, the time string out of the GPS and figuring 
out when it’s the top of the 
hour. I doubt it’s over 200 lines of code. I’m sure *somebody* will pop up with 
an example well below
that. No need for an OS. No need for anything complex. There’s sure to be 
enough room even on a $2 board
to include added stuff like real time clock driver and correcting the “local 
time” against GPS. 

Bob

> On May 2, 2016, at 5:36 PM, Nick Sayer via time-nuts  
> wrote:
> 
> 
>> On May 2, 2016, at 9:51 AM, jimlux  wrote:
>> 
>> 
>> The real question is whether "cron" is timely enough.  No matter, just write 
>> a script (or python) that reads time in a loop (and you can put a sleep in 
>> there) and pulses the GPIO when needed.
>> 
> 
> A Raspberry Pi with nothing else on its plate will have a cron-to-shell 
> script latency easily under 100 ms, possibly under 10.
> 
> If it were me and I were triggering a relay for some sort of external 
> circuit, I’d probably be happy it was on the right side of 500 ms. If I cared 
> more than that, then step 1 would be to do as others have suggested and come 
> up with a microcontroller + GPS solution instead of NTP + cron. Ironically, 
> that’d be around the same price (albeit more engineering work).
> ___
> 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] help

[Nick Sayer via time-nuts]

> On May 2, 2016, at 9:51 AM, jimlux  wrote:
> 
> 
> The real question is whether "cron" is timely enough.  No matter, just write 
> a script (or python) that reads time in a loop (and you can put a sleep in 
> there) and pulses the GPIO when needed.
> 

A Raspberry Pi with nothing else on its plate will have a cron-to-shell script 
latency easily under 100 ms, possibly under 10.

If it were me and I were triggering a relay for some sort of external circuit, 
I’d probably be happy it was on the right side of 500 ms. If I cared more than 
that, then step 1 would be to do as others have suggested and come up with a 
microcontroller + GPS solution instead of NTP + cron. Ironically, that’d be 
around the same price (albeit more engineering work).
___
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] help

[Adrian Godwin]

Here's a possible solution. It's ethernet-connected and will switch a 10A
output. It's made for UK use but would probably be fine if you have a 220V
supply. It doesn't say whether it tracks NTP, but looking at the specs i'd
suggest it's linux inside and can do that.

http://www.audon.co.uk/webcontrol/EZ-21g.html


On Mon, May 2, 2016 at 7:21 PM, Adrian Godwin  wrote:

> They're a LED and some current limiting. Some are specced as low as 3V and
> 10mA but they're optimised for 12-24. I'd definitely use a transistor and
> at least 5V, especially from something like a Pi or Teensy, which have 3v3
> logic levels.
>
> My reading is that Bill doesn't want to mess around with micros and
> electronics, though. He wants an off-the-shelf timeswitch that - for
> perfectly understandable reasons of engineering pedantry - is always
> correct.
>
> On Mon, May 2, 2016 at 5:56 PM, jimlux  wrote:
>
>> On 5/2/16 8:24 AM, Nick Sayer via time-nuts wrote:
>>
>>> To flesh this out a bit more, on a Raspberry Pi, it would be easy to
>>> make a cron job that would pulse a GPIO pin high. They really *want* you to
>>> use Python (thus the name), but this is easy to do in just a shell script.
>>> First, do this to set things up:
>>>
>>> #! /bin/sh
>>>
>>> GPIO_PIN=9 # pick whatever one you like
>>>
>>> echo $GPIO_PIN > /sys/class/gpio/export
>>> echo out > /sys/class/gpio/gpio${GPIO_PIN}/direction
>>> echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value
>>>
>>> Next, run this script out of cron:
>>>
>>> #! /bin/sh
>>>
>>> GPIO_PIN=9
>>> echo 1 > /sys/class/gpio/gpio${GPIO_PIN}/value
>>> sleep 1
>>> echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value
>>>
>>> That will make a positive going pulse with the leading edge synchronized
>>> to cron (for sufficiently vague definitions of “synchronized”).
>>>
>>> As for the hardware side, take the GPIO pin and connect a 10k resistor
>>> between it and the base of a 2N4401 transistor. Connect the emitter to
>>> ground and the collector is a classic “open collector” switching output.
>>> Think of it like a switch connection to ground. When it’s on, there is a
>>> low impedance path to ground. When it’s off, it’s high impedance. You can
>>> use it to work a relay (be sure to add a flyback diode across the relay
>>> coil) or directly to switch any load that doesn’t exceed the abilities of
>>> the transistor.
>>>
>>> If you want to be a little safer, you can use an opto-isolator instead.
>>> Connect the GPIO pin to a 150 Ω resistor and then to the anode of the LED
>>> in an optoisolator. Connect the cathode to ground. The optoisolator itself
>>> can be either a phototransistor type or a driver triac type (the latter
>>> would be used to drive a power triac to switch AC loads on and off).
>>>
>>>
>>>
>>
>> SSR data sheet at mouser (they are <$20)
>> http://www.mouser.com/ds/2/307/g3na_ds_e_11_1_csm165-892371.pdf
>>
>> myriad varieties of inputs and outputs, whether it has an indicator (nice
>> for testing), whether it's a zero voltage switch.
>>
>> BUT.. it kind of looks like it wants to see 4V to turn on for sure. Maybe
>> your 5V USB powered widget puts out that on a GPIO pin, maybe it doesn't.
>> I've had very mixed luck with driving SSRs directly from logic (because the
>> real threshold voltage and the real logic output voltage vary with
>> temperature, for instance).
>>
>> I'd use the extra transistor as an open collector and a 12V wall wart or
>> similar to provide the current for the SSR input.
>>
>>
>>
>>
>> ___
>> 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] help

[Adrian Godwin]

They're a LED and some current limiting. Some are specced as low as 3V and
10mA but they're optimised for 12-24. I'd definitely use a transistor and
at least 5V, especially from something like a Pi or Teensy, which have 3v3
logic levels.

My reading is that Bill doesn't want to mess around with micros and
electronics, though. He wants an off-the-shelf timeswitch that - for
perfectly understandable reasons of engineering pedantry - is always
correct.

On Mon, May 2, 2016 at 5:56 PM, jimlux  wrote:

> On 5/2/16 8:24 AM, Nick Sayer via time-nuts wrote:
>
>> To flesh this out a bit more, on a Raspberry Pi, it would be easy to make
>> a cron job that would pulse a GPIO pin high. They really *want* you to use
>> Python (thus the name), but this is easy to do in just a shell script.
>> First, do this to set things up:
>>
>> #! /bin/sh
>>
>> GPIO_PIN=9 # pick whatever one you like
>>
>> echo $GPIO_PIN > /sys/class/gpio/export
>> echo out > /sys/class/gpio/gpio${GPIO_PIN}/direction
>> echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value
>>
>> Next, run this script out of cron:
>>
>> #! /bin/sh
>>
>> GPIO_PIN=9
>> echo 1 > /sys/class/gpio/gpio${GPIO_PIN}/value
>> sleep 1
>> echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value
>>
>> That will make a positive going pulse with the leading edge synchronized
>> to cron (for sufficiently vague definitions of “synchronized”).
>>
>> As for the hardware side, take the GPIO pin and connect a 10k resistor
>> between it and the base of a 2N4401 transistor. Connect the emitter to
>> ground and the collector is a classic “open collector” switching output.
>> Think of it like a switch connection to ground. When it’s on, there is a
>> low impedance path to ground. When it’s off, it’s high impedance. You can
>> use it to work a relay (be sure to add a flyback diode across the relay
>> coil) or directly to switch any load that doesn’t exceed the abilities of
>> the transistor.
>>
>> If you want to be a little safer, you can use an opto-isolator instead.
>> Connect the GPIO pin to a 150 Ω resistor and then to the anode of the LED
>> in an optoisolator. Connect the cathode to ground. The optoisolator itself
>> can be either a phototransistor type or a driver triac type (the latter
>> would be used to drive a power triac to switch AC loads on and off).
>>
>>
>>
>
> SSR data sheet at mouser (they are <$20)
> http://www.mouser.com/ds/2/307/g3na_ds_e_11_1_csm165-892371.pdf
>
> myriad varieties of inputs and outputs, whether it has an indicator (nice
> for testing), whether it's a zero voltage switch.
>
> BUT.. it kind of looks like it wants to see 4V to turn on for sure. Maybe
> your 5V USB powered widget puts out that on a GPIO pin, maybe it doesn't.
> I've had very mixed luck with driving SSRs directly from logic (because the
> real threshold voltage and the real logic output voltage vary with
> temperature, for instance).
>
> I'd use the extra transistor as an open collector and a 12V wall wart or
> similar to provide the current for the SSR input.
>
>
>
>
> ___
> 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] help

[jimlux]

On 5/2/16 8:24 AM, Nick Sayer via time-nuts wrote:

To flesh this out a bit more, on a Raspberry Pi, it would be easy to make a 
cron job that would pulse a GPIO pin high. They really *want* you to use Python 
(thus the name), but this is easy to do in just a shell script. First, do this 
to set things up:

#! /bin/sh

GPIO_PIN=9 # pick whatever one you like

echo $GPIO_PIN > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio${GPIO_PIN}/direction
echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value

Next, run this script out of cron:

#! /bin/sh

GPIO_PIN=9
echo 1 > /sys/class/gpio/gpio${GPIO_PIN}/value
sleep 1
echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value

That will make a positive going pulse with the leading edge synchronized to 
cron (for sufficiently vague definitions of “synchronized”).

As for the hardware side, take the GPIO pin and connect a 10k resistor between 
it and the base of a 2N4401 transistor. Connect the emitter to ground and the 
collector is a classic “open collector” switching output. Think of it like a 
switch connection to ground. When it’s on, there is a low impedance path to 
ground. When it’s off, it’s high impedance. You can use it to work a relay (be 
sure to add a flyback diode across the relay coil) or directly to switch any 
load that doesn’t exceed the abilities of the transistor.

If you want to be a little safer, you can use an opto-isolator instead. Connect 
the GPIO pin to a 150 Ω resistor and then to the anode of the LED in an 
optoisolator. Connect the cathode to ground. The optoisolator itself can be 
either a phototransistor type or a driver triac type (the latter would be used 
to drive a power triac to switch AC loads on and off).





SSR data sheet at mouser (they are <$20)
http://www.mouser.com/ds/2/307/g3na_ds_e_11_1_csm165-892371.pdf

myriad varieties of inputs and outputs, whether it has an indicator 
(nice for testing), whether it's a zero voltage switch.


BUT.. it kind of looks like it wants to see 4V to turn on for sure. 
Maybe your 5V USB powered widget puts out that on a GPIO pin, maybe it 
doesn't. I've had very mixed luck with driving SSRs directly from logic 
(because the real threshold voltage and the real logic output voltage 
vary with temperature, for instance).


I'd use the extra transistor as an open collector and a 12V wall wart or 
similar to provide the current for the SSR input.




___
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] help

[jimlux]

On 5/2/16 8:24 AM, Nick Sayer via time-nuts wrote:

To flesh this out a bit more, on a Raspberry Pi, it would be easy to make a 
cron job that would pulse a GPIO pin high. They really *want* you to use Python 
(thus the name), but this is easy to do in just a shell script. First, do this 
to set things up:

#! /bin/sh

GPIO_PIN=9 # pick whatever one you like

echo $GPIO_PIN > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio${GPIO_PIN}/direction
echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value

Next, run this script out of cron:

#! /bin/sh

GPIO_PIN=9
echo 1 > /sys/class/gpio/gpio${GPIO_PIN}/value
sleep 1
echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value

That will make a positive going pulse with the leading edge synchronized to 
cron (for sufficiently vague definitions of “synchronized”).

As for the hardware side, take the GPIO pin and connect a 10k resistor between 
it and the base of a 2N4401 transistor. Connect the emitter to ground and the 
collector is a classic “open collector” switching output. Think of it like a 
switch connection to ground. When it’s on, there is a low impedance path to 
ground. When it’s off, it’s high impedance. You can use it to work a relay (be 
sure to add a flyback diode across the relay coil) or directly to switch any 
load that doesn’t exceed the abilities of the transistor.

If you want to be a little safer, you can use an opto-isolator instead. Connect 
the GPIO pin to a 150 Ω resistor and then to the anode of the LED in an 
optoisolator. Connect the cathode to ground. The optoisolator itself can be 
either a phototransistor type or a driver triac type (the latter would be used 
to drive a power triac to switch AC loads on and off).




Or just buy a DC controlled solid state relay..  The NPN open collector 
current booster might be nice still, but the SSR takes care of all the 
galvanic isolation, etc.



The real question is whether "cron" is timely enough.  No matter, just 
write a script (or python) that reads time in a loop (and you can put a 
sleep in there) and pulses the GPIO when needed.






___
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] help

[Nick Sayer via time-nuts]

To flesh this out a bit more, on a Raspberry Pi, it would be easy to make a 
cron job that would pulse a GPIO pin high. They really *want* you to use Python 
(thus the name), but this is easy to do in just a shell script. First, do this 
to set things up:

#! /bin/sh

GPIO_PIN=9 # pick whatever one you like

echo $GPIO_PIN > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio${GPIO_PIN}/direction
echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value

Next, run this script out of cron:

#! /bin/sh

GPIO_PIN=9
echo 1 > /sys/class/gpio/gpio${GPIO_PIN}/value
sleep 1
echo 0 > /sys/class/gpio/gpio${GPIO_PIN}/value

That will make a positive going pulse with the leading edge synchronized to 
cron (for sufficiently vague definitions of “synchronized”).

As for the hardware side, take the GPIO pin and connect a 10k resistor between 
it and the base of a 2N4401 transistor. Connect the emitter to ground and the 
collector is a classic “open collector” switching output. Think of it like a 
switch connection to ground. When it’s on, there is a low impedance path to 
ground. When it’s off, it’s high impedance. You can use it to work a relay (be 
sure to add a flyback diode across the relay coil) or directly to switch any 
load that doesn’t exceed the abilities of the transistor.

If you want to be a little safer, you can use an opto-isolator instead. Connect 
the GPIO pin to a 150 Ω resistor and then to the anode of the LED in an 
optoisolator. Connect the cathode to ground. The optoisolator itself can be 
either a phototransistor type or a driver triac type (the latter would be used 
to drive a power triac to switch AC loads on and off).


> On May 1, 2016, at 6:30 PM, Chris Albertson  wrote:
> 
>> But are you sure you want SMPTE... Do you have a source already?
>> 
>> 
> You don't need GPS or SMPTE if you have an Internet connection.  The
> computer can use a set of NTP servers from the "pool" to get time.  The
> result is good enough that the seed of sound delay resulting from your
> random distance to the bell will be the largest source of error.
> 
> If you convert timing errors to distance at the speed of sound.   You would
> need the GPS only if you car about bell to ear distances of about one foot,
> give or take
> 
> So for this use case the OP does not need a GPS or even a SMTPE connection
> just a WiFi link to the internet would be more than enough for controlling
> a horn blast from a light house
> 
> 
> -- 
> 
> 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] help

[jimlux]

On 5/1/16 6:30 PM, Chris Albertson wrote:

But are you sure you want SMPTE... Do you have a source already?



You don't need GPS or SMPTE if you have an Internet connection.  The
computer can use a set of NTP servers from the "pool" to get time.  The
result is good enough that the seed of sound delay resulting from your
random distance to the bell will be the largest source of error.

If you convert timing errors to distance at the speed of sound.   You would
need the GPS only if you car about bell to ear distances of about one foot,
give or take

So for this use case the OP does not need a GPS or even a SMTPE connection
just a WiFi link to the internet would be more than enough for controlling
a horn blast from a light house





However, depending on how much work you want to do, it's easier to 
decode the serial stream from a GPS receiver or SMPTE and close a relay, 
than it is to set up an internet connection, make sure it's not 
vulnerable, etc.etc.etc.


If you already have a PC with a connection, sure, it's straightforward, 
but if you're starting from scratch, the work to get the whole internet 
software stack up and running particularly on a small cheap board is 
substantial.


If you already have a Arduino/Beaglebone/Rpi set up, and safely 
connected to the internet, then you could just copy that; but if you've 
not done it before, it takes a while.



___
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] help

[Mike Cook]

> Le 2 mai 2016 à 03:14, Chris Albertson  a écrit :
> 
> On Sun, May 1, 2016 at 12:26 PM, Bill Baker via time-nuts <
> time-nuts@febo.com> wrote:
> 
>> My problem:  I'd like some kind of off-the-shelf device that can take the
>> time code and switch on or impulse another circuit-- specifically  I'd like
>> to trigger a 180 year-old fog bell (I'm a lighthouse nut as well,
>> www.henryisland.com) on the hour and maybe be able to impulse my minute
>> school clocks.  I'm not at this group's technical level, so it's got to be
>> pretty easy to program. So I need a box that I can program with SMPTE time
>> in and a timed switch impulse out.  Any ideas?
> 
> 
> I assume you only need to be accurate to within about 1/10th of a second or
> so.  Any general purpose computer like and old PC can do this but today
> you'd go with a Raspberry Pi 2 or some other single board computer.   The
> first step is to keep the computer's internal clock in sync with your time
> signal (NTP can do that and NTP will likely already be installed on the
> computer)  then if the computer is running a Unix-like OS (such as Linux,
> BSD or Mac OS X) there is a table you can set up that will run various apps
> at certain scheduled times.   You'd simply set s cron tab entry to blow the
> horn on every hour every hour.  

cron isn’t good enough for < 1s accuracy timing even with a GPS steered clock.
It only wakes up every minute and the time used scanning all crontab tables to 
see what needs to be run in that minute and scheduling those means that you 
rarely get a job executed in < 1s of the desired time. 

___
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] help

[Chris Albertson]

> But are you sure you want SMPTE... Do you have a source already?
>
>
You don't need GPS or SMPTE if you have an Internet connection.  The
computer can use a set of NTP servers from the "pool" to get time.  The
result is good enough that the seed of sound delay resulting from your
random distance to the bell will be the largest source of error.

If you convert timing errors to distance at the speed of sound.   You would
need the GPS only if you car about bell to ear distances of about one foot,
give or take

So for this use case the OP does not need a GPS or even a SMTPE connection
just a WiFi link to the internet would be more than enough for controlling
a horn blast from a light house


-- 

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] help

[Chris Albertson]

On Sun, May 1, 2016 at 12:26 PM, Bill Baker via time-nuts <
time-nuts@febo.com> wrote:

> My problem:  I'd like some kind of off-the-shelf device that can take the
> time code and switch on or impulse another circuit-- specifically  I'd like
> to trigger a 180 year-old fog bell (I'm a lighthouse nut as well,
> www.henryisland.com) on the hour and maybe be able to impulse my minute
> school clocks.  I'm not at this group's technical level, so it's got to be
> pretty easy to program. So I need a box that I can program with SMPTE time
> in and a timed switch impulse out.  Any ideas?


I assume you only need to be accurate to within about 1/10th of a second or
so.  Any general purpose computer like and old PC can do this but today
you'd go with a Raspberry Pi 2 or some other single board computer.   The
first step is to keep the computer's internal clock in sync with your time
signal (NTP can do that and NTP will likely already be installed on the
computer)  then if the computer is running a Unix-like OS (such as Linux,
BSD or Mac OS X) there is a table you can set up that will run various apps
at certain scheduled times.   You'd simply set s cron tab entry to blow the
horn on every hour every hour.   Not much software to write as this kind of
stuff (syncing to an external clock and doing things on a schedule) is
built in to the OS.

OK if you need to be much more accurate it gets harder but really this is a
audio alarm and the speed of sound is very slow such that the delay you'd
experience from sending 100 feet from the fog bell is longer than the delay
introduced by the software

So yjr only thing you need is to write software that does just one thing,
ring the bell then quit and let "crond" call it based on entries from the
table.

I see suggestion to use an Arduino or the like and program it.  That could
work too but if the little computer is powerful enough to run a unix-lil OS
you save some effort because they already come with built-in utilities to
do things on a schulue and to stay sync'd with an external clock signal.
-- 

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] help

[jimlux]

On 5/1/16 1:26 PM, jimlux wrote:

On 5/1/16 12:26 PM, Bill Baker via time-nuts wrote:

My problem:  I'd like some kind of off-the-shelf device that can take
the time code and switch on or impulse another circuit-- specifically
I'd like to trigger a 180 year-old fog bell (I'm a lighthouse nut as
well, www.henryisland.com) on the hour and maybe be able to impulse my
minute school clocks.  I'm not at this group's technical level, so
it's got to be pretty easy to program. So I need a box that I can
program with SMPTE time in and a timed switch impulse out.  Any ideas?
Many thanks,
W1BKR


An Arduino or Teensy (http://www.pjrc.com) are both trivially easy to
program and have easy interfaces (With a large number of off the shelf
interface widgets like relays, optoisolators, etc.).  There's probably
off the shelf code and hardware interfaces for decoding your SMPTE or
other time codes.



In fact
http://forum.arduino.cc/index.php?topic=8237.0

https://hackaday.io/project/7694-arduino-timecode-smpte-ltc-reader-generator-shield/log/27289-stripped-down-ltc-reader-code-for-arduino

references someone decoding SMPTE from an audio signal.



But are you sure you want SMPTE... Do you have a source already?


Seems to me you'd want something like a GPS receiver.. equally easy. 
I've got code the reads a Garmin GPS-18 on a teensy somewhere around, 
and I'm sure others have stuff for basically any GPS receiver made.


Lately, i've just been logging 1pps from various sources using the teensy.

After all, don't you want your fog bell to be accurate to fractions of a 
microsecond, because otherwise you're not really a time-nut .







___
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] help

[jimlux]

On 5/1/16 12:26 PM, Bill Baker via time-nuts wrote:

My problem:  I'd like some kind of off-the-shelf device that can take the time 
code and switch on or impulse another circuit-- specifically  I'd like to 
trigger a 180 year-old fog bell (I'm a lighthouse nut as well, 
www.henryisland.com) on the hour and maybe be able to impulse my minute school 
clocks.  I'm not at this group's technical level, so it's got to be pretty easy 
to program. So I need a box that I can program with SMPTE time in and a timed 
switch impulse out.  Any ideas?
Many thanks,
W1BKR


An Arduino or Teensy (http://www.pjrc.com) are both trivially easy to 
program and have easy interfaces (With a large number of off the shelf 
interface widgets like relays, optoisolators, etc.).  There's probably 
off the shelf code and hardware interfaces for decoding your SMPTE or 
other time codes.


The coding would be simple - the widget's not doing anything else, so 
there's nothing wrong with a structure like


void loop(){
if (msgavailable) {
get message
decode message
if right message{
digitalWrite(relaypin,HIGH)
sleep (10)
digitalWrite(relaypin,LOW)
}
}
}



___
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] Help with my ADEV measurement setup

[Dan Watson]

Oddly enough I do have a PPS output from the TCXO I was measuring. It's on
a little board I made and there is a PicDiv right on it. I'll have to play
around with that.

I did notice the aliasing issue trying to measure a 12MHz crystal. It
appeared to have incredible stability and accuracy for a plain old XO...
Also it has a frequency offset of over 1kHz, and I noticed that I had to
manually type in the correct initial frequency during setup to have
meaningful data in the frequency difference view. i.e, 12001053 instead of
12E6. But of course with a marginally stably oscillator, that poses a
problem. How long do I wait to find a mean frequency to type in...? It
makes total sense why this is so in TI mode, but still it's one more thing
to deal with.

I think I'll stick with frequency mode for most things. Many of the
oscillators I want to measure are right around 10^-8 or 10^-9, and I'd hate
to constantly be fighting the noise floor of the instrument. I'll treat the
data from frequency mode as relative and that should get me what I need. At
least until I own a better instrument.


Thanks

Dan

On Tue, Jun 30, 2015 at 10:49 PM, John Miles  wrote:

> Yep, it will ignore any non-numeric data like "us" suffixes.  It will
> always interpret incoming data as seconds, so the 1E-6 scale factor is
> appropriate if the counter is returning microseconds.  I'll tweak the
> mouseover help text for the scale factor field to clarify that.
>
> I think you're basically getting valid data.  The 53131A's one-shot
> resolution is 0.5 ns, and you're seeing about 2E-9 residual ADEV at t=1s.
> It's in the right ballpark, anyway... e.g., on a 20-ps HP 5370, the
> residual ADEV at t=1s will usually be in the neighborhood of 30-60 ps.
>
> I would, however, be worried about aliasing with a TCXO.  If its frequency
> is more than 5E-8 off -- meaning it drifts more than 50 nanoseconds per
> second with 10 MHz at the STOP jack --  its error will end up
> underrepresented in the measurement.  In this case your oscillator is
> drifting quite a bit (as expected) -- look at the 'w' view of the original
> phase compared to the unwrapped 'p' phase.  You could try putting 1pps on
> both the START and STOP jacks but that'll require more futzing with scale
> factors, 1pps dividers and the like, and may leave you more vulnerable to
> trigger uncertainty from various causes.  For measurement of a TCXO, I'd
> stick with frequency mode.  The ADEV plots won't be 100% kosher but they'll
> be fine for relative comparisons with other plots from the same measurement
> setup.
>
> -- john, KE5FX
> Miles Design LLC
>
>
> > -Original Message-
> > From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Dan
> > Watson
> > Sent: Tuesday, June 30, 2015 5:05 PM
> > To: Discussion of precise time and frequency measurement
> > Subject: Re: [time-nuts] Help with my ADEV measurement setup
> >
> > I tried both the PPS and the 10MHz signal on channel 1, with the 10MHz
> DUT
> > on channel 2. Tom emailed me and it turns out the software was not
> > detecting the units correctly from the serial string. (What are 6 powers
> of
> > ten between friends, right? :) ) Likely a settings mistake on my part, I
> > sent him a screen cap to see what's up.
> >
> > None the less, I manually enter the time units and was able to plot some
> > data. I attached a new screen cap. How does this look?
> >
> > Thanks
> >
> > Dan
> >
> > On Tue, Jun 30, 2015 at 5:36 PM, Bob Camp  wrote:
> >
> > > Hi
> > >
> > > Are you using a PPS as the “start” and the 10 MHz as the “stop” or
> > > comparing two PPS signals?
> > >
> > > Bob
> > >
> > > > On Jun 30, 2015, at 2:47 PM, Dan Watson 
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm trying to take some ADEV measurements with my 53131A, and I'm
> > having
> > > > some issues. This is my setup:
> > > >
> > > > - 53131A with the OCXO option. Calibrated against a T-bolt. I also
> did
> > > the
> > > > TI Quik cal and it passed
> > > > - I'm using RS-232 out with a null modem cable into a Serial-USB
> > > converter
> > > > - Software is TimeLab in talk-only mode. 53131A check box is checked.
> > > > - The counter is in TI mode, with a T-bolt on Channel 1 and DUT on
> > > Channel 2
> > > > - A delay of 1 second is set on the counter. TimeLab seems to
> accurately
> > > > detect this interval
> > > >
> > > 

Re: [time-nuts] Help with my ADEV measurement setup

[John Miles]

Yep, it will ignore any non-numeric data like "us" suffixes.  It will always 
interpret incoming data as seconds, so the 1E-6 scale factor is appropriate if 
the counter is returning microseconds.  I'll tweak the mouseover help text for 
the scale factor field to clarify that.  

I think you're basically getting valid data.  The 53131A's one-shot resolution 
is 0.5 ns, and you're seeing about 2E-9 residual ADEV at t=1s.  It's in the 
right ballpark, anyway... e.g., on a 20-ps HP 5370, the residual ADEV at t=1s 
will usually be in the neighborhood of 30-60 ps. 

I would, however, be worried about aliasing with a TCXO.  If its frequency is 
more than 5E-8 off -- meaning it drifts more than 50 nanoseconds per second 
with 10 MHz at the STOP jack --  its error will end up underrepresented in the 
measurement.  In this case your oscillator is drifting quite a bit (as 
expected) -- look at the 'w' view of the original phase compared to the 
unwrapped 'p' phase.  You could try putting 1pps on both the START and STOP 
jacks but that'll require more futzing with scale factors, 1pps dividers and 
the like, and may leave you more vulnerable to trigger uncertainty from various 
causes.  For measurement of a TCXO, I'd stick with frequency mode.  The ADEV 
plots won't be 100% kosher but they'll be fine for relative comparisons with 
other plots from the same measurement setup.

-- john, KE5FX
Miles Design LLC


> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Dan
> Watson
> Sent: Tuesday, June 30, 2015 5:05 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Help with my ADEV measurement setup
> 
> I tried both the PPS and the 10MHz signal on channel 1, with the 10MHz DUT
> on channel 2. Tom emailed me and it turns out the software was not
> detecting the units correctly from the serial string. (What are 6 powers of
> ten between friends, right? :) ) Likely a settings mistake on my part, I
> sent him a screen cap to see what's up.
> 
> None the less, I manually enter the time units and was able to plot some
> data. I attached a new screen cap. How does this look?
> 
> Thanks
> 
> Dan
> 
> On Tue, Jun 30, 2015 at 5:36 PM, Bob Camp  wrote:
> 
> > Hi
> >
> > Are you using a PPS as the “start” and the 10 MHz as the “stop” or
> > comparing two PPS signals?
> >
> > Bob
> >
> > > On Jun 30, 2015, at 2:47 PM, Dan Watson 
> wrote:
> > >
> > > Hi,
> > >
> > > I'm trying to take some ADEV measurements with my 53131A, and I'm
> having
> > > some issues. This is my setup:
> > >
> > > - 53131A with the OCXO option. Calibrated against a T-bolt. I also did
> > the
> > > TI Quik cal and it passed
> > > - I'm using RS-232 out with a null modem cable into a Serial-USB
> > converter
> > > - Software is TimeLab in talk-only mode. 53131A check box is checked.
> > > - The counter is in TI mode, with a T-bolt on Channel 1 and DUT on
> > Channel 2
> > > - A delay of 1 second is set on the counter. TimeLab seems to accurately
> > > detect this interval
> > >
> > > I started measuring various devices, and could never seem to get better
> > > than around 1x10^-6. Even my Rb was showing a 1 second ADEV of 10^-6.
> > > Finally I put the T-bolt on channel 1 with common mode on to both
> > channels,
> > > and it still measures around 10^-6. A picture of that is attached. Surely
> > > this can't be right.
> > >
> > > I tried frequency mode and it gives ADEVs of 10^-12 on the Rb and T-bolt,
> > > as expected. I understand the issues with filtering that the 53131A does
> > > internally on this mode, but at least it shows my setup is working to
> > some
> > > degree. It's TI mode that seems to be wonky.
> > >
> > > I'm probably doing something really stupid.
> > >
> > > Thanks for any help you all can suggest.
> > >
> > > Regards,
> > >
> > > Dan W
> > > ___
> > > 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.

Re: [time-nuts] Help with my ADEV measurement setup

[Bob Camp]

Hi

Your OCXO and the TBolt *should* be down around 1x10^-11 to 1x10^-12 at one 
second. 
That’s a factor of 10 to 100X better than the 53131 can do at a random 
frequency. At exactly
10 MHz it may be even worse than that. Effectively what you will be doing is 
measuring the 
noise floor of the counter out to a few hundred seconds. To get useful data, 
plan on runs of
at least several hours, if not a few days. 

Bob

> On Jun 30, 2015, at 8:05 PM, Dan Watson  wrote:
> 
> I tried both the PPS and the 10MHz signal on channel 1, with the 10MHz DUT
> on channel 2. Tom emailed me and it turns out the software was not
> detecting the units correctly from the serial string. (What are 6 powers of
> ten between friends, right? :) ) Likely a settings mistake on my part, I
> sent him a screen cap to see what's up.
> 
> None the less, I manually enter the time units and was able to plot some
> data. I attached a new screen cap. How does this look?
> 
> Thanks
> 
> Dan
> 
> On Tue, Jun 30, 2015 at 5:36 PM, Bob Camp  wrote:
> 
>> Hi
>> 
>> Are you using a PPS as the “start” and the 10 MHz as the “stop” or
>> comparing two PPS signals?
>> 
>> Bob
>> 
>>> On Jun 30, 2015, at 2:47 PM, Dan Watson  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm trying to take some ADEV measurements with my 53131A, and I'm having
>>> some issues. This is my setup:
>>> 
>>> - 53131A with the OCXO option. Calibrated against a T-bolt. I also did
>> the
>>> TI Quik cal and it passed
>>> - I'm using RS-232 out with a null modem cable into a Serial-USB
>> converter
>>> - Software is TimeLab in talk-only mode. 53131A check box is checked.
>>> - The counter is in TI mode, with a T-bolt on Channel 1 and DUT on
>> Channel 2
>>> - A delay of 1 second is set on the counter. TimeLab seems to accurately
>>> detect this interval
>>> 
>>> I started measuring various devices, and could never seem to get better
>>> than around 1x10^-6. Even my Rb was showing a 1 second ADEV of 10^-6.
>>> Finally I put the T-bolt on channel 1 with common mode on to both
>> channels,
>>> and it still measures around 10^-6. A picture of that is attached. Surely
>>> this can't be right.
>>> 
>>> I tried frequency mode and it gives ADEVs of 10^-12 on the Rb and T-bolt,
>>> as expected. I understand the issues with filtering that the 53131A does
>>> internally on this mode, but at least it shows my setup is working to
>> some
>>> degree. It's TI mode that seems to be wonky.
>>> 
>>> I'm probably doing something really stupid.
>>> 
>>> Thanks for any help you all can suggest.
>>> 
>>> Regards,
>>> 
>>> Dan W
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Help with my ADEV measurement setup

[Dan Watson]

Attached is a screenshot of the setup window. I manually typed in 1E-6 as
the units. I also hit Monitor and let it average the reporting interval for
a while until it settled at 1.00 seconds.

Originally I was leaving the time unit as 1, and microseconds in in the
serial string was not being detected to set the units automatically.

I'd be happy to send you a tim file as well if necessary. Let me know.

Thanks

Dan

On Tue, Jun 30, 2015 at 8:51 PM, John Miles  wrote:

> Let's see a snapshot of your acquisition dialog, just before you hit
> 'Start'.  (Or send me a .tim file directly.)  It can be tricky to configure
> the test setup for a TI measurement, since so many more things can go wrong
> compared to a frequency-based setup.
>
> -- john, KE5FX
> Miles Design LLC
>
> > -Original Message-
> > From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Dan
> > Watson
> > Sent: Tuesday, June 30, 2015 11:48 AM
> > To: time-nuts@febo.com
> > Subject: [time-nuts] Help with my ADEV measurement setup
> >
> > Hi,
> >
> > I'm trying to take some ADEV measurements with my 53131A, and I'm having
> > some issues. This is my setup...
>
> ___
> 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] Help with my ADEV measurement setup

[John Miles]

Let's see a snapshot of your acquisition dialog, just before you hit 'Start'.  
(Or send me a .tim file directly.)  It can be tricky to configure the test 
setup for a TI measurement, since so many more things can go wrong compared to 
a frequency-based setup.

-- john, KE5FX
Miles Design LLC

> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Dan
> Watson
> Sent: Tuesday, June 30, 2015 11:48 AM
> To: time-nuts@febo.com
> Subject: [time-nuts] Help with my ADEV measurement setup
> 
> Hi,
> 
> I'm trying to take some ADEV measurements with my 53131A, and I'm having
> some issues. This is my setup...

___
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] Help with my ADEV measurement setup

[Dan Watson]

I tried both the PPS and the 10MHz signal on channel 1, with the 10MHz DUT
on channel 2. Tom emailed me and it turns out the software was not
detecting the units correctly from the serial string. (What are 6 powers of
ten between friends, right? :) ) Likely a settings mistake on my part, I
sent him a screen cap to see what's up.

None the less, I manually enter the time units and was able to plot some
data. I attached a new screen cap. How does this look?

Thanks

Dan

On Tue, Jun 30, 2015 at 5:36 PM, Bob Camp  wrote:

> Hi
>
> Are you using a PPS as the “start” and the 10 MHz as the “stop” or
> comparing two PPS signals?
>
> Bob
>
> > On Jun 30, 2015, at 2:47 PM, Dan Watson  wrote:
> >
> > Hi,
> >
> > I'm trying to take some ADEV measurements with my 53131A, and I'm having
> > some issues. This is my setup:
> >
> > - 53131A with the OCXO option. Calibrated against a T-bolt. I also did
> the
> > TI Quik cal and it passed
> > - I'm using RS-232 out with a null modem cable into a Serial-USB
> converter
> > - Software is TimeLab in talk-only mode. 53131A check box is checked.
> > - The counter is in TI mode, with a T-bolt on Channel 1 and DUT on
> Channel 2
> > - A delay of 1 second is set on the counter. TimeLab seems to accurately
> > detect this interval
> >
> > I started measuring various devices, and could never seem to get better
> > than around 1x10^-6. Even my Rb was showing a 1 second ADEV of 10^-6.
> > Finally I put the T-bolt on channel 1 with common mode on to both
> channels,
> > and it still measures around 10^-6. A picture of that is attached. Surely
> > this can't be right.
> >
> > I tried frequency mode and it gives ADEVs of 10^-12 on the Rb and T-bolt,
> > as expected. I understand the issues with filtering that the 53131A does
> > internally on this mode, but at least it shows my setup is working to
> some
> > degree. It's TI mode that seems to be wonky.
> >
> > I'm probably doing something really stupid.
> >
> > Thanks for any help you all can suggest.
> >
> > Regards,
> >
> > Dan W
> > ___
> > 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.

Re: [time-nuts] Help with my ADEV measurement setup

[Bob Camp]

Hi

Are you using a PPS as the “start” and the 10 MHz as the “stop” or comparing 
two PPS signals?

Bob

> On Jun 30, 2015, at 2:47 PM, Dan Watson  wrote:
> 
> Hi,
> 
> I'm trying to take some ADEV measurements with my 53131A, and I'm having
> some issues. This is my setup:
> 
> - 53131A with the OCXO option. Calibrated against a T-bolt. I also did the
> TI Quik cal and it passed
> - I'm using RS-232 out with a null modem cable into a Serial-USB converter
> - Software is TimeLab in talk-only mode. 53131A check box is checked.
> - The counter is in TI mode, with a T-bolt on Channel 1 and DUT on Channel 2
> - A delay of 1 second is set on the counter. TimeLab seems to accurately
> detect this interval
> 
> I started measuring various devices, and could never seem to get better
> than around 1x10^-6. Even my Rb was showing a 1 second ADEV of 10^-6.
> Finally I put the T-bolt on channel 1 with common mode on to both channels,
> and it still measures around 10^-6. A picture of that is attached. Surely
> this can't be right.
> 
> I tried frequency mode and it gives ADEVs of 10^-12 on the Rb and T-bolt,
> as expected. I understand the issues with filtering that the 53131A does
> internally on this mode, but at least it shows my setup is working to some
> degree. It's TI mode that seems to be wonky.
> 
> I'm probably doing something really stupid.
> 
> Thanks for any help you all can suggest.
> 
> Regards,
> 
> Dan W
> ___
> 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] Help me make some sense of adev measurements of SR620'sown clock

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 25 Jan 2015 23:02, "Tom Van Baak"  wrote:

> You're getting 1e-12 at 1 second. Sounds fine to me.

Obviously you have the experience to know that 1e-12 at 1 second is fine.

But if it's possible,  I would like to understand the relationship between
the counters specification and the adev (or one of the modifications of it)
one would expect to see.

Obviously it is nice to know that the counter is working ok, but I would
like to understand how one can ascertain that from the data I recorded,
based on the SR620's specifications.

> Also, when you plot phase with TimeLab you'll notice a jump around
T+23600 seconds. This is likely you breathing near the instrument, or
touching a cable, or closing a door.

That's interesting.  It is about 4:30 am local time here, so when I was
asleep. I would have expected data then to be better than during the day
when I move around. The biggest disturbance occurred at a time I would have
least expected it.

> > Do most people save time information as I have done there, or phase
> > information?

> Always save phase. Not sure what you mean by time.
The counter can measure the time between the start and stop inputs, which
is what I done. The numbers are around 17.5 ns due to the cable length.

But instead of saving those time values, I could have configured the
counter to save the phase in the range -180 to +180 degrees. Your adev1
programe expected time in seconds rather than phase in degrees, which is
why I saved time rather than phase.  But I will use adev5 as you
suggested.  I used adev1 primarily since you had a web page on it.

I am not talking about elapsed time, time of the day etc. That's something
quite different.

> Even better is to save both phase and elapsed time or real time; the
latter can be used as a check that your sample rates are what you expect.

I did save elapsed time as you can see. I was in fact a bit surprised that
the data points are spaced very slightly *less* than a second apart. I
would have expected the data to take 1 second to collect, then some time
processing time, especially since I introduced a delay of about 200 us to
stop the GPIB reads randomly failing.   That's a bit of a mystery.

> Personally, I prefix every ascii line received with a MJD timestamp. That
way all my log files, everything from counters to temperature sensors to
GPS NMEA lines can all be correlated against themselves and with other
people.

I had never heard of the MJD, but I will do what you suggest.

> > Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year
format)
>
> Always use leading zeros for hours, minutes, and seconds.

That was not intensional. I would have intended to put the leading zero.

> The preferred way to write this is simply 2015-01-24 23:02:55 (see ISO
8601).

OK, I'll do that, despite it seems quite unnatural to us brits!

John's software looks impressive. In fact is TimePod hardware too, but far
out of my budget. I will have to make do with the SR620.

I just wish I didn't have to load the data into a Windows program. Maybe at
some point I will try to get gnuplot to do similar.

> /tvb

Thank you Tom. Also to Bob. I will do as Bob suggested and repeat using an
external 10 MHz source, rather than use the counters own timebase.

Dave
___
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] Help me make some sense of adev measurements of SR620'sown clock

[Magnus Danielson]

David,

Looking at the ADEV plot, I see the ripple that I expect from some 
oscillatory property.


Looking at the phase, I see some of it, and picking it up in fityk (to 
view the phase info) I see a sawtooth like pattern, seeing typ around 4 
cycles in 2000 s or so, which is typical of heating/AC type of 
behaviour. Hence, I may be looking at a temp-sensor.


Shielding from temperature-variations can be tricky, as the SR620 
produces a lot of heat. Putting thermal mass all around it 
(waterbottles) might be a fun experiment, but for most part, I think the 
performance you get is good and you should not be bothered with it.


The ADEV measure you got that was higher had only one degree of freedom, 
so the confidence interval was very wide, so you should just ignore 
that. You should look at the oadev list instead.


Cheers,
Magnus

On 01/25/2015 11:21 PM, Tom Van Baak wrote:

http://www.kirkbymicrowave.co.uk/time-stuff/ref-out-to-A-3.6m-cable-to-B-rev4.zip

The format should be pretty self-explanatory. Note the counter sample


Well done, nicely self-documenting.


I then used Tom's "adev1"

http://www.leapsecond.com/tools/adev1.htm
http://www.leapsecond.com/tools/adev1.c

to analyze the data.


That will work, but adev5 is a more recent version that I now use instead.

C:\tmp>skip 17 < ref-out-to-A-3.6m-cable-to-B.txt | fld 1 | adev5 /a 0 10 .5
** log(tau) from 0 to 10 step 0.5, that is, tau from 1 to 1e+010 with 2 
steps/decade
   0.   1 a -11.997131 1.006628e-012 56163
   0.5000   3 a -12.432202 3.696563e-013 56159
   1.  10 a -12.818504 1.518784e-013 56145
   1.5000  32 a -13.123597 7.523206e-014 56101
   2. 100 a -13.370151 4.264311e-014 55965
   2.5000 316 a -13.787569 1.630914e-014 55533
   3.1000 a -14.280998 5.236028e-015 54165
   3.50003162 a -14.694447 2.020940e-015 49841
   4.   1 a -15.061822 8.673176e-016 36165

Better yet, use John's TimeLab, import with 'L' and see nice phase, frequency, 
adev, tdev plots within seconds. Here are the plots you will get:
http://leapsecond.com/tmp/dave1-phase.gif
http://leapsecond.com/tmp/dave1-freq.gif
http://leapsecond.com/tmp/dave1-adev.gif
http://leapsecond.com/tmp/dave1-tdev.gif
http://leapsecond.com/tmp/dave1-tdev10.gif


I'm puzzled about, is how to interpret this, and if interpretation is
correct, my counter might not be in spec.


Your interpretation is correct. You can also get TDEV numbers using adev5 /t


The SR620 counter's display has resolution of 1 ps, and supposedly a
25 ps rms single short resolution. Would I be right in assuming that
after 1 second (1000 samples), I would expect to see an adev of
25e-12/sqrt(1000) = 8e-13, suggesting my counter is not achieving the
25 ps rms resolution, but rather sqrt(1000)*1.0066e-12=31.8 ps?


You're getting 1e-12 at 1 second. Sounds fine to me. Don't sweat the 10 vs 9 vs 
8e-13 thing; the counter is working fine. The TDEV gets down to 4e-13 at 4 
seconds if you want nice numbers. You're partly limited by 1 ps LSDigit 
quantization as well.


Also, why would the adev rise at 2 tau, when this is only
measuring the time between its own reference, and a version delayed by
about 17.5 ns due to a few metres of cable? But maybe there's not
really enough data at 2 seconds.


There are many things hidden inside the word "measuring itself". Internal and 
external enviromental effects will start to play a role in this time frame.

Also, when you plot phase with TimeLab you'll notice a jump around T+23600 
seconds. This is likely you breathing near the instrument, or touching a cable, 
or closing a door. We're talking ps here, so you can't even look at it while 
it's running.


Do most people save time information as I have done there, or phase
information? I'm guessing the two are easily related, but I'm
wondering what will work with most peoples software. What I like about
Tom's is it compiles easily on my Unix box, without me having to use
Windows. But I note some of Tom's software wants phase, and the other
time.


Always save phase. Not sure what you mean by time. Even better is to save both 
phase and elapsed time or real time; the latter can be used as a check that 
your sample rates are what you expect.

Personally, I prefix every ascii line received with a MJD timestamp. That way 
all my log files, everything from counters to temperature sensors to GPS NMEA 
lines can all be correlated against themselves and with other people.


Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year format)


Always use leading zeros for hours, minutes, and seconds. The preferred way to 
write this is simply 2015-01-24 23:02:55 (see ISO 8601).

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


___
time-nuts mailing list -- time-nuts@febo.co

Re: [time-nuts] Help me make some sense of adev measurements of SR620'sown clock

[Tom Van Baak]

> http://www.kirkbymicrowave.co.uk/time-stuff/ref-out-to-A-3.6m-cable-to-B-rev4.zip
> 
> The format should be pretty self-explanatory. Note the counter sample

Well done, nicely self-documenting.

> I then used Tom's "adev1"
> 
> http://www.leapsecond.com/tools/adev1.htm
> http://www.leapsecond.com/tools/adev1.c
> 
> to analyze the data.

That will work, but adev5 is a more recent version that I now use instead.

C:\tmp>skip 17 < ref-out-to-A-3.6m-cable-to-B.txt | fld 1 | adev5 /a 0 10 .5
** log(tau) from 0 to 10 step 0.5, that is, tau from 1 to 1e+010 with 2 
steps/decade
  0.   1 a -11.997131 1.006628e-012 56163
  0.5000   3 a -12.432202 3.696563e-013 56159
  1.  10 a -12.818504 1.518784e-013 56145
  1.5000  32 a -13.123597 7.523206e-014 56101
  2. 100 a -13.370151 4.264311e-014 55965
  2.5000 316 a -13.787569 1.630914e-014 55533
  3.1000 a -14.280998 5.236028e-015 54165
  3.50003162 a -14.694447 2.020940e-015 49841
  4.   1 a -15.061822 8.673176e-016 36165

Better yet, use John's TimeLab, import with 'L' and see nice phase, frequency, 
adev, tdev plots within seconds. Here are the plots you will get:
http://leapsecond.com/tmp/dave1-phase.gif
http://leapsecond.com/tmp/dave1-freq.gif
http://leapsecond.com/tmp/dave1-adev.gif
http://leapsecond.com/tmp/dave1-tdev.gif
http://leapsecond.com/tmp/dave1-tdev10.gif

> I'm puzzled about, is how to interpret this, and if interpretation is
> correct, my counter might not be in spec.

Your interpretation is correct. You can also get TDEV numbers using adev5 /t

> The SR620 counter's display has resolution of 1 ps, and supposedly a
> 25 ps rms single short resolution. Would I be right in assuming that
> after 1 second (1000 samples), I would expect to see an adev of
> 25e-12/sqrt(1000) = 8e-13, suggesting my counter is not achieving the
> 25 ps rms resolution, but rather sqrt(1000)*1.0066e-12=31.8 ps?

You're getting 1e-12 at 1 second. Sounds fine to me. Don't sweat the 10 vs 9 vs 
8e-13 thing; the counter is working fine. The TDEV gets down to 4e-13 at 4 
seconds if you want nice numbers. You're partly limited by 1 ps LSDigit 
quantization as well.

> Also, why would the adev rise at 2 tau, when this is only
> measuring the time between its own reference, and a version delayed by
> about 17.5 ns due to a few metres of cable? But maybe there's not
> really enough data at 2 seconds.

There are many things hidden inside the word "measuring itself". Internal and 
external enviromental effects will start to play a role in this time frame.

Also, when you plot phase with TimeLab you'll notice a jump around T+23600 
seconds. This is likely you breathing near the instrument, or touching a cable, 
or closing a door. We're talking ps here, so you can't even look at it while 
it's running.

> Do most people save time information as I have done there, or phase
> information? I'm guessing the two are easily related, but I'm
> wondering what will work with most peoples software. What I like about
> Tom's is it compiles easily on my Unix box, without me having to use
> Windows. But I note some of Tom's software wants phase, and the other
> time.

Always save phase. Not sure what you mean by time. Even better is to save both 
phase and elapsed time or real time; the latter can be used as a check that 
your sample rates are what you expect.

Personally, I prefix every ascii line received with a MJD timestamp. That way 
all my log files, everything from counters to temperature sensors to GPS NMEA 
lines can all be correlated against themselves and with other people.

> Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year format)

Always use leading zeros for hours, minutes, and seconds. The preferred way to 
write this is simply 2015-01-24 23:02:55 (see ISO 8601).

/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] Help me make some sense of adev measurements of SR620's own clock

[Bob Camp]

HI

If you want to check your counter, simply look at the standard deviation of the 
readings you are getting. When I put them in to Excel here, they come up at 
6.944 ps. That’s well within the counter’s specs. It’s not at all uncommon with 
the SR620 to get “to good to be true” readings using the internal standard. The 
reason is that the noise on the standard cancels out to some degree when you 
use it as your test source. To get a more realistic number, feed it with a 10 
MHz source that is not the same as it’s internal reference. 

Bob

> On Jan 25, 2015, at 10:43 AM, Dr. David Kirkby (Kirkby Microwave Ltd) 
>  wrote:
> 
> After sorting out some GPIB issues, I finally got to be able to make
> some measurements on my Stanford Research SR620 time-interval counter.
> I thought it sensible to first try to determine the performance of the
> counter, which is using its own high stability clock (option 001). So
> no external reference, such as one derived from GPS, is used.
> 
> I took the 10 MHz reference output from the SR620 via a cable about
> 0.5 m to the A input of the counter, which also had a BNC T on the
> counter. From the A input to the B input is a cable about 3.6 m long
> (longer than I would have liked with hindsight). I then measured the
> time-interval every second for 55488 seconds - it is actually still
> collecting data. The data file is here.
> 
> http://www.kirkbymicrowave.co.uk/time-stuff/ref-out-to-A-3.6m-cable-to-B-rev4.zip
> 
> The format should be pretty self-explanatory. Note the counter sample
> size is 1000, so it takes 1 sec. Note A is an high impedance input,
> and B 50 Ohms, which seems a logical choice if tapping off a bit from
> a 50 Ohm cable for the A input.
> 
> # Data collected with ./tic version 0.01
> # GPIB address 17 on host 'buzzard'
> # Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year 
> format)
> # Instrument settings are as follows:
> # Sample size: 1E3
> # Trigger level (external): -0.21 V
> # Trigger level (A): -0.01 V
> # Trigger level (B): -0.01 V
> # Coupling (A): AC
> # Coupling (B): AC
> # Termination (external): 100 Ohm
> # Termination (A): 100 Ohm
> # Termination (B): 50 Ohm
> # Mode = Time
> # Column 1 is the time from the SR620 in seconds
> # Column 2 is a hash(#) character, used to denote a comment
> # Column 3 is the delay in seconds since data was first collected
> 1.7540E-8 # 0.00 s
> 1.7538E-8 # 0.988158 s
> 1.7538E-8 # 1.976571 s
> 1.7538E-8 # 2.964327 s
> 
> The times recorded, about 17.5 ns, are consistent with what one would
> expect with a cable about the length I have.
> 
> I then used Tom's "adev1"
> 
> http://www.leapsecond.com/tools/adev1.htm
> http://www.leapsecond.com/tools/adev1.c
> 
> to analyze the data.
> 
> drkirkby@buzzard:/tmp$ adev1 1 < ref-out-to-A-3.6m-cable-to-B.txt
> 
> ** Sampling period: 1 s
> ** Phase data scale factor: 1.000e+00
> ** Total phase samples: 56165
> ** Normal and Overlapping Allan deviation:
> 
>   1 tau, 1.0066e-12 adev(n=56163), 1.0066e-12 oadev(n=56163)
>   2 tau, 5.2611e-13 adev(n=28081), 5.2820e-13 oadev(n=56161)
>   5 tau, 2.4461e-13 adev(n=11231), 2.4397e-13 oadev(n=56155)
>  10 tau, 1.5235e-13 adev(n=5615),  1.5188e-13 oadev(n=56145)
>  20 tau, 9.8477e-14 adev(n=2807),  9.9323e-14 oadev(n=56125)
>  50 tau, 5.7764e-14 adev(n=1122),  5.9520e-14 oadev(n=56065)
> 100 tau, 4.1609e-14 adev(n=560),   4.2643e-14 oadev(n=55965)
> 200 tau, 2.7712e-14 adev(n=279),   2.8362e-14 oadev(n=55765)
> 500 tau, 8.1848e-15 adev(n=111),   9.3519e-15 oadev(n=55165)
>1000 tau, 4.9553e-15 adev(n=55),5.2360e-15 oadev(n=54165)
>2000 tau, 3.3500e-15 adev(n=27),3.0661e-15 oadev(n=52165)
>5000 tau, 1.8873e-15 adev(n=10),1.4325e-15 oadev(n=46165)
>   1 tau, 8.6819e-16 adev(n=4), 8.6732e-16 oadev(n=36165)
>   2 tau, 1.4849e-15 adev(n=1), 6.3165e-16 oadev(n=16165)
> 
> I'm puzzled about, is how to interpret this, and if interpretation is
> correct, my counter might not be in spec.
> 
> I thought from reading Wikipedia and
> 
> en.wikipedia.org/wiki/Allan_variance
> 
> that at 1 tau, the Allen Deviation represents the RMS deviation
> between two observations 1 second apart.  So that is 1.0066 ps.
> 
> The SR620 counter's display has resolution of 1 ps, and supposedly a
> 25 ps rms single short resolution. Would I be right in assuming that
> after 1 second (1000 samples), I would expect to see an adev of
> 25e-12/sqrt(1000) = 8e-13, suggesting my counter is not achieving the
> 25 ps rms resolution, but rather sqrt(1000)*1.0066e-12=31.8 ps? I've
> run Autocal on this counter, and put the oscillator on frequency with
> one of the calbytes, but have not done any other adjustments. Needless
> to say its an eBay purchase, and I doubt has been near a cal lab in
> years.
> 
> Again based on a 25 ps rms resolution, would I expect after 500
> seconds (50,000 counts), to see an adev

Re: [time-nuts] Help identifying a display board

[ed breya]

It could be a combined time display with a channel number and 
measured value, from some kind of data logging instrument. L&N was 
big in thermocouple measurements and the like. With those digits you 
could show temperature at three digits resolution, selected channel 
00-99, and hours and minutes, with the LED for AM/PM.


Or NOT.

One clue would be to see if they used any of the Panaplex decimal 
points. None would be needed on time or channel readouts. If only the 
second DP of the three-digit one is connected, then it could be set 
to 1 or 0.1 degree resolution. If no DPs at all are used, then the 
temperature could show 1 degree resolution, and display -99 to 999 
deg F or C, which is a pretty decent range for common T/Cs, depending 
on the application. It could even work for cryogenics, reading say 
000-999 deg K.


The board also appears to be missing one DM8880.

Ed

___
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] Help identifying a display board

[Robert LaJeunesse]

Sure looks like Leeds & Northrup to me.

http://www.ebay.com/itm/Leeds-and-Northrup-Light-Beam-Galvanometer-2430-C-/281460565063?pt=LH_DefaultDomain_0&hash=item41885b6447

Bob L.

> Sent: Wednesday, October 08, 2014 at 2:41 PM
> From: "Dan Veeneman" 
> To: time-nuts@febo.com
> Subject: [time-nuts] Help identifying a display board
>
> Over the weekend I picked up a display board that appears to have come
> from a clock or time code device.  It has four Panaplex display modules
> and a single LED.  The board is silkscreened with a "LN" logo and
> appears to be circa 1974 (if what looks like a date code is actually a
> date code).
> 
> I have pictures up at
> .  Does
> anyone recognize the logo and/or the device this board might have come from?
> 
> 
> Thanks,
> Dan
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Help understanding an ADEV

[Hal Murray]

b...@evoria.net said:
> "Note: The DAC module is designed specifically for audio applications and is
> not recommended for control type applications."

> I had hoped that it wouldn't be a problem for driving an OCXO, but my
> mistake.  The datasheet also notes that the DAC has 16-bit resolution but
> only 14-bit accuracy.  It didn't seem to have even that at DC.  The PWM
> version doesn't have any escape clauses.  You set "x" parameters and it's
> supposed to be 16-bits wide.  Maybe "audio" means within the human auditory
> passband? 

In the old days, the specs for DACs and ADCs were easy to understand, at 
least after you figured things out, and all the major vendors had app-notes 
explaining what the parameters meant.  There was INL, DNL and a few buzzwords 
like no-missing-codes and monotonic.

Ballpark of 20 years ago, things got much more complicated.  A new generation 
of chips came out targeted at DSP applications.  FFT plots started appearing 
in data sheets.  Parameters like ENOB (effective number of bits) became the 
important ones.

On top of that, if you are interested in audio or radar, temperature 
stability is not an important parameter.



-- 
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] Help understanding an ADEV

[Bob Stewart]

Hi David,


It's an odd situation.  From the datasheet:

"Note: The DAC module is designed specifically for audio applications and is 
not recommended for control type applications."

I had hoped that it wouldn't be a problem for driving an OCXO, but my mistake.  
The datasheet also notes that the DAC has 16-bit resolution but only 14-bit 
accuracy.  It didn't seem to have even that at DC.  The PWM version doesn't 
have any escape clauses.  You set "x" parameters and it's supposed to be 
16-bits wide.  Maybe "audio" means within the human auditory passband?


Bob




 From: Dr. David Kirkby (Kirkby Microwave Ltd) 
To: Bob Stewart ; Discussion of precise time and frequency 
measurement  
Sent: Saturday, September 13, 2014 4:27 PM
Subject: Re: [time-nuts] Help understanding an ADEV
 





On 11 Sep 2014 04:35, "Bob Stewart"  wrote:
> I've ordered the PWM version of the PIC, and hopefully, since it's the motor 
> control version (as opposed to the audio version) it will have much better 
> noise performance.
I don't know the PIC but I would have thought chips for audio would be 
optimised for low noise far less than one for driving motors.
Dr David Kirkby
Managing Director
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Chelmsford, Essex, CM3 6DT, 
United Kingdom
Registered in England and Wales as company number 08914892
http://www.kirkbymicrowave.co.uk/
Tel 07910 441670 / +44 7910 441670 (0900-2100 GMT)
___
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] Help understanding an ADEV

[Dr. David Kirkby (Kirkby Microwave Ltd)]

OOPS! CORRECTION.

I don't know the PIC but I would have thought chips for audio would be
optimised for low noise far MOOR than one for driving motors.

Ears are more sensitive to a bit of noise than motors.

I assume I have misunderstood you.

Dave
___
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] Help understanding an ADEV

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 11 Sep 2014 04:35, "Bob Stewart"  wrote:

> I've ordered the PWM version of the PIC, and hopefully, since it's the
motor control version (as opposed to the audio version) it will have much
better noise performance.

I don't know the PIC but I would have thought chips for audio would be
optimised for low noise far less than one for driving motors.

Dr David Kirkby
Managing Director
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Chelmsford, Essex, CM3
6DT, United Kingdom
Registered in England and Wales as company number 08914892
http://www.kirkbymicrowave.co.uk/
Tel 07910 441670 / +44 7910 441670 (0900-2100 GMT)
___
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] Help understanding an ADEV

[Bob Stewart]

Hi Andrew,

Yeah, it was a pretty dumb mistake, but I think I learned my lesson.  At the 
very least, my scripts now allow me to skip as many initial samples as I like 
before the data is plotted.

And, the PWM version of the chip is in.  It's orders of magnitude more stable 
than the audio DAC in the one I've been posting about.  So, I'm doing testing 
and tuning, and will be back with still more questions.  But, I'm finally 
starting to get reasonable results.


Bob - AE6RV



 From: Andrew Rodland 
To: Bob Stewart ; Discussion of precise time and frequency 
measurement  
Cc: Tom Van Baak  
Sent: Friday, September 12, 2014 4:29 PM
Subject: Re: [time-nuts] Help understanding an ADEV
 

Your intuition isn't completely wrong -- the law of averages still
applies. As you provide more and more good data it will eventually
overwhelm the initial bad data, and the result will get closer to
correct.

But it will take a *lot* of data to overwhelm even a few data points
that have a deviation a hundred thousand times as large as the
deviation you're trying to measure. You would probably have to run for
months before you could trust the plot out to tau = 1s. Removing
the bad data is a superior alternative, if you ask me :)

Andrew




On Thu, Sep 11, 2014 at 5:21 PM, Bob Stewart  wrote:
> Hi Tom,
>
> And thank you very much for taking the time to look at this.  No, I don't 
> know what the heck a lot of this means, and it's no surprise that I used the 
> wrong tool.  I had noticed the first few seconds of bad data, but didn't 
> think it would matter over long sample sessions.
>
> I'll take some time to get this together properly and see what I can find 
> out.  The new PIC arrives tomorrow, so I'll know pretty quickly if there is a 
> big improvement in the noise.
>
> Thank you again, and everyone else who has taken even a moment of time to 
> help me during this project!
>
>
> Bob
>
>
>
> 
>  From: Tom Van Baak 
> To: Discussion of precise time and frequency measurement 
> Sent: Thursday, September 11, 2014 3:53 PM
> Subject: Re: [time-nuts] Help understanding an ADEV
>
>
>> I've been wondering if it would be better to look in the frequency domain.
>> I'll have to look at Tom's site to see if he has code to do that.
>> Bob
>
> Hi Bob,
>
> Ok, I think I found the problem with your plot. There's one mistake, one 
> misunderstanding, and a miscalibration.
>
>
> 1) It appears you're allowing bogus DAC readings to pollute the ADEV 
> calculation. Based on the raw data you kindly sent, your nominal DAC value is 
> about 2.1 volts and your DAC voltage typically changes by tens or low 
> hundreds of microvolts.
>
> However the first couple of data points are 0.0 and 1.0 volts. The ADEV 
> calculation is therefore seeing changes of millions (!) of microvolts. This 
> completely messes up every ADEV calculation at every tau of your plot. You 
> must feed clean data into any ADEV calculation. Either fix your 
> instrumentation, or put checks in your scripts, or visually examine time 
> series data before you blindly feed it into a statistical formula or a tool.
>
> I don't know why the plotting package you used does not show these points. 
> Those four bogus points should have been an instant red flag.
>
>
> 2) Realize that we normally make ADEV plots only from phase data or from 
> frequency data. Phase data is the net time difference (or time interval) 
> between the DUT and the REF. Units are seconds. Frequency data is the 
> (normalized) relative frequency difference between the DUT and the REF. This 
> is unitless.
>
> Now in your case, you want to make an ADEV plot from DAC data. This is ok, 
> since DAC voltage is essentially a proxy for frequency offset. But you can't 
> feed DAC or frequency data into the adev1 tool, since that tool expects phase 
> data only. Make sense?
>
> The details are that ADEV is based on the 2nd difference in phase, which is 
> the 1st difference in frequency. You have accidentally feed frequency data 
> into a phase calculation and the result is some sort of 3rd difference! This 
> is not what you want.
>
> The solution is either to integrate your DAC or frequency data so it looks 
> like phase. Or, just use a tool that will take frequency data instead of 
> phase data. Stable32 and TimeLab offer this option. Or you can use adev1f.exe 
> (www.leapsecond.com/tools/) which I just made for you.
>
>
> 3) To get an accurate ADEV plot you must scale your arbitrary DAC voltage to 
> real Hz. Use the known or measured EFC offset and gain to convert absolute 
> voltage to relative voltage to relati

Re: [time-nuts] Help understanding an ADEV

[Andrew Rodland]

Your intuition isn't completely wrong -- the law of averages still
applies. As you provide more and more good data it will eventually
overwhelm the initial bad data, and the result will get closer to
correct.

But it will take a *lot* of data to overwhelm even a few data points
that have a deviation a hundred thousand times as large as the
deviation you're trying to measure. You would probably have to run for
months before you could trust the plot out to tau = 1s. Removing
the bad data is a superior alternative, if you ask me :)

Andrew

On Thu, Sep 11, 2014 at 5:21 PM, Bob Stewart  wrote:
> Hi Tom,
>
> And thank you very much for taking the time to look at this.  No, I don't 
> know what the heck a lot of this means, and it's no surprise that I used the 
> wrong tool.  I had noticed the first few seconds of bad data, but didn't 
> think it would matter over long sample sessions.
>
> I'll take some time to get this together properly and see what I can find 
> out.  The new PIC arrives tomorrow, so I'll know pretty quickly if there is a 
> big improvement in the noise.
>
> Thank you again, and everyone else who has taken even a moment of time to 
> help me during this project!
>
>
> Bob
>
>
>
> 
>  From: Tom Van Baak 
> To: Discussion of precise time and frequency measurement 
> Sent: Thursday, September 11, 2014 3:53 PM
> Subject: Re: [time-nuts] Help understanding an ADEV
>
>
>> I've been wondering if it would be better to look in the frequency domain.
>> I'll have to look at Tom's site to see if he has code to do that.
>> Bob
>
> Hi Bob,
>
> Ok, I think I found the problem with your plot. There's one mistake, one 
> misunderstanding, and a miscalibration.
>
>
> 1) It appears you're allowing bogus DAC readings to pollute the ADEV 
> calculation. Based on the raw data you kindly sent, your nominal DAC value is 
> about 2.1 volts and your DAC voltage typically changes by tens or low 
> hundreds of microvolts.
>
> However the first couple of data points are 0.0 and 1.0 volts. The ADEV 
> calculation is therefore seeing changes of millions (!) of microvolts. This 
> completely messes up every ADEV calculation at every tau of your plot. You 
> must feed clean data into any ADEV calculation. Either fix your 
> instrumentation, or put checks in your scripts, or visually examine time 
> series data before you blindly feed it into a statistical formula or a tool.
>
> I don't know why the plotting package you used does not show these points. 
> Those four bogus points should have been an instant red flag.
>
>
> 2) Realize that we normally make ADEV plots only from phase data or from 
> frequency data. Phase data is the net time difference (or time interval) 
> between the DUT and the REF. Units are seconds. Frequency data is the 
> (normalized) relative frequency difference between the DUT and the REF. This 
> is unitless.
>
> Now in your case, you want to make an ADEV plot from DAC data. This is ok, 
> since DAC voltage is essentially a proxy for frequency offset. But you can't 
> feed DAC or frequency data into the adev1 tool, since that tool expects phase 
> data only. Make sense?
>
> The details are that ADEV is based on the 2nd difference in phase, which is 
> the 1st difference in frequency. You have accidentally feed frequency data 
> into a phase calculation and the result is some sort of 3rd difference! This 
> is not what you want.
>
> The solution is either to integrate your DAC or frequency data so it looks 
> like phase. Or, just use a tool that will take frequency data instead of 
> phase data. Stable32 and TimeLab offer this option. Or you can use adev1f.exe 
> (www.leapsecond.com/tools/) which I just made for you.
>
>
> 3) To get an accurate ADEV plot you must scale your arbitrary DAC voltage to 
> real Hz. Use the known or measured EFC offset and gain to convert absolute 
> voltage to relative voltage to relative frequency error. This data can then 
> be given to Stable32 (Data Type: Freq), or TimeLab (File data: Frequency 
> difference), or feed directly to the new tool, adev1f.
>
> Let me know if you have any questions.
>
> /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.
> ___
> 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] Help understanding an ADEV

[Bob Stewart]

Hi Tom,

And thank you very much for taking the time to look at this.  No, I don't know 
what the heck a lot of this means, and it's no surprise that I used the wrong 
tool.  I had noticed the first few seconds of bad data, but didn't think it 
would matter over long sample sessions.  

I'll take some time to get this together properly and see what I can find out.  
The new PIC arrives tomorrow, so I'll know pretty quickly if there is a big 
improvement in the noise.

Thank you again, and everyone else who has taken even a moment of time to help 
me during this project!


Bob




 From: Tom Van Baak 
To: Discussion of precise time and frequency measurement  
Sent: Thursday, September 11, 2014 3:53 PM
Subject: Re: [time-nuts] Help understanding an ADEV
 

> I've been wondering if it would be better to look in the frequency domain.  
> I'll have to look at Tom's site to see if he has code to do that.
> Bob

Hi Bob,

Ok, I think I found the problem with your plot. There's one mistake, one 
misunderstanding, and a miscalibration.


1) It appears you're allowing bogus DAC readings to pollute the ADEV 
calculation. Based on the raw data you kindly sent, your nominal DAC value is 
about 2.1 volts and your DAC voltage typically changes by tens or low hundreds 
of microvolts.

However the first couple of data points are 0.0 and 1.0 volts. The ADEV 
calculation is therefore seeing changes of millions (!) of microvolts. This 
completely messes up every ADEV calculation at every tau of your plot. You must 
feed clean data into any ADEV calculation. Either fix your instrumentation, or 
put checks in your scripts, or visually examine time series data before you 
blindly feed it into a statistical formula or a tool.

I don't know why the plotting package you used does not show these points. 
Those four bogus points should have been an instant red flag.


2) Realize that we normally make ADEV plots only from phase data or from 
frequency data. Phase data is the net time difference (or time interval) 
between the DUT and the REF. Units are seconds. Frequency data is the 
(normalized) relative frequency difference between the DUT and the REF. This is 
unitless.

Now in your case, you want to make an ADEV plot from DAC data. This is ok, 
since DAC voltage is essentially a proxy for frequency offset. But you can't 
feed DAC or frequency data into the adev1 tool, since that tool expects phase 
data only. Make sense?

The details are that ADEV is based on the 2nd difference in phase, which is the 
1st difference in frequency. You have accidentally feed frequency data into a 
phase calculation and the result is some sort of 3rd difference! This is not 
what you want.

The solution is either to integrate your DAC or frequency data so it looks like 
phase. Or, just use a tool that will take frequency data instead of phase data. 
Stable32 and TimeLab offer this option. Or you can use adev1f.exe 
(www.leapsecond.com/tools/) which I just made for you.


3) To get an accurate ADEV plot you must scale your arbitrary DAC voltage to 
real Hz. Use the known or measured EFC offset and gain to convert absolute 
voltage to relative voltage to relative frequency error. This data can then be 
given to Stable32 (Data Type: Freq), or TimeLab (File data: Frequency 
difference), or feed directly to the new tool, adev1f.

Let me know if you have any questions.

/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.
___
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] Help understanding an ADEV

[Tom Van Baak]

> I've been wondering if it would be better to look in the frequency domain.  
> I'll have to look at Tom's site to see if he has code to do that.
> Bob

Hi Bob,

Ok, I think I found the problem with your plot. There's one mistake, one 
misunderstanding, and a miscalibration.


1) It appears you're allowing bogus DAC readings to pollute the ADEV 
calculation. Based on the raw data you kindly sent, your nominal DAC value is 
about 2.1 volts and your DAC voltage typically changes by tens or low hundreds 
of microvolts.

However the first couple of data points are 0.0 and 1.0 volts. The ADEV 
calculation is therefore seeing changes of millions (!) of microvolts. This 
completely messes up every ADEV calculation at every tau of your plot. You must 
feed clean data into any ADEV calculation. Either fix your instrumentation, or 
put checks in your scripts, or visually examine time series data before you 
blindly feed it into a statistical formula or a tool.

I don't know why the plotting package you used does not show these points. 
Those four bogus points should have been an instant red flag.


2) Realize that we normally make ADEV plots only from phase data or from 
frequency data. Phase data is the net time difference (or time interval) 
between the DUT and the REF. Units are seconds. Frequency data is the 
(normalized) relative frequency difference between the DUT and the REF. This is 
unitless.

Now in your case, you want to make an ADEV plot from DAC data. This is ok, 
since DAC voltage is essentially a proxy for frequency offset. But you can't 
feed DAC or frequency data into the adev1 tool, since that tool expects phase 
data only. Make sense?

The details are that ADEV is based on the 2nd difference in phase, which is the 
1st difference in frequency. You have accidentally feed frequency data into a 
phase calculation and the result is some sort of 3rd difference! This is not 
what you want.

The solution is either to integrate your DAC or frequency data so it looks like 
phase. Or, just use a tool that will take frequency data instead of phase data. 
Stable32 and TimeLab offer this option. Or you can use adev1f.exe 
(www.leapsecond.com/tools/) which I just made for you.


3) To get an accurate ADEV plot you must scale your arbitrary DAC voltage to 
real Hz. Use the known or measured EFC offset and gain to convert absolute 
voltage to relative voltage to relative frequency error. This data can then be 
given to Stable32 (Data Type: Freq), or TimeLab (File data: Frequency 
difference), or feed directly to the new tool, adev1f.

Let me know if you have any questions.

/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] Help understanding an ADEV

[Bob Stewart]

Here are a couple of reference plots.  The only thing really important is the 
voltage trace in red.  It's in 10s of microvolts.

The first one is just measuring the EFC at the OCXO which is only being driven 
by the VRef output of the OCXO.  I think it clears the 3456A of any wrongdoing.

http://evoria.net/AE6RV/TIC/VRef.vs.3456A.png

The second one tests the noise from the op-amp by supplying its input with 3.3V 
from the PIC's VDD.  The PIC's DAC output is disconnected for this plot.  
There's a few more tens of microvolts of noise than in the one above, but 
that's to be expected, I think.  It's certainly nowhere near the noise on the 
other two plots driven by the DAC.


http://evoria.net/AE6RV/TIC/Op-Amp.png

Bob






 From: Bob Stewart 
To: Time Nuts  
Sent: Wednesday, September 10, 2014 10:06 PM
Subject: [time-nuts] Help understanding an ADEV
 

After spending a lot of effort trying to get some useful tuning figures for the 
PID in my GPSDO engine, I decided to capture the DAC output with my 3456A.  
And, of course I've made an ADEV plot.  If I understand this correctly, it 
means that there is mostly justnoise out to 2 tau, and an area from about 4-5 
tau is mostly noise, as well.  Could someone tell me if I have this right?  It 
matches what I'm seeing on the delta plot, and would explain why we couldn't 
get anything approaching reasonable stability from the OCXO, since the noise is 
larger than the increments being made to the DAC.


I've ordered the PWM version of the PIC, and hopefully, since it's the motor 
control version (as opposed to the audio version) it will have much better 
noise performance.

The red scatter is the EFC measured at the OCXO in tens of microvolts, and the 
blue line is the ADEV.  I'm using a short shielded twisted-pair with 
mini-clipsas the probe.  Hopefully I've got things scaled properly and have run 
the test properly.


http://evoria.net/AE6RV/TIC/DAC.wander.png

Bob - AE6RV
___
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] Help understanding an ADEV

[Bob Stewart]

Hi Bob,

After I posted last night, I realized that the loop was running, so I froze 
the DAC and did another sample.  Here is the voltage plot in 10s of uV, 
as well as the ADEV.  I can pull the op-amp out of the GSPDO engine and 
plot it without the DAC attached if that would be helpful.  There is a 
voltage-divider at the OCXO attached to the VRef output from the OCXO.  As 
always, I use Tom's adev1 software.


http://evoria.net/AE6RV/TIC/DAC.wander.2.png

I don't understand what you are asking for to do an ADEV of the GPS.  What do I 
plot and under what conditions?

I've been wondering if it would be better to look in the frequency domain.  
I'll have to look at Tom's site to see if he has code to do that.
Bob



 From: Bob Camp 
To: Bob Stewart ; Discussion of precise time and frequency 
measurement  
Sent: Thursday, September 11, 2014 6:10 AM
Subject: Re: [time-nuts] Help understanding an ADEV
 

Hi

The plot pretty much confirms what you already know - there is a noise spectrum 
and it’s not what you want to have. In a closed loop system, it’s all going to 
add up. The big unknown is - do you get noise out of the DAC trying to correct 
the OCXO’s noise or just noise out of the DAC? Is the DAC noise from the DAC 
it’s self or from the loop?

One source of noise is the LSB on the DAC. If you have a 1 ppm EFC and a 
1x10^-12 OCXO and a 1 LSB change at 1 second (yes that’s a lot …) - That’s a 
1x10^6 delta, you must have a ~20 bit DAC. If you have 1x10^-8 out of your GPS, 
 your loop (or filter) must have a 10,000:1 attenuation at 1 Hz. That’s 80 db. 
If you have a simple loop, you get 20 db / decade. That would put your tau 
below 0.0001 Hz.

Yes those are fast and simple numbers. The real stuff has a lot more if’s and’s 
and but’s in it.  

Simple way to check things:

1) Do an ADEV on the OCXO + EFC and make sure it looks right outside the loop.
2) Do an ADEV on your GPS and figure out where it’s at. 
3) Consider checking the noise in the frequency domain, it’s easier to 
understand.

So much fun.

Bob


On Sep 10, 2014, at 11:06 PM, Bob Stewart  wrote:

> After spending a lot of effort trying to get some useful tuning figures for 
> the PID in my GPSDO engine, I decided to capture the DAC output with my 
> 3456A.  And, of course I've made an ADEV plot.  If I understand this 
> correctly, it means that there is mostly justnoise out to 2 tau, and an area 
> from about 4-5 tau is mostly noise, as well.  Could someone tell me if I have 
> this right?  It matches what I'm seeing on the delta plot, and would explain 
> why we couldn't get anything approaching reasonable stability from the OCXO, 
> since the noise is larger than the increments being made to the DAC.
> 
> 
> I've ordered the PWM version of the PIC, and hopefully, since it's the motor 
> control version (as opposed to the audio version) it will have much better 
> noise performance.
> 
> The red scatter is the EFC measured at the OCXO in tens of microvolts, and 
> the blue line is the ADEV.  I'm using a short shielded twisted-pair with 
> mini-clipsas the probe.  Hopefully I've got things scaled properly and have 
> run the test properly.
> 
> 
> http://evoria.net/AE6RV/TIC/DAC.wander.png
> 
> Bob - AE6RV
> ___
> 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] Help understanding an ADEV

[Tom Van Baak]

Hi Bob S,

Since you're using DAC voltage as an input, did you calculate ADEV using the 
"y" equation (single difference) instead of the usual "x" equation (double 
difference)?

Looking at the red dots, there is significant measurement quantization (1 unit, 
or 10 uV) and a massive amount of noise (close to 50 units, half a millivolt). 
Is this due to your voltmeter, your measurement setup, or is the DAC really 
that terrible?

In your case, an ADEV plot made from a phase or frequency measurement should 
match an ADEV plot made from a DAC measurement. However, the fidelity of the 
plot is highly dependent on the resolution of the instrument being used. 
Typically you choose between a phase meter, frequency counter, or voltmeter by 
which one gives you the best resolution. Otherwise your ADEV plot is just 
showing the limitations of your instrument, not the GPSDO that you're trying to 
measure.

/tvb

- Original Message - 
From: "Bob Stewart" 
To: "Time Nuts" 
Sent: Wednesday, September 10, 2014 8:06 PM
Subject: [time-nuts] Help understanding an ADEV


> After spending a lot of effort trying to get some useful tuning figures for 
> the PID in my GPSDO engine, I decided to capture the DAC output with my 
> 3456A.  And, of course I've made an ADEV plot.  If I understand this 
> correctly, it means that there is mostly justnoise out to 2 tau, and an area 
> from about 4-5 tau is mostly noise, as well.  Could someone tell me if I have 
> this right?  It matches what I'm seeing on the delta plot, and would explain 
> why we couldn't get anything approaching reasonable stability from the OCXO, 
> since the noise is larger than the increments being made to the DAC.
> 
> 
> I've ordered the PWM version of the PIC, and hopefully, since it's the motor 
> control version (as opposed to the audio version) it will have much better 
> noise performance.
> 
> The red scatter is the EFC measured at the OCXO in tens of microvolts, and 
> the blue line is the ADEV.  I'm using a short shielded twisted-pair with 
> mini-clipsas the probe.  Hopefully I've got things scaled properly and have 
> run the test properly.
> 
> 
> http://evoria.net/AE6RV/TIC/DAC.wander.png
> 
> Bob - AE6RV


___
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] Help understanding an ADEV

[Bob Camp]

Hi

The plot pretty much confirms what you already know - there is a noise spectrum 
and it’s not what you want to have. In a closed loop system, it’s all going to 
add up. The big unknown is - do you get noise out of the DAC trying to correct 
the OCXO’s noise or just noise out of the DAC? Is the DAC noise from the DAC 
it’s self or from the loop?

One source of noise is the LSB on the DAC. If you have a 1 ppm EFC and a 
1x10^-12 OCXO and a 1 LSB change at 1 second (yes that’s a lot …) - That’s a 
1x10^6 delta, you must have a ~20 bit DAC. If you have 1x10^-8 out of your GPS, 
 your loop (or filter) must have a 10,000:1 attenuation at 1 Hz. That’s 80 db. 
If you have a simple loop, you get 20 db / decade. That would put your tau 
below 0.0001 Hz.

Yes those are fast and simple numbers. The real stuff has a lot more if’s and’s 
and but’s in it.  

Simple way to check things:

1) Do an ADEV on the OCXO + EFC and make sure it looks right outside the loop.
2) Do an ADEV on your GPS and figure out where it’s at. 
3) Consider checking the noise in the frequency domain, it’s easier to 
understand.

So much fun.

Bob

On Sep 10, 2014, at 11:06 PM, Bob Stewart  wrote:

> After spending a lot of effort trying to get some useful tuning figures for 
> the PID in my GPSDO engine, I decided to capture the DAC output with my 
> 3456A.  And, of course I've made an ADEV plot.  If I understand this 
> correctly, it means that there is mostly justnoise out to 2 tau, and an area 
> from about 4-5 tau is mostly noise, as well.  Could someone tell me if I have 
> this right?  It matches what I'm seeing on the delta plot, and would explain 
> why we couldn't get anything approaching reasonable stability from the OCXO, 
> since the noise is larger than the increments being made to the DAC.
> 
> 
> I've ordered the PWM version of the PIC, and hopefully, since it's the motor 
> control version (as opposed to the audio version) it will have much better 
> noise performance.
> 
> The red scatter is the EFC measured at the OCXO in tens of microvolts, and 
> the blue line is the ADEV.  I'm using a short shielded twisted-pair with 
> mini-clipsas the probe.  Hopefully I've got things scaled properly and have 
> run the test properly.
> 
> 
> http://evoria.net/AE6RV/TIC/DAC.wander.png
> 
> Bob - AE6RV
> ___
> 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] help me understand AM noise

[life speed]

Thanks for the link.

My current lineup is:

13 dBm source -> variable attenuator -> amp -> variable attenuator -> amp -> 
filter -> pad -> amp -> filter -> 20 dBm output

I think I already paid attention to interleaving gain and loss, as well as not 
reducing the signal to very low levels so as to gain up the noise floor too 
much.  At the moment I am also not much concerned with ALC behavior or 
stability as the AM noise measurements do not show much issue with this.

Mostly I am concerned with additive noise from the somewhat complex opamp 
circuits driving (and linearizing) the series/shunt topology microwave FET 
voltage-variable attenuators.  I would like to understand what changes in noise 
floor are just a result of attenuating the RF chain over it's amplitude control 
range, and what noise I am adding by my imperfect (noisy) attenuator driver 
circuitry.  I have already made some improvements in this area by 
bandwidth-limiting the opamps (I need about 1 MHz 3 dB corner for ALC stability 
and AM modulation) and switching to some lower noise opamps.  So clearly it was 
not perfect.  Just trying to figure out how much is added AM noise by my 
circuit and how much is laws of physics by increasing the attenuation.

Lifespeed


On Wed, 1/29/14, John Miles  wrote:

 Subject: Re: [time-nuts] help me understand AM noise
 To: "'Discussion of precise time and frequency measurement'" 

 Date: Wednesday, January 29, 2014, 4:46 PM
 
 If you're just using
 a single attenuator at the input of your PA, it makes
 sense that the additive noise in dBc terms is
 worse at lower output levels.
 Disregarding
 saturation for the moment, the PA is adding just as much
 noise
 to a low-level input signal as it does
 to a high-level signal. 
 
 ALC-controlled amps need to be designed with
 multiple alternating stages of
 attenuation
 and gain.  Whatever drives the PIN diodes or other
 attenuators
 also needs to be quiet and
 well-filtered, of course -- which also means
 keeping an eye on feedback stability.
 
 My (least) favorite
 counterexample is the IF amp in the HP 11729C noise test
 set.  It's not even an ALC amplifier, but
 a true limiting amplifier.  It was
 implemented by cascading several high-gain
 MMICs with clamp diodes between
 each
 stage.  Makes a nice comb generator.  They were driving a
 mixer so they
 would have reasoned that odd
 harmonics were acceptable, but because there
 was no interstage attenuation for low-level
 noise, the amplifier's additive
 AM and
 PM levels were awful.  You'll see similar performance
 if you measure
 the additive noise of a
 comparator or other limiting amp.  Several limiting
 amps were used in the HP 8662A/8663A
 synthesizer as well, which is why they
 have
 good close-in noise but a relatively poor white noise
 floor.  As long
 as you avoid these mistakes
 you'll be ahead of 90% of the crowd.
 
 As far as further reading goes, check out http://rubiola.org/index.html .
 
 -- john, KE5FX
 Miles Design LLC
 
 
 > -Original Message-
 > From: time-nuts-boun...@febo.com
 [mailto:time-nuts-
 > boun...@febo.com] On
 Behalf Of life speed
 > Sent: Wednesday,
 January 29, 2014 10:32 AM
 > To: time-nuts@febo.com
 > Subject: [time-nuts] help me understand AM
 noise
 > 
 > Hi Guys. 
 It has been a while since I posted, hope you can help with
 a
 slightly
 > time-related
 topic.  Can't have frequency without amplitude . . .
 > 
 > I recently designed
 an Automatic Level Control circuit consisting of dual-
 > slope detector logger, open and closed
 loop references with AM
 > modulation, and
 a linearizer (volts/dB) driver for series/shunt microwave
 > attenuators.  This is part of a DC - 20
 GHz microwave synthesizer.  I
 measured
 > the AM noise at 3 GHz, both open and
 closed loop, and find the noise level
 >
 is higher at the output of the attenuator/amplifier chain at
 similar power
 > levels to the input (13
 dBm).  The input RF chain saturates at about 17
 dBm,
 > while the output amp
 following the attenuators saturates at about 20 dBm.
 > 
 > I understand that an
 amplifier in compression will suppress AM noise. 
 What
 > I wonder is are my
 measurements of increased AM noise (red trace) at the
 > output of the attenuator/amp lineup to be
 expected based on the higher
 > available
 saturated power?  Is it possible to attenuate the signal
 using
 the
 > power control
 (open loop in this example, ALC is not used) without
 > degrading AM noise performance?  Does
 anybody have any suggested
 > reading on
 this subject?  I am trying to understand how well my
 circuit
 > performs, in general.  I do
 observe that control the power to a lower 
 level
 > increases the AM
 noise.  But it is a relative measurement to begin with,
 so
 > what is
 "good"?  I have 

Re: [time-nuts] help me understand AM noise

[John Miles]

If you're just using a single attenuator at the input of your PA, it makes
sense that the additive noise in dBc terms is worse at lower output levels.
Disregarding saturation for the moment, the PA is adding just as much noise
to a low-level input signal as it does to a high-level signal. 

ALC-controlled amps need to be designed with multiple alternating stages of
attenuation and gain.  Whatever drives the PIN diodes or other attenuators
also needs to be quiet and well-filtered, of course -- which also means
keeping an eye on feedback stability.

My (least) favorite counterexample is the IF amp in the HP 11729C noise test
set.  It's not even an ALC amplifier, but a true limiting amplifier.  It was
implemented by cascading several high-gain MMICs with clamp diodes between
each stage.  Makes a nice comb generator.  They were driving a mixer so they
would have reasoned that odd harmonics were acceptable, but because there
was no interstage attenuation for low-level noise, the amplifier's additive
AM and PM levels were awful.  You'll see similar performance if you measure
the additive noise of a comparator or other limiting amp.  Several limiting
amps were used in the HP 8662A/8663A synthesizer as well, which is why they
have good close-in noise but a relatively poor white noise floor.  As long
as you avoid these mistakes you'll be ahead of 90% of the crowd.

As far as further reading goes, check out http://rubiola.org/index.html .

-- john, KE5FX
Miles Design LLC


> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-
> boun...@febo.com] On Behalf Of life speed
> Sent: Wednesday, January 29, 2014 10:32 AM
> To: time-nuts@febo.com
> Subject: [time-nuts] help me understand AM noise
> 
> Hi Guys.  It has been a while since I posted, hope you can help with a
slightly
> time-related topic.  Can't have frequency without amplitude . . .
> 
> I recently designed an Automatic Level Control circuit consisting of dual-
> slope detector logger, open and closed loop references with AM
> modulation, and a linearizer (volts/dB) driver for series/shunt microwave
> attenuators.  This is part of a DC - 20 GHz microwave synthesizer.  I
measured
> the AM noise at 3 GHz, both open and closed loop, and find the noise level
> is higher at the output of the attenuator/amplifier chain at similar power
> levels to the input (13 dBm).  The input RF chain saturates at about 17
dBm,
> while the output amp following the attenuators saturates at about 20 dBm.
> 
> I understand that an amplifier in compression will suppress AM noise. 
What
> I wonder is are my measurements of increased AM noise (red trace) at the
> output of the attenuator/amp lineup to be expected based on the higher
> available saturated power?  Is it possible to attenuate the signal using
the
> power control (open loop in this example, ALC is not used) without
> degrading AM noise performance?  Does anybody have any suggested
> reading on this subject?  I am trying to understand how well my circuit
> performs, in general.  I do observe that control the power to a lower 
level
> increases the AM noise.  But it is a relative measurement to begin with,
so
> what is "good"?  I have been reading the Agilent E5500 user guide on AM
> noise measurements, but don't find a great deal of information there
> regarding AM noise performance of a Device Under Test.
> 
> Thanks,
> 
> Lifespeed
> 
> http://home.comcast.net/~claybu/pics/electronics/am_noise_1.png
> 

___
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] Help for general GPIB problem

[John Miles]

Hmm, yes, it's tough to say what might have motivated that recommendation.
I have no idea what a "device template" is, or what it might mean for
ibfind() to be "difficult to port."  It's worked for many years here, with
both genuine and emulated (HP 82350-series) adapters.

The one issue I've experienced is the inability of 64-bit Windows apps to
detect the emulated NI488.2 devices provided by Agilent I/O Libraries for
the 82357 adapters.  This is why the 32-bit drivers are still linked with
gpib-32.obj rather than the newer ni4882.obj API module.  
 
-- john, KE5FX
Miles Design LLC


> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-
> boun...@febo.com] On Behalf Of Ulrich Bangert
> Sent: Friday, January 24, 2014 1:29 AM
> To: 'Discussion of precise time and frequency measurement'
> Subject: Re: [time-nuts] Help for general GPIB problem
> 
> John,
> 
> thank you for your help. The idea to use IBDEV resulted from the following
> official NI statement:
> 
> Snip
> 
> For current and new GPIB applications, IBDEV should be used. IBFIND will
> return a board or device descriptor based off the device templates in the
> GPIB.ini file. Since IBFIND relies on GPIB.ini to return the board or
device
> descriptor, it is difficult to port. For example, with the device
templates,
> the device name can be changed to a custom name. Unless the device
> templates
> are ported to the target machine, the call will fail. IBFIND is found in
> older applications and can be easily updated to using IBDEV instead.
> 
> IBDEV is far more portable in that it frees the application from the need
to
> rely on specific device names. IBDEV also returns a board or device
> descriptor but allows you to programmatically specify all the required
input
> parameters in the parameter list of IBDEV (thus avoiding the need to refer
> to device templates). IBDEV should be used when creating a new GPIB
> device
> application.
> 
> IBFIND should still be used to open a GPIB board communication session,
> not
> for communication with instruments.
> 
> Snip---
> 
> But i will of course follow your suggestion to look up Timelab's
enumeration
> function.
> 
> 73's de Ulrich, DF6JB
> 
> > -Ursprungliche Nachricht-
> > Von: time-nuts-boun...@febo.com
> > [mailto:time-nuts-boun...@febo.com] Im Auftrag von John Miles
> > Gesendet: Freitag, 24. Januar 2014 08:58
> > An: 'Discussion of precise time and frequency measurement'
> > Betreff: Re: [time-nuts] Help for general GPIB problem
> >
> >
> > You probably want ibfind() rather than ibdev().  Take a look
> > at gpibport.cpp in the TimeLab source
> > (drivers/shared/gpibport.cpp under the installation folder),
> > in the enumerate_ports() function.
> >
> > -- john, KE5FX
> > Miles Design LLC
> >
> > > -Original Message-
> > > From: time-nuts-boun...@febo.com [mailto:time-nuts-
> > boun...@febo.com]
> > > On Behalf Of Ulrich Bangert
> > > Sent: Thursday, January 23, 2014 3:23 AM
> > > To: Time nuts
> > > Subject: [time-nuts] Help for general GPIB problem
> > >
> > > Gentlemen,
> > >
> > > I am just going to improve my EZGPIB utility so that it can
> > make use
> > > of
> > more
> > > than one GPIB-interface (supported by GPIB32.Dll, not Prologix). I
> > > have been trying to enumerate all detected interfaces by using
> > >
> > > ibdev(bi,0,0,T300ms,0,1)
> > >
> > > in a loop where bi starts with "0" and is incremented by
> > "1" until the
> > > result of the call gets negative. Much to my surprise this loop
> > > detects 4
> > > (!) interfaces GPIB0 to GPIB3 even if absolutely NO
> > interface is connected
> > > to the pc.
> > >
> > > What am I doing wrong. Is "4" the maximum number of interfaces that
> > > may be handled by GPIB32.Dll 
> > >
> > > What do I need to do to find the real number of detected interfaces
> > > ?
> > >
> > > Best regards and TIA for your answers
> > >
> > > Ulrich Bangert
> > > www.ulrich-bangert.de
> > > Ortholzer Weg 1
> > > 27243 Gross Ippener
> > >
> > > ___
> > > time-nuts mailing list -- time-nuts@febo.com
> > > To unsubscribe, go to https://www.febo.com/cgi-
> > > bin/

Re: [time-nuts] Help for general GPIB problem

[Ulrich Bangert]

John,

thank you for your help. The idea to use IBDEV resulted from the following
official NI statement:

Snip

For current and new GPIB applications, IBDEV should be used. IBFIND will
return a board or device descriptor based off the device templates in the
GPIB.ini file. Since IBFIND relies on GPIB.ini to return the board or device
descriptor, it is difficult to port. For example, with the device templates,
the device name can be changed to a custom name. Unless the device templates
are ported to the target machine, the call will fail. IBFIND is found in
older applications and can be easily updated to using IBDEV instead.

IBDEV is far more portable in that it frees the application from the need to
rely on specific device names. IBDEV also returns a board or device
descriptor but allows you to programmatically specify all the required input
parameters in the parameter list of IBDEV (thus avoiding the need to refer
to device templates). IBDEV should be used when creating a new GPIB device
application.

IBFIND should still be used to open a GPIB board communication session, not
for communication with instruments.

Snip---

But i will of course follow your suggestion to look up Timelab's enumeration
function.

73's de Ulrich, DF6JB 

> -Ursprungliche Nachricht-
> Von: time-nuts-boun...@febo.com 
> [mailto:time-nuts-boun...@febo.com] Im Auftrag von John Miles
> Gesendet: Freitag, 24. Januar 2014 08:58
> An: 'Discussion of precise time and frequency measurement'
> Betreff: Re: [time-nuts] Help for general GPIB problem
> 
> 
> You probably want ibfind() rather than ibdev().  Take a look 
> at gpibport.cpp in the TimeLab source 
> (drivers/shared/gpibport.cpp under the installation folder), 
> in the enumerate_ports() function.  
> 
> -- john, KE5FX
> Miles Design LLC
> 
> > -Original Message-
> > From: time-nuts-boun...@febo.com [mailto:time-nuts- 
> boun...@febo.com] 
> > On Behalf Of Ulrich Bangert
> > Sent: Thursday, January 23, 2014 3:23 AM
> > To: Time nuts
> > Subject: [time-nuts] Help for general GPIB problem
> > 
> > Gentlemen,
> > 
> > I am just going to improve my EZGPIB utility so that it can 
> make use 
> > of
> more
> > than one GPIB-interface (supported by GPIB32.Dll, not Prologix). I 
> > have been trying to enumerate all detected interfaces by using
> > 
> > ibdev(bi,0,0,T300ms,0,1)
> > 
> > in a loop where bi starts with "0" and is incremented by 
> "1" until the 
> > result of the call gets negative. Much to my surprise this loop 
> > detects 4
> > (!) interfaces GPIB0 to GPIB3 even if absolutely NO 
> interface is connected
> > to the pc.
> > 
> > What am I doing wrong. Is "4" the maximum number of interfaces that 
> > may be handled by GPIB32.Dll 
> > 
> > What do I need to do to find the real number of detected interfaces 
> > ?
> > 
> > Best regards and TIA for your answers
> > 
> > Ulrich Bangert
> > www.ulrich-bangert.de
> > Ortholzer Weg 1
> > 27243 Gross Ippener
> > 
> > ___
> > 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.

Re: [time-nuts] Help for general GPIB problem

[John Miles]

You probably want ibfind() rather than ibdev().  Take a look at gpibport.cpp
in the TimeLab source (drivers/shared/gpibport.cpp under the installation
folder), in the enumerate_ports() function.  

-- john, KE5FX
Miles Design LLC

> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-
> boun...@febo.com] On Behalf Of Ulrich Bangert
> Sent: Thursday, January 23, 2014 3:23 AM
> To: Time nuts
> Subject: [time-nuts] Help for general GPIB problem
> 
> Gentlemen,
> 
> I am just going to improve my EZGPIB utility so that it can make use of
more
> than one GPIB-interface (supported by GPIB32.Dll, not Prologix). I have
> been
> trying to enumerate all detected interfaces by using
> 
> ibdev(bi,0,0,T300ms,0,1)
> 
> in a loop where bi starts with "0" and is incremented by "1" until the
> result of the call gets negative. Much to my surprise this loop detects 4
> (!) interfaces GPIB0 to GPIB3 even if absolutely NO interface is connected
> to the pc.
> 
> What am I doing wrong. Is "4" the maximum number of interfaces that may
> be
> handled by GPIB32.Dll 
> 
> What do I need to do to find the real number of detected interfaces ?
> 
> Best regards and TIA for your answers
> 
> Ulrich Bangert
> www.ulrich-bangert.de
> Ortholzer Weg 1
> 27243 Gross Ippener
> 
> ___
> 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] Help for general GPIB problem

[Azelio Boriani]

OK, understood. So it seems that the next step is to try to connect
with those reported devices and see if an error is returned,
identifying the really connected ones from the placeholders...

On Thu, Jan 23, 2014 at 5:00 PM, Ulrich Bangert  wrote:
> Azelio,
>
>> Try to stop the HPIB driver...
>
> I do not have any HPIB (=HP specific) driver in my system. Instead I use the
> GPIB32.DLL that comes together with every National Instruments GPIB
> interface adapter. The DLL is basically thought as the National Instruments
> support for C-Programmers but I wrote a wrapper unit to be able to use the
> DLL from my Delphi programming environment.
>
> The DLL is the BASIC translation between software and hardware and can
> hardly been left away. It is responsible for the fact that you can use the
> same DLL function calls regardless of what physical interface is used, i.e.
> it works with a PCI plugin card as well as with USB to GPIB adapters as well
> as with network based GPIB adapters (as long as the all come from NI). That
> is one of the really NEAT things with NI stuff.
>
> Best regards
> Ulrich
>
>
>
>> -Ursprungliche Nachricht-
>> Von: time-nuts-boun...@febo.com
>> [mailto:time-nuts-boun...@febo.com] Im Auftrag von Azelio Boriani
>> Gesendet: Donnerstag, 23. Januar 2014 14:27
>> An: Discussion of precise time and frequency measurement
>> Betreff: Re: [time-nuts] Help for general GPIB problem
>>
>>
>> Try to stop the HPIB driver... maybe the driver is reporting
>> as available even if no hardware is actually connected.
>>
>> On Thu, Jan 23, 2014 at 12:22 PM, Ulrich Bangert
>>  wrote:
>> > Gentlemen,
>> >
>> > I am just going to improve my EZGPIB utility so that it can
>> make use
>> > of more than one GPIB-interface (supported by GPIB32.Dll, not
>> > Prologix). I have been trying to enumerate all detected
>> interfaces by
>> > using
>> >
>> > ibdev(bi,0,0,T300ms,0,1)
>> >
>> > in a loop where bi starts with "0" and is incremented by
>> "1" until the
>> > result of the call gets negative. Much to my surprise this loop
>> > detects 4
>> > (!) interfaces GPIB0 to GPIB3 even if absolutely NO
>> interface is connected
>> > to the pc.
>> >
>> > What am I doing wrong. Is "4" the maximum number of interfaces that
>> > may be handled by GPIB32.Dll 
>> >
>> > What do I need to do to find the real number of detected interfaces
>> > ?
>> >
>> > Best regards and TIA for your answers
>> >
>> > Ulrich Bangert
>> > www.ulrich-bangert.de
>> > Ortholzer Weg 1
>> > 27243 Gross Ippener
>> >
>> > ___
>> > time-nuts mailing list -- time-nuts@febo.com
>> > To unsubscribe, go to
>> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> > and follow the instructions there.
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Help for general GPIB problem

[Ulrich Bangert]

Azelio,

> Try to stop the HPIB driver...

I do not have any HPIB (=HP specific) driver in my system. Instead I use the
GPIB32.DLL that comes together with every National Instruments GPIB
interface adapter. The DLL is basically thought as the National Instruments
support for C-Programmers but I wrote a wrapper unit to be able to use the
DLL from my Delphi programming environment.  

The DLL is the BASIC translation between software and hardware and can
hardly been left away. It is responsible for the fact that you can use the
same DLL function calls regardless of what physical interface is used, i.e.
it works with a PCI plugin card as well as with USB to GPIB adapters as well
as with network based GPIB adapters (as long as the all come from NI). That
is one of the really NEAT things with NI stuff.

Best regards
Ulrich 



> -Ursprungliche Nachricht-
> Von: time-nuts-boun...@febo.com 
> [mailto:time-nuts-boun...@febo.com] Im Auftrag von Azelio Boriani
> Gesendet: Donnerstag, 23. Januar 2014 14:27
> An: Discussion of precise time and frequency measurement
> Betreff: Re: [time-nuts] Help for general GPIB problem
> 
> 
> Try to stop the HPIB driver... maybe the driver is reporting 
> as available even if no hardware is actually connected.
> 
> On Thu, Jan 23, 2014 at 12:22 PM, Ulrich Bangert 
>  wrote:
> > Gentlemen,
> >
> > I am just going to improve my EZGPIB utility so that it can 
> make use 
> > of more than one GPIB-interface (supported by GPIB32.Dll, not 
> > Prologix). I have been trying to enumerate all detected 
> interfaces by 
> > using
> >
> > ibdev(bi,0,0,T300ms,0,1)
> >
> > in a loop where bi starts with "0" and is incremented by 
> "1" until the 
> > result of the call gets negative. Much to my surprise this loop 
> > detects 4
> > (!) interfaces GPIB0 to GPIB3 even if absolutely NO 
> interface is connected
> > to the pc.
> >
> > What am I doing wrong. Is "4" the maximum number of interfaces that 
> > may be handled by GPIB32.Dll 
> >
> > What do I need to do to find the real number of detected interfaces 
> > ?
> >
> > Best regards and TIA for your answers
> >
> > Ulrich Bangert
> > www.ulrich-bangert.de
> > Ortholzer Weg 1
> > 27243 Gross Ippener
> >
> > ___
> > 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.

Re: [time-nuts] Help for general GPIB problem

[Azelio Boriani]

Try to stop the HPIB driver... maybe the driver is reporting as
available even if no hardware is actually connected.

On Thu, Jan 23, 2014 at 12:22 PM, Ulrich Bangert
 wrote:
> Gentlemen,
>
> I am just going to improve my EZGPIB utility so that it can make use of more
> than one GPIB-interface (supported by GPIB32.Dll, not Prologix). I have been
> trying to enumerate all detected interfaces by using
>
> ibdev(bi,0,0,T300ms,0,1)
>
> in a loop where bi starts with "0" and is incremented by "1" until the
> result of the call gets negative. Much to my surprise this loop detects 4
> (!) interfaces GPIB0 to GPIB3 even if absolutely NO interface is connected
> to the pc.
>
> What am I doing wrong. Is "4" the maximum number of interfaces that may be
> handled by GPIB32.Dll 
>
> What do I need to do to find the real number of detected interfaces ?
>
> Best regards and TIA for your answers
>
> Ulrich Bangert
> www.ulrich-bangert.de
> Ortholzer Weg 1
> 27243 Gross Ippener
>
> ___
> 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] Help in Locking a Windows Computer to GPS Time

[David J Taylor]

From: Hal Murray


I think the OP wants "UTC time from a GPS" rather than "GPS time".


In case, it should be simple.


But even  if it /was/ GPS time, couldn't a set of simple "fudge" 
statements

in the NTP  configuration provide that?  OK, you would need to change the
fudge lines  when the GPS to UTC offset changed...


I think that would work.

Another complication is that there isn't any fudge offset for other servers
(non refclocks) so you can't use normal servers running on UTC as a sanity
check.
===

Oh, if you can't use a fudge on other servers, that's a pity, and I wouldn't 
then trust such a fiddled clock.  Mind you, I can quite understand why it's 
not allowed!


Thanks, Hal.

David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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] Help in Locking a Windows Computer to GPS Time

[Rex Moncur]

Hi David

Yes I did not make myself clear but I am looking for UTC time from a GPS.
Thanks for all your references which I will work through and see how I go.

Regards Rex VK7MO

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of David J Taylor
Sent: Thursday, 22 August 2013 6:24 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Help in Locking a Windows Computer to GPS Time

From: Hal Murray

I think you are missing the big picture.

The OP wanted GPS time.

NTP isn't setup to work with GPS time rather than UTC.
[]
=

I think the OP wants "UTC time from a GPS" rather than "GPS time".  But even
if it /was/ GPS time, couldn't a set of simple "fudge" statements in the NTP
configuration provide that?  OK, you would need to change the fudge lines
when the GPS to UTC offset changed...

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 

___
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] Help in Locking a Windows Computer to GPS Time

[Hal Murray]

> I think the OP wants "UTC time from a GPS" rather than "GPS time".

In case, it should be simple.


> But even  if it /was/ GPS time, couldn't a set of simple "fudge" statements
> in the NTP  configuration provide that?  OK, you would need to change the
> fudge lines  when the GPS to UTC offset changed...

I think that would work.

Another complication is that there isn't any fudge offset for other servers 
(non refclocks) so you can't use normal servers running on UTC as a sanity 
check.


-- 
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] Help in Locking a Windows Computer to GPS Time

[David J Taylor]

From: Hal Murray

I think you are missing the big picture.

The OP wanted GPS time.

NTP isn't setup to work with GPS time rather than UTC.
[]
=

I think the OP wants "UTC time from a GPS" rather than "GPS time".  But even 
if it /was/ GPS time, couldn't a set of simple "fudge" statements in the NTP 
configuration provide that?  OK, you would need to change the fudge lines 
when the GPS to UTC offset changed...


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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] Help in Locking a Windows Computer to GPS Time

[Hal Murray]

albertson.ch...@gmail.com said:
> NTP will use the "best" reference clocks it finds.  If that is GPS it will
> use that.  It can also use other NTP servers.   Typically people use those
> rather then getting their own GPS receiver.  If the PC has a network
> connection you can likely get time to within a few milliseconds using NTP
> and a few of the pool time servers. 

I think you are missing the big picture.

The OP wanted GPS time.

NTP isn't setup to work with GPS time rather than UTC.

None of the typical low cost GPS/NMEA receivers tell you GPS time rather than 
UTC.  Some of them tell you the offset.

If you really want GPS time, you have two choices.
  One is to get UTC via NTP and the offset via IERS, USNO, and NIST, and 
probably others.
  This has troubles when the leap-second offset changes.

  The other would be to listen to various GPS devices and see if you can get 
GPS time rather than UTC.  It might work to hack various refclock drivers 
distributed with the NTP reference package.





-- 
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] Help in Locking a Windows Computer to GPS Time

[David J Taylor]

Hello

You can try Nmeatime: "www.visualgps.net/NMEATime/"

Regards
===

Some advantages of the standard NTP software over NMEATime are listed here:

 http://www.satsignal.eu/ntp/setup.html#why

The OP's main problem is that his GPS receiver does not include PPS, but a 
new, low-cost receiver easily solves that problem.


Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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] Help in Locking a Windows Computer to GPS Time

[Dimitry Borzenko]

 

 Hello 

You can try Nmeatime: "www.visualgps.net/NMEATime/" 

 Regards

 On 21/08/13 23:48 , Chris Albertson albertson.ch...@gmail.com sent:
  It's simple, just install and run "NTP"

 On Wed, Aug 21, 2013 at 9:02 PM, Rex Moncur  wrote:

 > I am trying to lock a Windows XP computer to GPS time taking advantage
of
 > both the NEMA sentence and the 1PPS with the hope of getting to within
a
 > few
 > ms.
 >
 > I am using a Garmin GPS 18PC and the NMEATime program. When I tick the
box
 > to implement the 1PPS feature on NMEATime the program locks up each
time it
 > attempts to correct the PC time. Perhaps there is something I need to
do
 > to
 > configure the GPS 18PC to fix this.
 >
 > I would be grateful for advice as to whether and how one can use
NMEATime
 > for this purpose with a Garmin GPS 18 PC or advice on other programs to
 > achieve accurate locking of the PC.
 >
 > Rex VK7MO
 >
 > ___
 > time-nuts mailing list -- 
 > To unsubscribe, go to
 > 
 > and follow the instructions there.
 >

 -- 

 Chris Albertson
 Redondo Beach, California
 ___
 time-nuts mailing list -- 
 To unsubscribe, go 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] Help in Locking a Windows Computer to GPS Time

[Chris Albertson]

Hit "send" a bit to soon.

NTP will use the "best" reference clocks it finds.  If that is GPS it will
use that.  It can also use other NTP servers.   Typically people use those
rather then getting their own GPS receiver.  If the PC has a network
connection you can likely get time to within a few milliseconds using NTP
and a few of the pool time servers.

I would defiantly recommend getting NTP to work using the pool servers
first.  Then add GPS.

Be warned that the NMEA spec says that messages apply to the current
second.  This means the NMEA data from the serial port can be up to one
second "off".  It is used only to tell you the number of the second, not
for accurate timing.For that NTP uses the PPS reference clock.  On some
GPS receivers (not your Garmin unit) the PPS is good for a few tens of
nanoseconds.

I looked up NMEATime.  It uses "SNTP" protocol.  It will never be very
accurate.  Think about a mechanical clock that you want to set.  First to
set it then you wait a day or so and see if it gains or looses time.  Then
you adust the rate, faster or slower.  Eventually the clock keeps good time
after a few more cycles of adjust and wait and check.   NTP works like
this.  SNTP simply sets the clock once then quits and never even looks at
the rate.

This is the place to get NTP
http://www.ntp.org
However many Windows users like to get third party versions of NTP.  These
are packages with installers and are good for people who can't build and
install the source distribution.  Google should find one.

About your Garmin GPS.   You can buy a real "timing receiver" for under $20
on eBay.  If you need nanoseconds that is the way to go.   A timing
reciever will have at least two features (1) position hold, where the
receiver is told it is NOT moving and (2) self survey, where the reciever
can take about 30 minutes or longer to deterim it's position to typically
less than a meter.  Position uncertainty creates time uncertainty (by the
speed of light) so not knowing you location by a meter means you don't know
the time within about 3 nanoseconds.






On Wed, Aug 21, 2013 at 11:48 PM, Chris Albertson  wrote:

> It's simple, just install and run "NTP"
> http://www.ntp.org/downloads.html
>
>
> On Wed, Aug 21, 2013 at 9:02 PM, Rex Moncur wrote:
>
>> I am trying to lock a Windows XP computer to GPS time taking advantage of
>> both the NEMA sentence and the 1PPS with the hope of getting to within a
>> few
>> ms.
>>
>> I am using a Garmin GPS 18PC and the NMEATime program.  When I tick the
>> box
>> to implement the 1PPS feature on NMEATime the program locks up each time
>> it
>> attempts to correct the PC time.  Perhaps there is something I need to do
>> to
>> configure the GPS 18PC to fix this.
>>
>> I would be grateful for advice as to whether and how one can use NMEATime
>> for this purpose with a Garmin GPS 18 PC or advice on other programs to
>> achieve accurate locking of the PC.
>>
>> Rex VK7MO
>>
>> ___
>> 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
>



-- 

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] Help in Locking a Windows Computer to GPS Time

[Dimitry Borzenko]

 

 Hello. 

You can try  

  

Regards. 

 On 21/08/13 23:48 , Chris Albertson albertson.ch...@gmail.com sent:
  It's simple, just install and run "NTP"

 On Wed, Aug 21, 2013 at 9:02 PM, Rex Moncur  wrote:

 > I am trying to lock a Windows XP computer to GPS time taking advantage
of
 > both the NEMA sentence and the 1PPS with the hope of getting to within
a
 > few
 > ms.
 >
 > I am using a Garmin GPS 18PC and the NMEATime program. When I tick the
box
 > to implement the 1PPS feature on NMEATime the program locks up each
time it
 > attempts to correct the PC time. Perhaps there is something I need to
do
 > to
 > configure the GPS 18PC to fix this.
 >
 > I would be grateful for advice as to whether and how one can use
NMEATime
 > for this purpose with a Garmin GPS 18 PC or advice on other programs to
 > achieve accurate locking of the PC.
 >
 > Rex VK7MO
 >
 > ___
 > time-nuts mailing list -- 
 > To unsubscribe, go to
 > 
 > and follow the instructions there.
 >

 -- 

 Chris Albertson
 Redondo Beach, California
 ___
 time-nuts mailing list -- 
 To unsubscribe, go 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] Help in Locking a Windows Computer to GPS Time

[Chris Albertson]

It's simple, just install and run "NTP"
http://www.ntp.org/downloads.html


On Wed, Aug 21, 2013 at 9:02 PM, Rex Moncur  wrote:

> I am trying to lock a Windows XP computer to GPS time taking advantage of
> both the NEMA sentence and the 1PPS with the hope of getting to within a
> few
> ms.
>
> I am using a Garmin GPS 18PC and the NMEATime program.  When I tick the box
> to implement the 1PPS feature on NMEATime the program locks up each time it
> attempts to correct the PC time.  Perhaps there is something I need to do
> to
> configure the GPS 18PC to fix this.
>
> I would be grateful for advice as to whether and how one can use NMEATime
> for this purpose with a Garmin GPS 18 PC or advice on other programs to
> achieve accurate locking of the PC.
>
> Rex VK7MO
>
> ___
> 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] Help in Locking a Windows Computer to GPS Time

[David J Taylor]

I am trying to lock a Windows XP computer to GPS time taking advantage of
both the NEMA sentence and the 1PPS with the hope of getting to within a few
ms.

I am using a Garmin GPS 18PC and the NMEATime program.  When I tick the box
to implement the 1PPS feature on NMEATime the program locks up each time it
attempts to correct the PC time.  Perhaps there is something I need to do to
configure the GPS 18PC to fix this.

I would be grateful for advice as to whether and how one can use NMEATime
for this purpose with a Garmin GPS 18 PC or advice on other programs to
achieve accurate locking of the PC.

Rex VK7MO
==

Rex,

Does the GPS 18PC even have a PPS output?  A module which does is this one:

 http://www.adafruit.com/products/746

and there are lots of others.

With Windows-8 and a bit of luck, you don't even need the PPS to get within 
a millisecond - see:


 http://www.satsignal.eu/mrtg/bergen_ntp_2.html

and that's over a Wi-Fi connection!  More typically, though, using PPS will 
get you within a millisecond = how much depends on the version of Windows 
you are using:


 http://www.satsignal.eu/mrtg/performance_ntp.php#windows-stratum-1

(PC Feenix is currently playing up, hence the glitches)  PC Alta is 
Windows-7, and PC Stamsund Windows-8.  I also have an XP PC whose graphs are 
not so regularly updated:


 http://www.satsignal.eu/mrtg/Old-Feenix/feenix_ntp_2.html

using a ublox NEO 6M module from China.

Rather than NMEATime, which uses just a small subset of the capabilities on 
NTP, use the standard NTP software from Meinberg, installed as per my 
instructions here:


 http://www.satsignal.eu/ntp/setup.html

Once that is done, and you have the serial GPS recognised (its performance 
won't be that good), add the PPS support with the special driver, as 
documented here:


 http://www.satsignal.eu/ntp/NTP-on-Windows-Vista.html

Performance of a Windows-7 system using that kernel-mode driver is here:

 http://www.satsignal.eu/mrtg/alta_ntp_2.html

Averaged jitter of under 35 microseconds.  The Windows-8 system (where the 
more precise timestamp instructions are available in the OS) has jitter 
under 20 microseconds.


73,
David GM8ARV
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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] Help support the microwave addiction.

[Lizeth Norman]

Pictures at:
http://www.flickr.com/photos/n3ykf/

___
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] Help support the microwave addiction.

[Edgardo Molina]

Hi,

May I see pictures of both kits off list please?  xe1xus at amsat dot org 
Thanks.

Regards,



Edgardo Molina
Dirección IPTEL

www.iptel.net.mx

T : 55 55 55202444
M : 04455 10045822

Piensa en Bits SA de CV



Información anexa:




CONFIDENCIALIDAD DE INFORMACION

Este mensaje tiene carácter confidencial. Si usted no es el destinarario de 
este mensaje, le suplicamos se lo notifique al remitente mediante un correo 
electrónico y que borre el presente mensaje y sus anexos de su computadora sin 
retener una copia de los mismos. Queda estrictamente prohibido copiar este 
mensaje o hacer usode el para cualquier propósito o divulgar su en forma 
parcial o total su contenido. Gracias.


NON-DISCLOSURE OF INFORMATION

This email is strictly confidential and may also be privileged. If you are not 
the intended recipient please immediately advise the sender by replying to this 
e-mail and then deleting the message and its attachments from your computer 
without keeping a copy. It is strictly forbidden to copy it or use it for any 
purpose or disclose its contents to any third party. Thank you.






On Dec 8, 2012, at 6:59 PM, Lizeth Norman  wrote:

> Hi all!
> 
> Having finally moved and having been able to sort the stuff, there's
> some goodies for sale:
> Do have a few more items that would be of interest to the time and
> frequency folks, but here's the first two.
> 
> I have two Shera based gpsdo kits available. One board is built,
> tested and working.  The other is a complete kit of all parts and the
> A+A engineering pc board.
> 
> Included in each kit:
> 1 HP 10811a-60111
> 1 sma unknown 5v active patch gps L1 antenna
> 1 HP 58535a gps active splitter
> 1 Motorola M12+T gps receiver
> 
> The built kit gets an HP rack mount enclosure with a LCD display of
> the efc voltage. Feel free to use the boards inside, but as you will
> see, it was my first attempt at a partial kit where YOU the builder
> must buy to spec and then integrate according to a plan. Looks like
> hell. Works ok, though..
> 
> Would like to trade for equipment. Particularly microwave attenuators,
> mixers, preamps. Will trade + cash for a signal generator good to 18
> GHz.
> 
> Kit one (built board with enclosure and power supply. Ask for photos.)
> $250
> Kit two
> $210
> 
> All reasonable offers considered.
> 
> ___
> 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] Help with HAMEG HM8123

[K. Szeker]

Hi all,

Hello Dani, sorry, but you cannot find some documentations, with
schematics, over more newer Hameg equipments, in all cases not from Hameg!
:-(  Its practically a illusion & a real problem...
K.

2011/12/8 Daniel Mendes 

> Maybe i´m blind but at the Hameg site I can only find one PDF with the
> manual in 4 different languages together (english, spanish, german and
> french) but no schematics...
>
> Daniel
>
>
> Date: Wed, 7 Dec 2011 19:52:58 -
> From: "Alan Melia"
> >
> To: "Discussion of precise time and frequency measurement"
>
> Subject: Re: [time-nuts] Help with HAMEG HM8123
> Message-ID:<002301ccb519$**dc57c050$4001a8c0@lark>
> Content-Type: text/plain;   charset="iso-8859-1"
>
>
> Get a manual from the Hameg site
> http://www.hameg.com/manuals.**0.html?&no_cache=1&L=1%3E<http://www.hameg.com/manuals.0.html?&no_cache=1&L=1%3E>
> You may find that the English versions do no always contain the circuit
> diagrams .in this case download the German language version which will
> have the circuits at the back
>
> Alan G3NYK
>
> - Original Message -
> From: "Daniel Mendes"
> To:
> Sent: Wednesday, December 07, 2011 6:43 PM
> Subject: [time-nuts] Help with HAMEG HM8123
>
>
> Hi, i?ve got a hameg HM8123 that came without any front panel button
>
> working. Opening it i found that both flat cables from the panel to the
> mainboard got loose. I figured where to plug the fist one (because it
> could only plug in one connector...  it was a tight fit) but the other
> can be plugged in 2 different receptacles at the mainboard. Does someone
> have a repair manual or internal photos of one of these?
>
>
> __**_
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/**
> mailman/listinfo/time-nuts<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] Help with HAMEG HM8123

[Alan Melia]

Hi Danial I admit I have only downloaded scope manuals but for many of those
the schematics are only at the end of the German language version. They are
usually quite helpful so it might be worth contacting them.

Alan
G3NYK

- Original Message - 
From: "Daniel Mendes" 
To: 
Sent: Thursday, December 08, 2011 11:15 AM
Subject: Re: [time-nuts] Help with HAMEG HM8123


Maybe i´m blind but at the Hameg site I can only find one PDF with the
manual in 4 different languages together (english, spanish, german and
french) but no schematics...

Daniel


Date: Wed, 7 Dec 2011 19:52:58 -
From: "Alan Melia"
To: "Discussion of precise time and frequency measurement"

Subject: Re: [time-nuts] Help with HAMEG HM8123
Message-ID:<002301ccb519$dc57c050$4001a8c0@lark>
Content-Type: text/plain; charset="iso-8859-1"

Get a manual from the Hameg site
http://www.hameg.com/manuals.0.html?&no_cache=1&L=1%3E
You may find that the English versions do no always contain the circuit
diagrams .in this case download the German language version which will
have the circuits at the back

Alan G3NYK

- Original Message -
From: "Daniel Mendes"
To:
Sent: Wednesday, December 07, 2011 6:43 PM
Subject: [time-nuts] Help with HAMEG HM8123


Hi, i?ve got a hameg HM8123 that came without any front panel button
working. Opening it i found that both flat cables from the panel to the
mainboard got loose. I figured where to plug the fist one (because it
could only plug in one connector...  it was a tight fit) but the other
can be plugged in 2 different receptacles at the mainboard. Does someone
have a repair manual or internal photos of one of these?


___
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] Help with HAMEG HM8123

[Daniel Mendes]

Maybe i´m blind but at the Hameg site I can only find one PDF with the manual 
in 4 different languages together (english, spanish, german and french) but no 
schematics...

Daniel


Date: Wed, 7 Dec 2011 19:52:58 -
From: "Alan Melia"
To: "Discussion of precise time and frequency measurement"
    
Subject: Re: [time-nuts] Help with HAMEG HM8123
Message-ID:<002301ccb519$dc57c050$4001a8c0@lark>
Content-Type: text/plain;   charset="iso-8859-1"

Get a manual from the Hameg site
http://www.hameg.com/manuals.0.html?&no_cache=1&L=1%3E
You may find that the English versions do no always contain the circuit
diagrams .in this case download the German language version which will
have the circuits at the back

Alan G3NYK

- Original Message -
From: "Daniel Mendes"
To:
Sent: Wednesday, December 07, 2011 6:43 PM
Subject: [time-nuts] Help with HAMEG HM8123


Hi, i?ve got a hameg HM8123 that came without any front panel button
working. Opening it i found that both flat cables from the panel to the
mainboard got loose. I figured where to plug the fist one (because it
could only plug in one connector...  it was a tight fit) but the other
can be plugged in 2 different receptacles at the mainboard. Does someone
have a repair manual or internal photos of one of these?


___
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] Help with HAMEG HM8123

[Alan Melia]

Get a manual from the Hameg site
http://www.hameg.com/manuals.0.html?&no_cache=1&L=1%3E
You may find that the English versions do no always contain the circuit
diagrams .in this case download the German language version which will
have the circuits at the back

Alan G3NYK

- Original Message - 
From: "Daniel Mendes" 
To: 
Sent: Wednesday, December 07, 2011 6:43 PM
Subject: [time-nuts] Help with HAMEG HM8123


Hi, i´ve got a hameg HM8123 that came without any front panel button
working. Opening it i found that both flat cables from the panel to the
mainboard got loose. I figured where to plug the fist one (because it
could only plug in one connector...  it was a tight fit) but the other
can be plugged in 2 different receptacles at the mainboard. Does someone
have a repair manual or internal photos of one of these?

Thank you.

An aspiring time nut,

Daniel

___
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] Help with TCXO

[Azelio Boriani]

Yes, I remember that thread.
Anyway, Hal, are you suggesting to use the 3.2GHz clock to crank up the
counting speed? OK, strange, but can be a way...

On Wed, Dec 7, 2011 at 1:23 AM, Bob Camp  wrote:

> Hi
>
> There was a point in time where a general purpose board could have been
> done on a group basis. The discussion of that offended some on the list.
> That prevented it from being done in a timely manner. The funds that would
> have gone to the project went to a closed design that is not available.
>
> Sorry about that.
>
> Bob
>
>
>
> On Dec 6, 2011, at 5:11 PM, Attila Kinali  wrote:
>
> > On Tue, 6 Dec 2011 17:06:43 -0500
> > "Bob Camp"  wrote:
> >
> >> It's the "wave union" one that the Fermi labs papers talk about. We
> started
> >> talking about a group design on one a while back. Ultimately it got
> taken
> >> off list 
> >
> > What is the status of that?
> > I would try to help if i didnt know that i have way too
> > little time currently :-(
> >
> >Attila Kinali
> > --
> > Why does it take years to find the answers to
> > the questions one should have asked long ago?
> >
> > ___
> > 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.

Re: [time-nuts] Help with TCXO

[Bob Camp]

Hi

There was a point in time where a general purpose board could have been done on 
a group basis. The discussion of that offended some on the list. That prevented 
it from being done in a timely manner. The funds that would have gone to the 
project went to a closed design that is not available.

Sorry about that.

Bob



On Dec 6, 2011, at 5:11 PM, Attila Kinali  wrote:

> On Tue, 6 Dec 2011 17:06:43 -0500
> "Bob Camp"  wrote:
> 
>> It's the "wave union" one that the Fermi labs papers talk about. We started
>> talking about a group design on one a while back. Ultimately it got taken
>> off list 
> 
> What is the status of that?
> I would try to help if i didnt know that i have way too
> little time currently :-(
> 
>Attila Kinali
> -- 
> Why does it take years to find the answers to
> the questions one should have asked long ago?
> 
> ___
> 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] Help with TCXO

[Hal Murray]

> At the moment I'm in the 2.5nS resolution range and successfully made a
> GPSDO that my company uses for the DVB-T synchronization needs. Next step
> will be to use a Maxim/Dallas delay line to hardware correct the PPS by the
> negative sawtooth and try to improve the TDC resolution. Maybe a small
> Virtex will replace the Spartan...

Check out the high speed serial interfaces.  I think they have a mode where 
you can use them as a raw serial to parallel interface: the receive PLL is 
locked to the reference clock rather than the data stream.  A Spartan 6 blurb 
says 3.2 gigabits which is 312.5 ps.

I think that can be made to work without fancy placement or calibration.  (I 
haven't tried it.)


-- 
These are my opinions, not necessarily my employer's.  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] Help with TCXO

[Azelio Boriani]

I have read the two papers about the wave union TDC but still wonder if
anything reasonable could be done without:
1) place every single gate by hand on the target silicon
2) heavy postprocess the data to obtain results
Something like: I have a Spartan3, the WebTool suite from Xilinx and, yes,
I have to tinker with the compiler configuration. Finally the data is read
by a C8051 (an MCS51-like 8 bit microprocessor). At the moment I'm in the
2.5nS resolution range and successfully made a GPSDO that my company uses
for the DVB-T synchronization needs. Next step will be to use a
Maxim/Dallas delay line to hardware correct the PPS by the negative
sawtooth and try to improve the TDC resolution. Maybe a small Virtex will
replace the Spartan...

On Tue, Dec 6, 2011 at 11:11 PM, Attila Kinali  wrote:

> On Tue, 6 Dec 2011 17:06:43 -0500
> "Bob Camp"  wrote:
>
> > It's the "wave union" one that the Fermi labs papers talk about. We
> started
> > talking about a group design on one a while back. Ultimately it got taken
> > off list 
>
> What is the status of that?
> I would try to help if i didnt know that i have way too
> little time currently :-(
>
>Attila Kinali
> --
> Why does it take years to find the answers to
> the questions one should have asked long ago?
>
> ___
> 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] Help with TCXO

[Attila Kinali]

On Tue, 6 Dec 2011 17:06:43 -0500
"Bob Camp"  wrote:

> It's the "wave union" one that the Fermi labs papers talk about. We started
> talking about a group design on one a while back. Ultimately it got taken
> off list 

What is the status of that?
I would try to help if i didnt know that i have way too
little time currently :-(

Attila Kinali
-- 
Why does it take years to find the answers to
the questions one should have asked long ago?

___
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] Help with TCXO

[Bob Camp]

Hi

The gotcha with the papers is the "RMS" measure of accuracy. A more
conventional counter would call 30 ps RMS, 90 ps accuracy...

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Attila Kinali
Sent: Tuesday, December 06, 2011 5:05 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Help with TCXO

On Tue, 6 Dec 2011 21:47:24 +0100
Azelio Boriani  wrote:

> I have read about the two main delay line techniques: the vernier delay
> line and the tapped delay line. These require a sort of on-the-fly
> calibration virtually for every sample you get because of the temperature
> and power supply dependency of the delay itself. Presently my
> time-to-digital converter has a 2.5nS resolution made only by counters,
> based on a 100MHz clock and on the capabilities of the Digital Clock
> Manager in the Spartan3 XC3S50 FPGA. In your opinion what resolution can I
> get from a Spartan3 (without any calibration) using delay lines? I have to
> learn how to manage delay lines and how to direct their placement for
> time-nut purposes.

Google for [1]. Wu et al reports that he was able to get to <60ps RMS
uncalibrated on a Cyclone II chip (which is quite old and slow).
Calibrated it was in the range of 10-25ps RMS (depending on the
exact architecture).

In [2] Qi et al "verify" the result from [1] and get to 20ps RMS with
30ps RMS worst case. Unfortunately, they don't write which FPGA they used.
(At least i couldnt find it just now)

Attila Kinali

[1] The lO-ps Wave Union TDC: Improving FPGA TDC Resolution
beyond Its Cell Delay, Jinyuan Wu and Zonghan Shi, 
2008 IEEE Nuclear Science Symposium Conference 

[2] A 20ps Resolution Wave Union FPGA TDC with On-Chip Real
Time Correction, Ji Qi, Zhi Deng, Hui Gong, Yinong Liu



-- 
Why does it take years to find the answers to
the questions one should have asked long ago?

___
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] Help with TCXO

[Bob Camp]

Hi

It's the "wave union" one that the Fermi labs papers talk about. We started
talking about a group design on one a while back. Ultimately it got taken
off list 

Bob 

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Attila Kinali
Sent: Tuesday, December 06, 2011 4:52 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Help with TCXO

On Tue, 6 Dec 2011 16:43:37 -0500
"Bob Camp"  wrote:

> With reasonable calibration, it looks like you can get below 200 ps. You
> will need to boost the clock up to ~ 400 MHz with one of the internal
PLL's
> to get it to "fit" in a reasonable sized device.

With which design would that be?

Attila Kinali
-- 
Why does it take years to find the answers to
the questions one should have asked long ago?

___
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] Help with TCXO

[Attila Kinali]

On Tue, 6 Dec 2011 21:47:24 +0100
Azelio Boriani  wrote:

> I have read about the two main delay line techniques: the vernier delay
> line and the tapped delay line. These require a sort of on-the-fly
> calibration virtually for every sample you get because of the temperature
> and power supply dependency of the delay itself. Presently my
> time-to-digital converter has a 2.5nS resolution made only by counters,
> based on a 100MHz clock and on the capabilities of the Digital Clock
> Manager in the Spartan3 XC3S50 FPGA. In your opinion what resolution can I
> get from a Spartan3 (without any calibration) using delay lines? I have to
> learn how to manage delay lines and how to direct their placement for
> time-nut purposes.

Google for [1]. Wu et al reports that he was able to get to <60ps RMS
uncalibrated on a Cyclone II chip (which is quite old and slow).
Calibrated it was in the range of 10-25ps RMS (depending on the
exact architecture).

In [2] Qi et al "verify" the result from [1] and get to 20ps RMS with
30ps RMS worst case. Unfortunately, they don't write which FPGA they used.
(At least i couldnt find it just now)

Attila Kinali

[1] The lO-ps Wave Union TDC: Improving FPGA TDC Resolution
beyond Its Cell Delay, Jinyuan Wu and Zonghan Shi, 
2008 IEEE Nuclear Science Symposium Conference 

[2] A 20ps Resolution Wave Union FPGA TDC with On-Chip Real
Time Correction, Ji Qi, Zhi Deng, Hui Gong, Yinong Liu



-- 
Why does it take years to find the answers to
the questions one should have asked long ago?

___
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] Help with TCXO

[Attila Kinali]

On Tue, 6 Dec 2011 16:43:37 -0500
"Bob Camp"  wrote:

> With reasonable calibration, it looks like you can get below 200 ps. You
> will need to boost the clock up to ~ 400 MHz with one of the internal PLL's
> to get it to "fit" in a reasonable sized device.

With which design would that be?

Attila Kinali
-- 
Why does it take years to find the answers to
the questions one should have asked long ago?

___
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] Help with TCXO

[Bob Camp]

Hi

With reasonable calibration, it looks like you can get below 200 ps. You
will need to boost the clock up to ~ 400 MHz with one of the internal PLL's
to get it to "fit" in a reasonable sized device.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Azelio Boriani
Sent: Tuesday, December 06, 2011 3:47 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Help with TCXO

I have read about the two main delay line techniques: the vernier delay
line and the tapped delay line. These require a sort of on-the-fly
calibration virtually for every sample you get because of the temperature
and power supply dependency of the delay itself. Presently my
time-to-digital converter has a 2.5nS resolution made only by counters,
based on a 100MHz clock and on the capabilities of the Digital Clock
Manager in the Spartan3 XC3S50 FPGA. In your opinion what resolution can I
get from a Spartan3 (without any calibration) using delay lines? I have to
learn how to manage delay lines and how to direct their placement for
time-nut purposes.

On Tue, Dec 6, 2011 at 6:11 PM, Bob Camp  wrote:

> Hi
>
> Actually you can get to sub ns resolution with a delay line in a modern
> cheap FPGA. Weather you can get to sub 50 ps across the full window is
open
> to a bit of debate.
>
> The amount of hassle goes up as your resolution gets better. Without
heroic
> efforts, sub 200 ps is quite possible.
>
> Bob
>
> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
> Behalf Of Azelio Boriani
> Sent: Tuesday, December 06, 2011 10:25 AM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Help with TCXO
>
> Yes, with an analog interpolator you can. Without an analog interpolator
> and without using the vernier delay line (and other tricks like that), the
> FPGA can only get to nS resolution so far (for example, in a Spartan3 or
> equivalent). To implement a vernier delay line you need also to control
the
> logic translator and the technology fitter and know by heart your logic
> chip. Maybe one day they pop up with a time-nut FPGA compiler that is
aware
> of intentionally-placed delay lines and stuff like this.
>
> On Tue, Dec 6, 2011 at 3:43 PM, Attila Kinali  wrote:
>
> > On Tue, 29 Nov 2011 11:23:26 +1100
> > Michael Malloy  wrote:
> >
> > > let me know if you want schematics for my other designs
> >
> > I'm always interested in learning from others.
> > So, if it would be not too much a hassle, i'd greatly
> > appreciate if you could publish yous schematics/designs.
> > Especially, if you can write a few words on what your
> > design decisions were.
> >
> >Attila Kinali
> > --
> > The trouble with you, Shev, is you don't say anything until you've saved
> > up a whole truckload of damned heavy brick arguments and then you dump
> > them all out and never look at the bleeding body mangled beneath the
heap
> >-- Tirin, The Dispossessed, U. Le Guin
> >
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
> >
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


___
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] Help with TCXO

[Azelio Boriani]

I have read about the two main delay line techniques: the vernier delay
line and the tapped delay line. These require a sort of on-the-fly
calibration virtually for every sample you get because of the temperature
and power supply dependency of the delay itself. Presently my
time-to-digital converter has a 2.5nS resolution made only by counters,
based on a 100MHz clock and on the capabilities of the Digital Clock
Manager in the Spartan3 XC3S50 FPGA. In your opinion what resolution can I
get from a Spartan3 (without any calibration) using delay lines? I have to
learn how to manage delay lines and how to direct their placement for
time-nut purposes.

On Tue, Dec 6, 2011 at 6:11 PM, Bob Camp  wrote:

> Hi
>
> Actually you can get to sub ns resolution with a delay line in a modern
> cheap FPGA. Weather you can get to sub 50 ps across the full window is open
> to a bit of debate.
>
> The amount of hassle goes up as your resolution gets better. Without heroic
> efforts, sub 200 ps is quite possible.
>
> Bob
>
> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
> Behalf Of Azelio Boriani
> Sent: Tuesday, December 06, 2011 10:25 AM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Help with TCXO
>
> Yes, with an analog interpolator you can. Without an analog interpolator
> and without using the vernier delay line (and other tricks like that), the
> FPGA can only get to nS resolution so far (for example, in a Spartan3 or
> equivalent). To implement a vernier delay line you need also to control the
> logic translator and the technology fitter and know by heart your logic
> chip. Maybe one day they pop up with a time-nut FPGA compiler that is aware
> of intentionally-placed delay lines and stuff like this.
>
> On Tue, Dec 6, 2011 at 3:43 PM, Attila Kinali  wrote:
>
> > On Tue, 29 Nov 2011 11:23:26 +1100
> > Michael Malloy  wrote:
> >
> > > let me know if you want schematics for my other designs
> >
> > I'm always interested in learning from others.
> > So, if it would be not too much a hassle, i'd greatly
> > appreciate if you could publish yous schematics/designs.
> > Especially, if you can write a few words on what your
> > design decisions were.
> >
> >Attila Kinali
> > --
> > The trouble with you, Shev, is you don't say anything until you've saved
> > up a whole truckload of damned heavy brick arguments and then you dump
> > them all out and never look at the bleeding body mangled beneath the heap
> >-- Tirin, The Dispossessed, U. Le Guin
> >
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
> >
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Help with TCXO

[Bob Camp]

Hi

Actually you can get to sub ns resolution with a delay line in a modern
cheap FPGA. Weather you can get to sub 50 ps across the full window is open
to a bit of debate. 

The amount of hassle goes up as your resolution gets better. Without heroic
efforts, sub 200 ps is quite possible. 

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Azelio Boriani
Sent: Tuesday, December 06, 2011 10:25 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Help with TCXO

Yes, with an analog interpolator you can. Without an analog interpolator
and without using the vernier delay line (and other tricks like that), the
FPGA can only get to nS resolution so far (for example, in a Spartan3 or
equivalent). To implement a vernier delay line you need also to control the
logic translator and the technology fitter and know by heart your logic
chip. Maybe one day they pop up with a time-nut FPGA compiler that is aware
of intentionally-placed delay lines and stuff like this.

On Tue, Dec 6, 2011 at 3:43 PM, Attila Kinali  wrote:

> On Tue, 29 Nov 2011 11:23:26 +1100
> Michael Malloy  wrote:
>
> > let me know if you want schematics for my other designs
>
> I'm always interested in learning from others.
> So, if it would be not too much a hassle, i'd greatly
> appreciate if you could publish yous schematics/designs.
> Especially, if you can write a few words on what your
> design decisions were.
>
>Attila Kinali
> --
> The trouble with you, Shev, is you don't say anything until you've saved
> up a whole truckload of damned heavy brick arguments and then you dump
> them all out and never look at the bleeding body mangled beneath the heap
>-- Tirin, The Dispossessed, U. Le Guin
>
> ___
> 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.

Re: [time-nuts] Help with TCXO

[Azelio Boriani]

Yes, with an analog interpolator you can. Without an analog interpolator
and without using the vernier delay line (and other tricks like that), the
FPGA can only get to nS resolution so far (for example, in a Spartan3 or
equivalent). To implement a vernier delay line you need also to control the
logic translator and the technology fitter and know by heart your logic
chip. Maybe one day they pop up with a time-nut FPGA compiler that is aware
of intentionally-placed delay lines and stuff like this.

On Tue, Dec 6, 2011 at 3:43 PM, Attila Kinali  wrote:

> On Tue, 29 Nov 2011 11:23:26 +1100
> Michael Malloy  wrote:
>
> > let me know if you want schematics for my other designs
>
> I'm always interested in learning from others.
> So, if it would be not too much a hassle, i'd greatly
> appreciate if you could publish yous schematics/designs.
> Especially, if you can write a few words on what your
> design decisions were.
>
>Attila Kinali
> --
> The trouble with you, Shev, is you don't say anything until you've saved
> up a whole truckload of damned heavy brick arguments and then you dump
> them all out and never look at the bleeding body mangled beneath the heap
>-- Tirin, The Dispossessed, U. Le Guin
>
> ___
> 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] Help with TCXO

[Attila Kinali]

On Tue, 29 Nov 2011 11:23:26 +1100
Michael Malloy  wrote:

> let me know if you want schematics for my other designs

I'm always interested in learning from others.
So, if it would be not too much a hassle, i'd greatly
appreciate if you could publish yous schematics/designs.
Especially, if you can write a few words on what your
design decisions were.

Attila Kinali
-- 
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin

___
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] Help with TCXO

[Attila Kinali]

On Tue, 29 Nov 2011 16:09:34 +0100
Azelio Boriani  wrote:

> FPGA time interval counter? With an analog interpolator? No? Then, at most,
> you will get a nS resolution. I have a 2.5nS resolution TIC with 100MHz
> clock using four phases from the Xilinx DCM in a Spartan3.

I'm quite sure you can do better than ns resolution with an analog
interpolator. Heck, even the PICTIC does something arount 200ps 
if i'm not mistaken. And the PICTIC has a quite simple design too.

Attila Kinali
-- 
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin

___
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] Help with TCXO

[Azelio Boriani]

FPGA time interval counter? With an analog interpolator? No? Then, at most,
you will get a nS resolution. I have a 2.5nS resolution TIC with 100MHz
clock using four phases from the Xilinx DCM in a Spartan3.

On Tue, Nov 29, 2011 at 1:23 AM, Michael Malloy  wrote:

> Ok great thank you very much I will go get some 74HC14 today if possible
> and replace them, I will also upload a schematic, and a smaller picture
>
> i tried running on a bread board with a 4000 CMOS CD40106
> the output looked like a square wave through a diode to LP filter not
> good, like spikes
> not what I want I suspect something to do with the 4000 CMOS circuitry??
> 4000 CMOS is good because you can do cool stuff with it as it will
> work up to 15 volts or maybe more
> great for hybrid analog and digital designs, especially for audio
> applications, you can use 4000 CMOS
> to build very good VCO, but low frequencies.. if you would like a
> circuit for that
> I can give you this also if interested? I have about 6 different
> design for VCO using hybrid design like this?
>
>
> off topic I am also building a VHDL/FPGA time interval counter, I will
> be happy to share the code and the schematics if your interested
> the FPGA is great fast, and I can do all the pre scaling and down
> converting within the hardware. concurrently as you know
> downside FPGA are expensive for what they are.
>
> the TI logic design guidelines said specifically that 4000 cmos is
> good for low frequencies sub 1MHZ
> for anything above different logic families.
>
> I will get back to you all later with schematic and pictures
> thanks again for all your help.
>
> let me know if you want schematics for my other designs
>
> also forgive my ignorance and don't judge me but what is a "line-receiver"
> never heard of this is this jargon, I am australian, or is this just
> my ignorance
> remember I am a newbie to time and frequency but I am fascinated
>
>
> On Mon, Nov 28, 2011 at 10:23 PM, ehydra  wrote:
> > A 50K picture should fit the problem.
> >
> > I successfully use 4000 series for amplifying a 5MHz PSK signal. The
> HEF4x
> > is a little faster than HCFx.
> >
> > Or use a line-receiver if the oscillators is not buffered internal.
> >
> > - Henry
> >
> >
> > Michael Malloy schrieb:
> >>
> >> its a shame i cannot post the picture i took is there any way to be
> >> able to send my oscilloscope picture its 800k thats the problem
> >
> > --
> > ehydra.dyndns.info
> >
> > ___
> > 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.
> >
>
>
>
> --
> #include 
> /*  */
> Michael
> /*How crazy does it get on the moon, when theres a full Earth?*/
>
> ___
> 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] Help with TCXO

[Michael Malloy]

Ok great thank you very much I will go get some 74HC14 today if possible
and replace them, I will also upload a schematic, and a smaller picture

i tried running on a bread board with a 4000 CMOS CD40106
the output looked like a square wave through a diode to LP filter not
good, like spikes
not what I want I suspect something to do with the 4000 CMOS circuitry??
4000 CMOS is good because you can do cool stuff with it as it will
work up to 15 volts or maybe more
great for hybrid analog and digital designs, especially for audio
applications, you can use 4000 CMOS
to build very good VCO, but low frequencies.. if you would like a
circuit for that
I can give you this also if interested? I have about 6 different
design for VCO using hybrid design like this?


off topic I am also building a VHDL/FPGA time interval counter, I will
be happy to share the code and the schematics if your interested
the FPGA is great fast, and I can do all the pre scaling and down
converting within the hardware. concurrently as you know
downside FPGA are expensive for what they are.

the TI logic design guidelines said specifically that 4000 cmos is
good for low frequencies sub 1MHZ
for anything above different logic families.

I will get back to you all later with schematic and pictures
thanks again for all your help.

let me know if you want schematics for my other designs

also forgive my ignorance and don't judge me but what is a "line-receiver"
never heard of this is this jargon, I am australian, or is this just
my ignorance
remember I am a newbie to time and frequency but I am fascinated


On Mon, Nov 28, 2011 at 10:23 PM, ehydra  wrote:
> A 50K picture should fit the problem.
>
> I successfully use 4000 series for amplifying a 5MHz PSK signal. The HEF4x
> is a little faster than HCFx.
>
> Or use a line-receiver if the oscillators is not buffered internal.
>
> - Henry
>
>
> Michael Malloy schrieb:
>>
>> its a shame i cannot post the picture i took is there any way to be
>> able to send my oscilloscope picture its 800k thats the problem
>
> --
> ehydra.dyndns.info
>
> ___
> 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.
>



-- 
#include 
/*  */
Michael
/*How crazy does it get on the moon, when theres a full Earth?*/

___
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] Help with TCXO

[paul swed]

Ok to answer part of the original question.
Indeed I have see the "clipped sine wave" as you stated and it has no
negative component.
Numbers of vectrons and other xtal oscilators look like that. No negative
supply nor transformers so thats what you tend to get. Its normal. But as
you say feed into a circuit to clean it up and all works just fine.
Regards
Paul.

On Mon, Nov 28, 2011 at 8:42 AM, Attila Kinali  wrote:

> On Mon, 28 Nov 2011 19:28:37 +1100
> Michael Malloy  wrote:
>
> > I was pretty sure that the 4000 CMOS range was only really good sub
> > 1Mhz I am wrong here? please correct me
> > thats why I chose the 74HC series as its high speed CMOS??
>
> High speed is a very relative term here. It's high speed compared
> to the 4000 series, it's is not high speed in modern terms.
> If you want speed, then look for the AC* or LV* families.
> Like always: check the data sheets of the parts to see whether
> they fit your need. NXP and fairchild have general guides on
> logic families and their characteristics online.
>
>Attila Kinali
> --
> The trouble with you, Shev, is you don't say anything until you've saved
> up a whole truckload of damned heavy brick arguments and then you dump
> them all out and never look at the bleeding body mangled beneath the heap
>-- Tirin, The Dispossessed, U. Le Guin
>
> ___
> 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] Help with TCXO

[Attila Kinali]

On Mon, 28 Nov 2011 19:28:37 +1100
Michael Malloy  wrote:

> I was pretty sure that the 4000 CMOS range was only really good sub
> 1Mhz I am wrong here? please correct me
> thats why I chose the 74HC series as its high speed CMOS??

High speed is a very relative term here. It's high speed compared
to the 4000 series, it's is not high speed in modern terms.
If you want speed, then look for the AC* or LV* families.
Like always: check the data sheets of the parts to see whether
they fit your need. NXP and fairchild have general guides on
logic families and their characteristics online.

Attila Kinali
-- 
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin

___
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] Help with TCXO

[Attila Kinali]

On Mon, 28 Nov 2011 19:29:41 +1100
Michael Malloy  wrote:

> On Mon, Nov 28, 2011 at 7:14 PM, Michael Malloy  wrote:
> > yeah it is squaring up, but not great I have already designed the
> > circuit boards, hmm
> > maybe if i replace the 74HC04 with a 74HC14 (schmitt trigger input)
> > which I do not have
> > I did make a surface mount single gate schmitt trig after the 74HC04
> > as I knew that

You should but the HC14 infront of the HC04, not after (or simply replace it)
The HC14 is used to "clean" the output of the TCXO and make it
logic compatible. Its hysteresis will ensure that you don't have
any oscillation or other adverse efects during the "slow" rise
and fall times of the TCXO output.

> > this squares things up much better, however after the 74HC04 it goes to
> > a 74HC4040 divide by 12 counter and from that input it goes to another
> > 74HC04 into the processor
> > I am worried that the fact that the counter and the processor are 90
> > degrees out of phase clock cycle
> > if I put the single gate schmitt trig in it will bring both in phase
> > I may need to make software adjustments if this happens??

I don't see how where a phase shift of 90° occurs. If, then i'd be 180°.
Unless i misunderstood you. A schematic would be really helpfull here.


> > let me see if the 74HC14 is pin for pin compatible with 74HC04 maybe I
> > will replace with this.
> > but I do not think I have any here

They are pin compatible. The HC14 is the same as the HC04 but has
a schmitt trigger input. 


Attila Kinali
-- 
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin

___
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] Help with TCXO

[ehydra]

Sorry. Read:
"Or use a line-receiver if the oscillators is buffered internal."

- Henry


Michael Malloy schrieb:

its a shame i cannot post the picture i took is there any way to be
able to send my oscilloscope picture its 800k thats the problem


--
ehydra.dyndns.info

___
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] Help with TCXO

[ehydra]

A 50K picture should fit the problem.

I successfully use 4000 series for amplifying a 5MHz PSK signal. The 
HEF4x is a little faster than HCFx.


Or use a line-receiver if the oscillators is not buffered internal.

- Henry


Michael Malloy schrieb:

its a shame i cannot post the picture i took is there any way to be
able to send my oscilloscope picture its 800k thats the problem


--
ehydra.dyndns.info

___
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] Help with TCXO

[Michael Malloy]

its a shame i cannot post the picture i took is there any way to be
able to send my oscilloscope picture its 800k thats the problem

On Mon, Nov 28, 2011 at 7:29 PM, Michael Malloy  wrote:
> On Mon, Nov 28, 2011 at 7:14 PM, Michael Malloy  wrote:
>> yeah it is squaring up, but not great I have already designed the
>> circuit boards, hmm
>> maybe if i replace the 74HC04 with a 74HC14 (schmitt trigger input)
>> which I do not have
>> I did make a surface mount single gate schmitt trig after the 74HC04
>> as I knew that
>> this squares things up much better, however after the 74HC04 it goes to
>> a 74HC4040 divide by 12 counter and from that input it goes to another
>> 74HC04 into the processor
>> I am worried that the fact that the counter and the processor are 90
>> degrees out of phase clock cycle
>> if I put the single gate schmitt trig in it will bring both in phase
>> I may need to make software adjustments if this happens??
>>
>> and no I did not test the unit without any load, I had a hombrew TCXO
>> in the original
>> circuit but its performance was only +- 10PPM and caused problems with the 
>> codec
>> its a very sensitive design to jitter, TXCO was cheapest option but if
>> I had the money would have put an OCXO
>> in but they are not cheap in small runs, I am getting off track
>> I will take a picture of my oscilloscope and post it
>>
>> let me see if the 74HC14 is pin for pin compatible with 74HC04 maybe I
>> will replace with this.
>> but I do not think I have any here
>>
>> On Mon, Nov 28, 2011 at 6:36 PM, Attila Kinali  wrote:
>>> On Mon, 28 Nov 2011 16:15:37 +1100
>>> Michael Malloy  wrote:
>>>
 Hi all I ordered a 8.192MHZ TCXO 1.0PPM
 Now it was supposed to have a clipped sine wave output? however it
 looks more like a saw tooth, I assumed a clipped sine would be a sine
 wave with the peaks clipped, I am running this through
 a 150pF cap and then using a inverter amplifier i.e. 74HC04 with a 1M
 resistor from input to output.

 am I over loading or loading down the the oscillator, or should I be
 changing the buffer capacitor?
 I mean the circuit is working but its not 45/55 duty cycle
 the out put looks like the first 0 -90 degrees of a sine wave then
 drops to zero stays there for about 20% of the duty cycle then ramps
 back up?
>>>
>>> Do you measure the TCXO raw, w/o any circuitry attached?
>>> Because this sounds rather like that the 74ZHC04 is messing
>>> with the signal. Maybe the 1M resistor isnt really 1M?
>>>
>>> Other than that, i would feed the output directly to
>>> a 74HC14 (schmitt trigger input) to square it. If you
>>> want to have precise or adjustable duty cycle, you can also
>>> use a comparator (but make sure to include enough hysteresis,
>>> otherwise the comparator might oscillate)
>>>
>>>
>>>                        Attila Kinali
>>>
>>> --
>>> Why does it take years to find the answers to
>>> the questions one should have asked long ago?
>>>
>>> ___
>>> 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.
>>>
>>
>>
>>
>> --
>> #include 
>> /*  */
>> Michael
>> /*How crazy does it get on the moon, when theres a full Earth?*/
>>
>
>
>
> --
> #include 
> /*  */
> Michael
> /*How crazy does it get on the moon, when theres a full Earth?*/
>



-- 
#include 
/*  */
Michael
/*How crazy does it get on the moon, when theres a full Earth?*/

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