[time-nuts] Cannot Command RFTGm-II-Rb / RFTGm-II-XO

[Mark Sims]

The RFTG-m units don't speak SCPI.   They have an undocumented binary control 
language.   I reversed engineered the protocol and the latest version of Lady 
Heather can talk to them.  The v5.0 release of Heather does not support these.  
 If you run something linuxy or can compile the v5.0 release, I can send you 
the newest version to try.  Hope to get a public Windoze release out shortly...

On ko4bb.com there is a copy of Lucent's control software for Win 95/98 (works 
under XP).  It is six (?) files that need to be saved in a directory.  It is 
rather wonky and crusty and a bit unstable (hmmm... sounds a bit like me).
___
time-nuts mailing 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] Cannot Command RFTGm-II-Rb / RFTGm-II-XO

[Bob kb8tq]

Hi

If you go back a ways in the archives, there is a *lot* of information about how
to run these beasts. There also are links to the software and command sets
for the devices.

Bob

> On Dec 17, 2017, at 5:01 PM, Patrick Murphy  wrote:
> 
> I have recently acquired a used Lucent RFTGm-II-Rb and XO. The set came
> assembled with cables and frame, so I am pretty sure everything is hooked
> together correctly. I have powered both units, and after a few hours I have
> the green "Online" light lit on the REF-0 (Rb) and the yellow "Standby"
> light lit on the REF-1 (XO). I am watching serial traffic via two
> RS422<->USB adapters. After switching a couple of wires around, I am seeing
> TCODE data from both units on the RX side at the PC. I have a clean 15MHz
> waveform and 2 ugly 10MHz waveforms from the Rb, and PPS from both units.
> All seems well so far.
> 
> I'd like to hook them up to two instances of Lady Heather and see what is
> going on. The problem is that I cannot interrupt the TCODE stream to put
> the device into SCPI mode. I have tried commands like ":ptim:tcod:cont 0"
> (also "ptim:tcod:cont 0", without the leading ":") and variants of
> ":SYST:STAT?". Both modules just ignore them.
> 
> I have a bootable Linux partition. I guess I can load up WINE and try the
> somewhat dated "RFTG.EXE". That seems a little extreme, especially if I
> need to repeat that every time I need to restart the RFTGs.
> 
> Any suggestions what I should try next before I go the Linux route? Surely
> there is some command or secret handshake I am just missing.
> 
> Thanks!
> 
> -Patrick Murphy
> ___
> time-nuts mailing 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] Cannot Command RFTGm-II-Rb / RFTGm-II-XO

[Patrick Murphy]

I have recently acquired a used Lucent RFTGm-II-Rb and XO. The set came
assembled with cables and frame, so I am pretty sure everything is hooked
together correctly. I have powered both units, and after a few hours I have
the green "Online" light lit on the REF-0 (Rb) and the yellow "Standby"
light lit on the REF-1 (XO). I am watching serial traffic via two
RS422<->USB adapters. After switching a couple of wires around, I am seeing
TCODE data from both units on the RX side at the PC. I have a clean 15MHz
waveform and 2 ugly 10MHz waveforms from the Rb, and PPS from both units.
All seems well so far.

I'd like to hook them up to two instances of Lady Heather and see what is
going on. The problem is that I cannot interrupt the TCODE stream to put
the device into SCPI mode. I have tried commands like ":ptim:tcod:cont 0"
(also "ptim:tcod:cont 0", without the leading ":") and variants of
":SYST:STAT?". Both modules just ignore them.

I have a bootable Linux partition. I guess I can load up WINE and try the
somewhat dated "RFTG.EXE". That seems a little extreme, especially if I
need to repeat that every time I need to restart the RFTGs.

Any suggestions what I should try next before I go the Linux route? Surely
there is some command or secret handshake I am just missing.

Thanks!

-Patrick Murphy
___
time-nuts mailing 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] ergodicity vs 1/f

[Magnus Danielson]

Hi

On 12/18/2017 01:03 AM, Bob kb8tq wrote:

You then hit the very basic fact that a “standard noise process” does not cover 
what real oscillators or amplifiers
do in the field. They have a *lot* of “noise like” issues that impact their 
performance. Simply coming up with a model
for this or that process is only a very basic start to modeling a real device 
…..


Yes, indeed.

One does not have to be very esoteric. Temperature dependence is a very 
systematic process, and we can kind of model a good part of its major 
effects, but the "noise" of the temperature variations itself is not 
easily covered and well, is a mess all in itself.


You then go downhill from there with gazillions sources of drift and 
modulations.


We can however break some of the noise properties away and model them 
and estimate their properties to some degree, so that helps get some of 
the stuff understandable enough. The tools however is often widely 
misunderstood and misused.


I just don't see how a lengthy debate on ergodicity is really helping 
when doing it in the wrong end of things.


People does not even properly separate systematic effects from noise, so 
their noise analyses becomes way of the mark and the systematic analyses 
does not have proper confidence intervals. Then the discussing the color 
of black does not help to understand the color of the orange very much.


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

Re: [time-nuts] ergodicity vs 1/f

[Bob kb8tq]

Hi



> On Dec 17, 2017, at 6:50 PM, Magnus Danielson  
> wrote:
> 
> Hi,
> 
> On 12/17/2017 03:09 PM, Mattia Rizzi wrote:
>>> you demand ergodicity, you cannot have 1/f. You can have only one or the
>> other. Not both. And if you choose ergodicity, you will not faithfully
>> model a clock.
>> I am talking about the issues of flicker noise processes for an
>> experimentalist. I know that the (current) theory is incompatible with
>> ergodicy, but for an experimentalist ergodicity is an assumption that you
>> have to do. You did as well, in Attila#2.
> 
> We need to assume the properies of our model is static as we measure it and 
> try to estimate the model parameters.
> 
> However, the noise we have does not have the normal convergence properties, 
> so much of the normal ways of defining things does not directly apply.
> 
> Much of the methods we have come out of experimentalists trying to make 
> models and methods adapt to their measurement reality.
> 
> A spectrum analyzer will pre-filter flicker noise and by that change its 
> statistical behavior, it will start to behave much more like white noise, but 
> there will be a bias in the reading. The bias in the reading depends on the 
> filtershape and noise type. This is known from both theory and actual 
> measurements.
> 
> Similarly will counter-based observation behave.
> 
> This heated debate on ergodic etc. needs to focus on what actually happens 
> and leave the theory draftingboard, since honestly, you guys to not make 
> enough sense even to me. Leave the fancy definitions aside for a moment and 
> let's focus on the properties and how we achieve them and how not to achieve 
> them.
> 
>>> Please take one of the SA's you have at CERN, measure an oscillator
>> for a long time and note down the center frequency with each measurement.
>> I promise you, you will be astonished.
>> Let's keep the focus on flicker noise, for instance, flicker noise of an
>> amplifier. Noise in oscillators is more fuzzy.
> 
> It's the noise of oscillators you need to handle, because it will be there to 
> act as test signals for amplifiers.
> 
> It is however understood and we have methods to handle it.
> 
> The models we have work within some limits. I've spent time to learn these 
> limits and checked it with those knowing much better. Being rigorous about 
> this is not for the fainthearted, and while many knows some, it does not help 
> if you want to be rigorous. Then again, very very few are. I have not seen 
> any real convergence in your debate, it's kept fluctuating without 
> stabilizing just as a RMS measure does on these noisetypes, you keep 
> deviating even wilder even.
> 
> I find that much of the terms and definitions in classical statistics is 
> really not applicable as you encounter 1/f and further noises. While useful 
> background, as you enter the dark dungeon of time and frequency, there be 
> flicker dragons and other monsters that the classical statistics didn't 
> prepare you very well for, even if it was a good education.
> 
> To go further, for a while all references to ergodic, I.I.D., gaussian etc. 
> just have to pause, because they are not contributing to understanding, they 
> only contribute to disagreement. Let's discuss actual properties separate, 
> and maybe we can come back and conclude what it means in other terms, but not 
> now.

You then hit the very basic fact that a “standard noise process” does not cover 
what real oscillators or amplifiers
do in the field. They have a *lot* of “noise like” issues that impact their 
performance. Simply coming up with a model
for this or that process is only a very basic start to modeling a real device 
…..

Bob


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

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

Re: [time-nuts] ergodicity vs 1/f

[Magnus Danielson]

Hi,

On 12/17/2017 03:09 PM, Mattia Rizzi wrote:

you demand ergodicity, you cannot have 1/f. You can have only one or the

other. Not both. And if you choose ergodicity, you will not faithfully
model a clock.

I am talking about the issues of flicker noise processes for an
experimentalist. I know that the (current) theory is incompatible with
ergodicy, but for an experimentalist ergodicity is an assumption that you
have to do. You did as well, in Attila#2.


We need to assume the properies of our model is static as we measure it 
and try to estimate the model parameters.


However, the noise we have does not have the normal convergence 
properties, so much of the normal ways of defining things does not 
directly apply.


Much of the methods we have come out of experimentalists trying to make 
models and methods adapt to their measurement reality.


A spectrum analyzer will pre-filter flicker noise and by that change its 
statistical behavior, it will start to behave much more like white 
noise, but there will be a bias in the reading. The bias in the reading 
depends on the filtershape and noise type. This is known from both 
theory and actual measurements.


Similarly will counter-based observation behave.

This heated debate on ergodic etc. needs to focus on what actually 
happens and leave the theory draftingboard, since honestly, you guys to 
not make enough sense even to me. Leave the fancy definitions aside for 
a moment and let's focus on the properties and how we achieve them and 
how not to achieve them.



Please take one of the SA's you have at CERN, measure an oscillator

for a long time and note down the center frequency with each measurement.
I promise you, you will be astonished.

Let's keep the focus on flicker noise, for instance, flicker noise of an
amplifier. Noise in oscillators is more fuzzy.


It's the noise of oscillators you need to handle, because it will be 
there to act as test signals for amplifiers.


It is however understood and we have methods to handle it.

The models we have work within some limits. I've spent time to learn 
these limits and checked it with those knowing much better. Being 
rigorous about this is not for the fainthearted, and while many knows 
some, it does not help if you want to be rigorous. Then again, very very 
few are. I have not seen any real convergence in your debate, it's kept 
fluctuating without stabilizing just as a RMS measure does on these 
noisetypes, you keep deviating even wilder even.


I find that much of the terms and definitions in classical statistics is 
really not applicable as you encounter 1/f and further noises. While 
useful background, as you enter the dark dungeon of time and frequency, 
there be flicker dragons and other monsters that the classical 
statistics didn't prepare you very well for, even if it was a good 
education.


To go further, for a while all references to ergodic, I.I.D., gaussian 
etc. just have to pause, because they are not contributing to 
understanding, they only contribute to disagreement. Let's discuss 
actual properties separate, and maybe we can come back and conclude what 
it means in other terms, but not now.


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

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

[paul swed]

As comment mmdd is actually a windows behavior.
If files are named in that manner they line up in the directory in order.
20171216 8603 pix 1-20.
Minor but may be helpful.
Regards
Paul
WB8TSL

On Sun, Dec 17, 2017 at 8:55 AM, Attila Kinali  wrote:

> On Sat, 16 Dec 2017 15:14:25 -0800
> "Tom Van Baak"  wrote:
>
> > Ed Palmer text and photos:
> > http://leapsecond.com/museum/osa8601/
> > http://leapsecond.com/museum/osa8601/view.htm
>
> The 7.04.82 in the 11th picture is likely to be a date code.
> But it's in European notation, meaning day.month.year.
> Ie it's 7th Arpil, 1983
>
> Rule of thumb: if it's "/" then it's MM/DD/YY or YY/MM/DD (depending
> whether it's USian or Japanese). If it's "." then it's DD.MM.YY
> (most common European notation). If it's "-" it was supposed
> to be -MM-DD by ISO8601, but too many people confused it as
> being the "new way" to write dates, so it can be literally anything.
>
>
> Thanks for the pictures!
>
> Attila Kinali
>
> --
> 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.
>
___
time-nuts mailing 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] ergodicity vs 1/f (was: Allan variance by sine-wave fitting)

[Mattia Rizzi]

Hi,

Finally I have time to answer it properly.
Let's do a quick recap. Topic is flicker noise, statistics theory vs
experimental hypothesis. I am aware that flicker noise, in stochastic
theory, it's not ergodic nor stationary.

Mattia#1: (If you striclty apply the stochastic theory) you are not allowed
to take a realization, make several fft and claim that that's the PSD of
the process. But that's what the spectrum analyzer does, because it's not a
multiverse instrument.
Every experimentalist suppose ergodicity on this kind of noise (i.e.
flicker noise), otherwise you get nowhere.

Attila#1: Err.. no. Even if you assume that the spectrum tops off at some
very low frequency and does not increase anymore, ie that there is a finite
limit to noise power, even then ergodicity is not given.
Ergodicity breaks because the noise process is not stationary. And assuming
so for any kind of 1/f noise would be wrong.  the reason why this is wrong
is because assuming noise is ergodic means it is stationary. But the reason
why we have to
treat 1/f noise specially is exactly because it is not stationary.


Mattia:It's not so simple. If you don't assume ergodicity, your spectrum
analyzer does not work, because:
1) [...]
2) It's just a single realization, therefore also a flat signal can be a
realization of 1/f flicker noise. Your measurement has *zero* statistical
significance.


Attila#2: I do not see how ergocidity has anything to do with a spectrum
analyzer.
You are measuring one single instance. Not multiple.
A flat signal cannot be the realization of a random variable with a PSD ~
1/f. At least not for a statisticially significant number of time-samples.
If it would be, then the random variable would not have a PSD of 1/f. If
you go back to the definition of the PSD of a random variable X(ω,t), you
will see it is independent of ω.
And about statistical significance: yes, you will have zero statistical
significance about the behaviour of the population of random variables, but
you will have a statistically significant number of samples of *one*
realization of the random variable. And that's what you work with.

Mattia: Let me emphasize your sentence:  "you will have a statistically
significant number of samples of *one* realization of the random variable.".
This sentence is the meaning of ergodic process. If it's ergodic, you can
characterize the stochastic process using only one realization.
If it's not, your measurement is worthless, because there's no guarantee
that it contains all the statistical information.

End of recap.

Let's start again with Attila#2 in the recap. You say that a flat signal
cannot be a realization of flicker process. Well, you're using one
assumption "At least not for a statisticially significant number of
time-samples". This property is true only for an ergodic process.
Definition of ergodic process (from wikipedia): "a stochastic process is
said to be ergodic if its statistical properties can be deduced from a
single, sufficiently long, random sample of the process".
You applied ergodicy to dismiss my mental experiment. If you striclty apply
the stochastic theory, from an experimental point of view, you cannot proof
or dismiss hypothesis, which is the core of scientific research.


>You are mixing up ergodicity and reproducability. Also, you are moving the
goalpost. We usually want to characterize a single clock or oscillator.
Not a production lot. As such the we only care about the statistical
properties of that single instance.


Nope. I was always talking about *a single* realization, coming from a
single DUT.
Due to the complex nature of flicker noise, you have just a single
realization in this Universe (thats why I am talking about multiverse in
Mattia#1).

> you demand ergodicity, you cannot have 1/f. You can have only one or the
other. Not both. And if you choose ergodicity, you will not faithfully
model a clock.

I am talking about the issues of flicker noise processes for an
experimentalist. I know that the (current) theory is incompatible with
ergodicy, but for an experimentalist ergodicity is an assumption that you
have to do. You did as well, in Attila#2.

>Please take one of the SA's you have at CERN, measure an oscillator
for a long time and note down the center frequency with each measurement.
I promise you, you will be astonished.

Let's keep the focus on flicker noise, for instance, flicker noise of an
amplifier. Noise in oscillators is more fuzzy.



cheers,
Mattia




2017-11-30 15:40 GMT+01:00 Attila Kinali :

> On Thu, 30 Nov 2017 12:44:13 +0100
> Mattia Rizzi  wrote:
>
> > Let me emphasize your sentence:  "you will have a statistically
> significant
> > number of samples of *one* realization of the random variable.".
> > This sentence is the meaning of ergodic process [
> > https://en.wikipedia.org/wiki/Ergodic_process]
> > If it's ergodic, you can characterize the stochastic process using only
> one
> > realization.
> > If 

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

[Attila Kinali]

On Sat, 16 Dec 2017 15:14:25 -0800
"Tom Van Baak"  wrote:

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

The 7.04.82 in the 11th picture is likely to be a date code.
But it's in European notation, meaning day.month.year.
Ie it's 7th Arpil, 1983

Rule of thumb: if it's "/" then it's MM/DD/YY or YY/MM/DD (depending
whether it's USian or Japanese). If it's "." then it's DD.MM.YY
(most common European notation). If it's "-" it was supposed
to be -MM-DD by ISO8601, but too many people confused it as
being the "new way" to write dates, so it can be literally anything.


Thanks for the pictures!

Attila Kinali

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