Re: [time-nuts] Oscilloquartz 8600-3 Disassembly pictures...

[Tom Van Baak]

Ulf Kylenfall photos:
http://leapsecond.com/museum/osa8600/
http://leapsecond.com/museum/osa8600/view.htm


Ed Palmer text and photos:
http://leapsecond.com/museum/osa8601/
http://leapsecond.com/museum/osa8601/view.htm


___
time-nuts mailing 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] Oscilloquartz 8600-3 Disassembly pictures...

[Jean-Louis Oneto]

Hello,

Once upon a time, I uploaded to Didier Juges' site the manual (English & 
French) for my Oscilloquartz 2200 which include a OCXO 8601 :


http://www.ko4bb.com/getsimple/index.php?id=download=02_GPS_Timing/Oscilloquartz_SA_2200_2205_Quartz_Frequency_Standard_Type_2200_and_Clock__Option_2205_Operator_Manual.pdf

Even if the internals of the 8601 are not detailled, I hope it will be 
of any help.


Best regards from France,
Jean-Louis

On 14/12/2017 07:02, Ulf Kylenfall via time-nuts wrote:
  
Tried to mail the pictures to Magnus. The mail bounced back.

Ole Petter Ronningen was kind to also offer space for themand they can be found 
at:

www (dot) efos3 (dot) com/osa8600-3

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



--
Jean-Louis Oneto
email: jl.on...@free.fr

___
time-nuts mailing 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] Oscilloquartz 8600-3 Disassembly pictures...

[Didier Juges]

You are always welcome to upload time-nuts related material to my manual
site www.ko4bb.com

Didier KO4BB

On Dec 14, 2017 1:03 AM, "Ulf Kylenfall via time-nuts" 
wrote:

>
> Tried to mail the pictures to Magnus. The mail bounced back.
> Ole Petter Ronningen was kind to also offer space for themand they can be
> found at:
>
> www (dot) efos3 (dot) com/osa8600-3
>
> 73
> Ulf Kylenfall - SM6GXV
> ___
> time-nuts mailing 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] Lady Heather newb questions

[W7SLS]

Mark,

Thanks.  I think I got it:  

> Tcor, UNC

Lady Heather happily posts cryptic messages from the device!

> TFOM, FFOM

Yup, I found them in the Z3801A manual.

Appreciate the help.  Will look for (maybe I have) the (or a) Symmetricom 
manual.

Scott


> On Dec 16, 2017, at 10:55 AM, Mark Sims  wrote:
> 
> Generally the best way to figure out what some cryptic Heather parameter is 
> is to consult the manual for the device and see if you can find something 
> similar to the label... you do have an extensive Symmetricom GPSDO manual, 
> don't you?  ;-) If Heather sees a wiggly value in a message , it tends to 
> get plotted. 
> 
> UNC is the holdover uncertainty... how much the time is expected to drift 
> over 24 hours without signal.  The value should go down as the GPSDO learns 
> the oscillator behavior.
> 
> TCOR is,  uhh,  tcorr.  Yeah, that's the ticket... obvious...   It's some 
> value in a status message that wiggles around.  It shows up in a status 
> message with the header "TEMP COR".   I assume it's the frequency adjustment 
> made due to temperature.
> 
> TFOM and FFOM are pretty standard GPSDO parameters.  Time figure of merit and 
> frequency figure of merit. I think the telecom industry sort of standardized 
> them. The HP Z3801A manual talks about them. 
> ___
> time-nuts mailing 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] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Mark Goldberg]

On Sat, Dec 16, 2017 at 7:36 AM, Gerhard Hoffmann  wrote:

I'm about to buy a RedPitaya Stemlab 125-14. Cost is just €310 in .de,
> seems to have respectable performance, can emulate the
> GnuRadio hardware boards more or less right out of the box,
> Win  & Linux.
>
> And it is a nice stepping stone to what I really want: a bigger ZYNC
> with JESD204B support, AD9680/ADC32RF45 ADCs & AD9142 or
> similar DACs for direct L-band digitizing. No more
> phase-shifting preselector or IF filters.
> There seem to appear better ADC/DAC chips every month for Gen5.
>
> That could be a Timepod++  :-)
>
>
You know you guys are going to wind up costing me more money! The RedPitya
looks like an amazing product for the price, dual ADCs and DACs and a Zync
for that price! And, they are available at Digikey in the US for pretty
good prices. Again, a project for the future possibly.

Thanks,

Mark
W7MLG
___
time-nuts mailing 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] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Mark Goldberg]

On Sat, Dec 16, 2017 at 3:57 AM, Attila Kinali  wrote:

>
>
> Apparently the Perseus is supported by GnuRadio[1]. Which means you can
> just click your control system together (similar to LabView). According
> to [2] the driver uses libusb and works on windows as well.
>
> If you want to use GnuRadio, I suggest you go to one of the many
> Hackfests[3]
> they have and let them jump-start you (I started this way years ago).
>

There are issues with the Perseus, Windows 10 and USB3. It is hit and miss
with various software. I am not sure it would actually work with GnuRadio
on the computer I use in my Ham Radio / Electronics lab. I do have three
computers running Linux but they are elsewhere. Simon Brown has posted some
positive messages about the cause of this being found on the Perseus Forum.
Hopefully it can be fixed. The creator of the Perseus has had to move on to
other things and can only provide limited help.

It would be a big project fro me though. I have lots of projects, but will
consider it. I do have a friend that is much more of an expert with
GnuRadio.

Thanks,

Mark
W7MLG
___
time-nuts mailing 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] Lady Heather newb questions

[W7SLS]

Hello,

Thanks for the great discussions on this group, and the work of all who brought 
Lady Heather to us.

I hope it is acceptable to ask some newbie questions?

What works:
Lady Heather installs, connects, and runs fine.
I’m comfortable with the command line interface.

What I’m curious about:
Where can I get more information about some of the abbreviation on the 
main screen?
For example:
Tcor  (corrected time?)
UNC (?)
I searched w/o success for those terms on the web, within this group 
archives, and in, for example, HP Zxxx manuals.

I’m also curious about my specific GPSDO.  It is a Symmetricom, inside a small 
enclosure with a display ($150 / eBay).
Specifically, even though I am not sure what UNC is, my guess is that 
63k us  (= 63 ms) is not good.
Still, my (uncalibrated) Tek scopes and Agilent frequency meter say it 
is “10 MHz”
TFOM looks OK (@ 2)
I’ve not measured the cable length
I’ve had the GPSDO connected for maybe 24 hours.

Thank you for considering.

Scott
W7SLS

PS: Not sure whether a screen shot will make it to the group, but here goes.
PPS:  Yes, I obscured the specific lat/lon (but yes, I know there is enough 
info to find out anyway)
PPPS:  house blocks Northern sky

___
time-nuts mailing 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] Lady Heather newb questions

[Mark Sims]

Generally the best way to figure out what some cryptic Heather parameter is is 
to consult the manual for the device and see if you can find something similar 
to the label... you do have an extensive Symmetricom GPSDO manual, don't you?  
;-) If Heather sees a wiggly value in a message , it tends to get plotted. 

UNC is the holdover uncertainty... how much the time is expected to drift over 
24 hours without signal.  The value should go down as the GPSDO learns the 
oscillator behavior.

TCOR is,  uhh,  tcorr.  Yeah, that's the ticket... obvious...   It's some value 
in a status message that wiggles around.  It shows up in a status message with 
the header "TEMP COR".   I assume it's the frequency adjustment made due to 
temperature.

TFOM and FFOM are pretty standard GPSDO parameters.  Time figure of merit and 
frequency figure of merit. I think the telecom industry sort of standardized 
them. The HP Z3801A manual talks about them. 
___
time-nuts mailing 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] European Electronics Systems Radio Clock Model 100

[steve]

Nigel

Thank you for the information.  I have two Model 100 units, one has a
stick on label saying "GPS modified" the other has no label but as they
came from the same source at the same time, it may be that the label has
come off.  I am going to take a look inside the units later today.

The units have Maldon, Essex on the serial number plates.

I guess somebody in the timing community must have worked there.

Regards

Steve


 Original Message 
Subject: Re: [time-nuts] European Electronics Systems Radio Clock Model
100
From: gandal...@aol.com
Date: Fri, December 15, 2017 10:59 am
To: time-nuts@febo.com
Cc: st...@g8ebm.com

  Hi Steve,
 
The name EES, or European Electronics Services Ltd, has been used more
than once, latest registration appears to be only about a year ago, and
might well have been used at one time by Siemens, but I think the
company you're looking for is, or was, EES Technology Ltd.
 
This eventually became Time and Frequency Solutions in Witham who were
taken over a year or so ago by Brandywine Communications in the US. I'm
still pretty sure that Radiocode clocks were also part of the earlier
mix but can't confirm that right now.
 
If checking Companies House records take a look at the filing history of
Time and Frequency Solutions here, especially early name changes.
 
https://beta.companieshouse.gov.uk/company/02627556
 
I've never used my model 100s, not quite sure why just never got round
to it, but they seem to have started out as straight MSF receivers, some
of which at least were sold to the MOD as transportable units in wooden
carrying cases with mains PSU and battery back up, and the update of
these to GPS seems to have been carried out some time later.
The mod included the addition of a separately packaged diecast box with
a GPS antenna on top, and containing a Motorola Oncore GPS module on an
interface board. I've just checked an antenna unit and it turns out the
Oncore module is a UT+, which is a bit more recent than expected:-)
 
I don't know if the GPS interface provides a stand alone 60KHz signal to
the EES 100 or whether that was also modified, although I suspect the
latter, and don't know either if the "updated" ES100s could also still
operate as an off air MSF, which may be one reason why I've not used
them.
 
Are yours the GPS version or originals?
 
Nigel GM8PZR
 
 
In a message dated 14/12/2017 12:47:27 GMT Standard Time,
st...@g8ebm.com writes:
Nigel

The link to Siemens came from Companies House searches on the name. 
They reference the link to Siemens and mention Christchurch as a base
(however that could just have been a registered office for accounting
purposes and not the engineering / production location).

I have several model 100 units and was just about to put one in a timing
rack at the museum.

Regards

Steve G8EBM
 Original Message 
Subject: [time-nuts] European Electronics Systems Radio Clock Model 100
From: GandalfG8--- via time-nuts 
Date: Thu, December 14, 2017 1:59 am
To: time-nuts@febo.com

Does anyone have a service manual or any information on the 
Europeanlectronics Systems (EES) Radio Clock Model 100.
The company was part of Siemens but closed down in 2005.
The Model 100 was supplied by Plessey Defence Systems to the UK
military. 
Some models could be GPS disciplined 
Any information would be gratefully received for the Radio Communication

Museum of Great Britain.
(thanks to Robert with the hint about plain text !!)
Steve Haseldine G8EBM

--
Now there's interesting!

With EES being quite a small outfit based in Maldon, Essex, or so I 
thought, I'm surprised to hear they were ever part of Siemens, are you
sure about 
that?

For some reason I thought they eventually became part of Radiocode
Clocks, 
although I could well be wrong on that also, something not entirely 
unheard of :-), but do seem to recall several mergers etc amongst the
various UK 
off air standards outfits.

I've got a few EES MSF and Droitwich clocks, including the earlier
SFR060A 
and SFR200B, plus a 201 at the top of one of my racks in constant use,
but 
despite having some EES documentation I never did find much on the model

100.

With half a dozen or so of the GPS conditioned versions of the model 100

sitting in my garage I would also welcome some documentation. My notes
made 
several years ago seem to have disappeared but I do remember being 
convinced that the GPS option was very much an aftermarket afterthought,
for that 
read bodge:-), based on a retrofit Motorola Oncore if I remember
correctly, 
and not really something to get very excited about.

Regards, Nigel GM8PZR







___
time-nuts mailing 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 

Re: [time-nuts] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Gerhard Hoffmann]

Am 16.12.2017 um 11:57 schrieb Attila Kinali:



[1] "Oscillator metrology with software defined radio",
by Sherman and Jördens, 2016
https://arxiv.org/abs/1605.03505


I have seen this paper before. Unfortunately, it is a lot more work to
implement than what I have already done. I am really a hardware engineer,
with decades old education in control systems that has not been used in a
long time. It would take getting my brain back in gear and re-studying, not
a bad thing actually!

The other issue is the Perseus drivers have issues under Windows 10 that
may or may not be solved. I was able to get it to work with Spectrum Lab,
but it does not work with many other tools that would be able to implement
this algorithm.

That said, I may look into it further in the future.

Apparently the Perseus is supported by GnuRadio[1]. Which means you can
just click your control system together (similar to LabView). According
to [2] the driver uses libusb and works on windows as well.

If you want to use GnuRadio, I suggest you go to one of the many Hackfests[3]
they have and let them jump-start you (I started this way years ago).


I'm about to buy a RedPitaya Stemlab 125-14. Cost is just €310 in .de,
seems to have respectable performance, can emulate the
GnuRadio hardware boards more or less right out of the box,
Win  & Linux.

And it is a nice stepping stone to what I really want: a bigger ZYNC
with JESD204B support, AD9680/ADC32RF45 ADCs & AD9142 or
similar DACs for direct L-band digitizing. No more
phase-shifting preselector or IF filters.
There seem to appear better ADC/DAC chips every month for Gen5.

That could be a Timepod++  :-)

regards, Gerhard

<  https://www.redpitaya.com/c96/stemsuplabsup-125-14   >
< http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver-hpsdr/ >




___
time-nuts mailing 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] Somewhat OT: Resurrecting a Symmetricom ND-4 Clock / Date display with a Raspberry Pi.

[Warren Kumari]

Hi all,

I've had a broken Symmetricom ND-4 NTP Clock sitting around for a
time, and it somehow turned into one of those OCD projects which I
just couldn't drop. I wanted an NTP display to show what my time is,
and this was such a simple device that the fact I couldn't fix it
really bugged me. Yes, I put in way more time than the device was
worth, but I ended up with an easy fix.

Last weekend I'd finally had enough and so ripped out the processor
board and replaced it with a Raspberry Pi Zero W, running NTP and
taking to the display directly.

It seems that these ND-4 / ND-2 devices used to be fairly popular, but
had a relatively high failure rate. They are also EOL.

If anyone has a busticated one, it's really easy to replace the board
with a Pi. I've put a short writeup here:
https://www.kumari.net/index.php/projects/random-projects/94-replacing-a-symmetricom-nd-4-processor-with-a-raspberry-pi
and the (trivial) code is here:
https://github.com/wkumari/symmetricom-nd4-python

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
time-nuts mailing 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] accurate 60 hz reference chips/ckts

[Tom Van Baak]

I sent a note to Vlad off-list about the bug in the MCU code, but it's worth a 
reminder to the list as well since many of you are programmers and this arcane 
issue comes up every once in a while here and on the web.

The way to compute time differences of free-running binary time counters is 
subtraction. One line of code. There is no need to special case overflow / 
rollover / wraparound. It is the very nature of unsigned or 2's compliment 
signed binary arithmetic that subtraction is sufficient. So the bug-free code 
is just this:

 uwIC2Value2 = (HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1));
 uwDiffCapture = (uwIC2Value2 - prevtimer);
 prevtimer = uwIC2Value2;

If you'd like a simple example why this is correct and a demonstration of what 
the bug was, see:

http://leapsecond.com/tools/deltatim.c

/tvb

- Original Message - 
From: "Vlad" 
To: "Jeremy Nichols" 
Cc: "Discussion of precise time and frequency measurement" 
Sent: Friday, December 15, 2017 9:41 AM
Subject: Re: [time-nuts] accurate 60 hz reference chips/ckts



My setup is pretty simple indeed. This is 9.830400MHZ OCXO which 
clocking MCU. Then it is Zero-Cross detector which connected to capture 
timer.
The MCU counting the intervals between of each zero-cross event and 
number of events occurred.

 if (htim->Instance == TIM5 && htim->Channel == 
HAL_TIM_ACTIVE_CHANNEL_1) {
 uwIC2Value2 = (HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1));
 if (uwIC2Value2 >= prevtimer) {
 uwDiffCapture = (uwIC2Value2 - prevtimer);
 } else {
 uwDiffCapture =((0x - prevtimer) + uwIC2Value2);
 }

 prevtimer = uwIC2Value2;

 // MAIN Time calculation
 if(++uwCapT > 59) {  // Every 60 cycles (60hz)
 if(++maintime.Seconds > 59) {
 maintime.Seconds = 0;
 if(++maintime.Minutes > 59) {
 maintime.Minutes = 0;
 if(++maintime.Hours > 23)
 maintime.Hours = 0;
 }
 }
 uwCapT = 0;
}

Once an hour the program prints its internal clock (MCU time), RTC time 
and MAIN time

# Uptime:   476 hours
# RTC time: 13:00:00
# MCU time: 13:00:00
# MAIN time:13:00:01

The graph shows the "delta" between of RTC and MAIN.


___
time-nuts mailing 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] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Attila Kinali]

On Fri, 15 Dec 2017 10:08:29 -0700
Mark Goldberg  wrote:

> > The approach using FFT works, but just using the peak frequency, you throw
> > away half of the data (the phase) and also limit yourself in precision
> > to the bin width. It's not 100% clear that estimating the frequency
> > using an FFT is unbiased in this case, thus you might get worse (or better)
> > results than what the oscillator actually does.
> >
> 
> Since I do not know the exact algorithm used to interpolate peak frequency,
> I don't know the effect on precision. They do claim that the peak frequency
> determination precision is much smaller than the bin width, which seems to
> be shown by the data.
> 
> The results are good enough to discern between "bad" and "good" units under
> test, but I have no way to compare my results to any other method of
> measurement. This is all I have access to.

If all you want is to discern good and bad units, this is good enough.
 
> > [1] "Oscillator metrology with software defined radio",
> > by Sherman and Jördens, 2016
> > https://arxiv.org/abs/1605.03505
> >
> 
> I have seen this paper before. Unfortunately, it is a lot more work to
> implement than what I have already done. I am really a hardware engineer,
> with decades old education in control systems that has not been used in a
> long time. It would take getting my brain back in gear and re-studying, not
> a bad thing actually!
> 
> The other issue is the Perseus drivers have issues under Windows 10 that
> may or may not be solved. I was able to get it to work with Spectrum Lab,
> but it does not work with many other tools that would be able to implement
> this algorithm.
> 
> That said, I may look into it further in the future.

Apparently the Perseus is supported by GnuRadio[1]. Which means you can
just click your control system together (similar to LabView). According
to [2] the driver uses libusb and works on windows as well.

If you want to use GnuRadio, I suggest you go to one of the many Hackfests[3]
they have and let them jump-start you (I started this way years ago).


Attila Kinali


[1] https://gnuradio.org/
[2] https://github.com/Microtelecom/libperseus-sdr
[3] https://www.gnuradio.org/event-type/hackfest/


-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
___
time-nuts mailing 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] Simple open source microcontroller solution to tune DDS needed

[Bo Hansen]

Hi list

Here is an Arduino way to control AD9833, AD9850, AD9851, AD9912 and AD9913



Alternatively using an Atmega128A to control an AD9912:



Bo



___
time-nuts mailing 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] Lady Heather newb questions

[W7SLS]

Hello,

Thanks for the great discussions on this group, and the work of all who brought 
Lady Heather to us.

I hope it is acceptable to ask some newbie questions?

What works:
Lady Heather installs, connects, and runs fine.
I’m comfortable with the command line interface.

What I’m curious about:
Where can I get more information about some of the abbreviation on the 
main screen?
For example:
Tcor  (corrected time?)
UNC (?)
I searched w/o success for those terms on the web, within this group 
archives, and in, for example, HP Zxxx manuals.

I’m also curious about my specific GPSDO.  It is a Symmetricom, inside a small 
enclosure with a display ($150 / eBay).
Specifically, even though I am not sure what UNC is, my guess is that 
63k us  (= 63 ms) is not good.
Still, my (uncalibrated) Tek scopes and Agilent frequency meter say it 
is “10 MHz”
TFOM looks OK (@ 2)
I’ve not measured the cable length
I’ve had the GPSDO connected for maybe 24 hours.

Thank you for considering.

Scott
W7SLS

PS: Not sure whether a screen shot will make it to the group, but here goes.
PPS:  Yes, I obscured the specific lat/lon (but yes, I know there is enough 
info to find out anyway)
PPPS:  house blocks Northern sky




___
time-nuts mailing 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] accurate 60 hz reference chips/ckts

[Gary E. Miller]

Yo All!

Jeremy wrote:

> I'm surprised Vlad is seeing as much as six seconds differential
> but maybe I don't understand the experiment. I've done measurements
> of the line frequency here in California and never seen much
> variation.  

I live in Central Oregon.  Next to the Pacific Intertie and the Paccific
DC Intertie.  Near the Round Butte Dam, Pelton Dam, and other power
generating dams.

The Interties connect the massive hydropower generation of the Columbia
River system with southern California.

The hypropower system includes the best technology of the 1930's, 1940's
and 1950's.

I've had converstations with some of the dam operators about how
they keep frequency.  Pretty simple really.  Huge tonnages of spinning
steel and copper being pushed by falling water.  The water is regulated
by flapper valves.  Pretty stable short term.

Now imagine when a 300MVA intertie blows over, or is burned by a fire,
and instantly disconnects.  Or a steel mill shuts down for the day, or...

The electrical backpressure to the generators drops, so the generators
speed up, increasing the line frequency and voltage.

When this happens, the dam operators literally pick up the phone, and
talk to the other dams to decide what to do.  Usually that involves
one or more dams closing down a few flapper vavles.

That is how the short term frequency of your local power line is
controlled.

The control room also has a AC synchronous clock, off the power line, 
and an accurate digital clock.  Once a day they manually get the
AC clock to agree with the digital clocl.

None of this is rocket science, don't use it for anything you need
any accuracy for.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgp5568AfFDAl.pgp
Description: OpenPGP digital signature
___
time-nuts mailing 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] Determining Allan Deviation From Interpolated Peak Frequency Readings

[Mark Goldberg]

Thanks for the detailed response.

On Fri, Dec 15, 2017 at 5:42 AM, Attila Kinali  wrote:

> Hey Mark
>
> On Wed, 6 Dec 2017 15:43:49 -0700
> Mark Goldberg  wrote:
>
> > https://sites.google.com/site/perseusmods/
> > and
> > https://sites.google.com/site/spectrumlabtesting/
> >
> > using wide FFT bins and Spectrum Lab's peak frequency interpolation
> > function. I would appreciate comments as to the effectiveness of this
> > approach. I have a thick skin, so any criticism is welcome if it improves
> > the process.
>
> The approach using FFT works, but just using the peak frequency, you throw
> away half of the data (the phase) and also limit yourself in precision
> to the bin width. It's not 100% clear that estimating the frequency
> using an FFT is unbiased in this case, thus you might get worse (or better)
> results than what the oscillator actually does.
>

Since I do not know the exact algorithm used to interpolate peak frequency,
I don't know the effect on precision. They do claim that the peak frequency
determination precision is much smaller than the bin width, which seems to
be shown by the data.

The results are good enough to discern between "bad" and "good" units under
test, but I have no way to compare my results to any other method of
measurement. This is all I have access to.


>
> What you are trying to do is spectral estimation from a limited number of
> samples. You want to have some kind of continuity, that might allow you to
> track minute changes from block you are processing to the next block.
> The easiest way to do this would be to downconvert the signal on the PC
> to zero Hz and take the phase information (simplest way: use a NCO as a
> reference, then pass the reference and signal into a CORDIC to get the
> phase
> difference). Recording this phase difference should give you a lower floor
> for *DEV than your FFT method. It will also alow you to track small phase
> changes (aka small frequency fluctuations) that happen over long periods.
> Sherman and Jördens[1] describe the approach in more detail.
>
> Other than that, the general approach looks ok.
>
>
> Attila Kinali
>
>
> [1] "Oscillator metrology with software defined radio",
> by Sherman and Jördens, 2016
> https://arxiv.org/abs/1605.03505
>

I have seen this paper before. Unfortunately, it is a lot more work to
implement than what I have already done. I am really a hardware engineer,
with decades old education in control systems that has not been used in a
long time. It would take getting my brain back in gear and re-studying, not
a bad thing actually!

The other issue is the Perseus drivers have issues under Windows 10 that
may or may not be solved. I was able to get it to work with Spectrum Lab,
but it does not work with many other tools that would be able to implement
this algorithm.

That said, I may look into it further in the future.

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