Re: [time-nuts] Cheap jitter measurements

[Gerhard Hoffmann]

Am 10.04.2018 um 01:03 schrieb Gary E. Miller:

Yo Hal!

On Mon, 09 Apr 2018 13:53:21 -0700
Hal Murray  wrote:


The API  for the kernel clock can be read to a ns.  I don't see ntpd
having much use for finer grain than that.  I should look at the
source to see what the internal details look like.

Yeah, but the granularity is much worse.



And with the new generation of attacks against the prefetch queue /
instruction decoder latency that probably will be blurred even more.

I don't expect my computers' clock to be more precise than needed
for makefiles. Anything more precise is better taken care of by hardware.

regards, Gerhard



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

Re: [time-nuts] Cheap jitter measurements

[Gary E. Miller]

Yo Hal!

On Mon, 09 Apr 2018 13:53:21 -0700
Hal Murray  wrote:

> The API  for the kernel clock can be read to a ns.  I don't see ntpd
> having much use for finer grain than that.  I should look at the
> source to see what the internal details look like.

Yeah, but the granularity is much worse.

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


pgpsOvGE7c621.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] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 9, 2018, at 4:53 PM, Hal Murray  wrote:
> 
> 
> kb...@n1k.org said:
>> Somewhere in the NTP algorithm, there is a “zero error” estimate. GPS
>> modules have the same thing buried in them. A GPS module (like NTP as
>> described above) can only *express* a PPS modulo some clock rate. GPS
>> modules get around this with a firmware hack. They simply tell you what the
>> error was. It is a simple way to get out of the “I need a 10 GHz clock
>> source” problem. No need for FPGA’s or any other guck. You just do an
>> estimate and report it. It then would work on any hardware and let you do
>> the sort of measurements we’re talking about.
> 
> The GPS offset is a kludge to work around not being able to control the local 
> oscillator.
> 
>> Now - *can* that be done with NTP??  Who knows…. 
> 
> The kernel clock has a knob so the same concept doesn't apply.

The kernel clock comes from the CPU clock. That CPU clock is phase locked
to a crystal. If you have a CPU that is driven by a VCXO that is a *very* 
unusual
CPU board.  The crystal runs at an arbitrary frequency. That gives you edges 
that
are unlikely to happen “right on the second”. 

> 
> The API  for the kernel clock can be read to a ns.  I don't see ntpd having 
> much use for finer grain than that.  I should look at the source to see what 
> the internal details look like.
> 
> If ntpd decides the clock needs correcting, it tells the kernel to do the 
> work.  The kernel offsets the clock rate knob by 500 PPM, so it takes 2000 
> microseconds to adjust the clock by 1 microsecond.  It would be possible to 
> read the correction-left and adjust the time by that amount.

And the kernel does the “adjust” by dropping or adding clock cycles to the 
count. 
The result is still modulo the hardware clock period as conveyed to the kernel 
through 
a timer. Dig into the timer architecture and it has it’s limitations. What they 
are is 
very much a “that depends” from this CPU to that CPU. 

Being able to read the kernel time is only part of the process. You need to 
generate
an edge. That gets you into timers and (likely) a different set of limitations 
as the
edge makes it’s way to get to a pin. 

> 
> I think it would be possible to make similar adjustments by post processing 
> the data.  I'd have to double check to make sure I understand what is in 
> loopstats.  If now, we could fix it.

The idea is to get a second by second update of what is going on relative to an 
edge 
that comes out of the computer. Effectively you:

1) need to generate that edge
2) track it back to the NTP internals 
3) turn that track into a message that tells the user what the offset is

Now, if indeed you *can* generate edges to within 1 ns of an arbitrary point in 
time, then 
yes - the message probably has no value. I have yet to see a normal computer 
that is set
up to do that.  Putting a GHz clock into a modulo divider or 32 bit comparator 
apparently 
isn’t something there is much call for …..

Bob

> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

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

Re: [time-nuts] Looking for IEEE-488 codes and formats for Datum 9700AT Programmable Time System

[Bob kb8tq]

Hi

Yes, there is what appears to be a socketed ROM on the board. Next step seems 
to be to dump
the ROM and see what’s inside. 

Bob

> On Apr 9, 2018, at 3:55 PM, Forrest Christian (List Account) 
>  wrote:
> 
> Just curious, is there by chance a removable eprom or other programmable
> device on these boards?
> 
> Assuming a fairly verbose scpi like command interface, I've occasionally
> had luck reverse engineering a command set by looking through an eprom dump
> for a list of commands?
> 
> Also, does this by chance respond to the standard scpi commands like *IDN?
> and *TST?
> 
> On Mon, Apr 9, 2018, 12:24 PM Bill  wrote:
> 
>> I have two of these with 488  interfaces.
>> Would appreciate any 488 info you get.
>> br...@otelco.net
>> 
>> -Original Message-
>> From: Bob kb8tq
>> Sent: Saturday, April 07, 2018 10:27 PM
>> To: lee...@aol.com ; Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Looking for IEEE-488 codes and formats for Datum
>> 9700AT Programmable Time System
>> 
>> Hi
>> 
>> Actually the manual is moot on any sort of remote control. The RS-232
>> section refers you to an insert
>> in the back of the manual. I’d guess that the 488 stuff was done the same
>> way.
>> 
>> Nasty question: Are you sure you have the 488 option installed?  It would
>> not be the first piece of gear
>> produced that never really got a 488 firmware version …..
>> 
>> Bob
>> 
>>> On Apr 7, 2018, at 11:11 PM, Tom Leedy via time-nuts >> 
>>> wrote:
>>> 
>>> 
>>> Hi:
>>> 
>>> I am looking for the IEEE-488 codes and formats for a Datum 9700AT
>>> Programmable Time System.  The 9700AT is a 1U time generator and
>>> translator with slots in the back that can accept option cards with
>>> various functionalities such as -488 and RS-232 interfaces, GPIO, and
>> tape
>>> searches.  What I need is the character strings to output the time for
>>> the -488 interface.  The manual for the unit is here:
>>> 
>> http://www1.symmetricom.com/media/files/support/ttm/product-manual/man-9700at-9710.pdf
>>> However, it is silent on the details of the -488 interface.
>>> 
>>> Any help would be appreciated and feel free to contact me offline.
>>> 
>>> Many thanks!
>>> 
>>> Tom Leedy
>>> Clarksburg, MD
>>> 
>>> 
>>> ___
>>> time-nuts mailing 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.
>> 
>> 
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing 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] ADEV dead time w/ HP 53131A & TimeLab

[Magnus Danielson]

Hi David,

On 04/09/2018 03:29 AM, David Burnett wrote:
> Hi time-nuts,
> 
> I'm doing oscillator-related research for my PhD and found this list
> recently. It's been a great resource in trying to refine my freq
> measurement setup and in starting to understand what's really going on
> inside my lab equipment.

Really good! Welcome!

> I've been trawling the archives and have a question about measuring ADEV
> accurately with the Agilent 53131A frequency counter I have on hand. From
> the comments on this list and elsewhere, and the fact that TimeLab will
> talk to my 53131A directly, I have the impression one can use the 53131A
> for period measurements with which to calculate ADEV. But from GPIB command
> sniffing it looks like there's a lot of dead time between measurements:
> -- In period or freq mode* measurements take an extra ~130ms longer than
> gate time to return (but this seems to produce the correct measurements for
> TimeLab);
> -- in time interval mode they take about ~20ms;
> -- in totalize mode they take about 5ms, in keeping with "200 measurements
> per second" advertised in the brochure, but of course this is a simple
> counter and one loses the resolution of a reciprocal counter or anything
> smarter added in.
> 
> Is it just generally assumed everyone is making period measurements on time
> scales long enough that any instrument dead time is ignorable? Or is
> TimeLab and everyone else silently applying the correction factor as
> described by the Barnes & Allan NIST paper (NIST technical note 1318)? Or
> is there a configuration mode I'm missing that prints measurements with
> more regularly? TimeLab's GPIB commands seem to be limited to "get current
> measurement" so I might not have the box set up right to start with.

OK, first off, one hides the dead time of the counter by using the
time-interval mode and use a reference signal such as a PPS or other
suitable rate as start/Channel 1 signal where as the measured signals
goes into stop/Channel 2. That works up to the rate of the counter, and
you don't want to miss samples.

You should also consider what the time resolution you would need. A
HP5372A for instance can do 8000 samples as every 100 ns with 200 ps
resolution for instance. There is more modern counters that do much better.

> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure. But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail. I suspect
> someone will recommend that I get a time-stamping/continuous measurement
> box, which is probably the best solution. But I'm hoping there's a way
> around that in the short term so I can make these measurements sooner.

Well, start with what you have, learn what limits it and then you can
motivate better toys/tools.

That you mention dead-time is refreshing, so you get an extra point
right there, besides asking how to get started.

Now, how much drift do you expect that your oscillators would do? Do you
have a rough idea?

i have done lot's of measurements using a 53131A and hold-over, but
usually the first 10-100 s is relatively easy, but depending on the
details of the lock mechanism it can be more or less "interesting".

Cheers,
Magnus

> 
> 73,
> Dave
> 
> * Others on this list have warned about using this mode because the machine
> does a lot of averaging but it seems like TimeLab needs the box to be in
> this mode regardless. I'm still looking for the part in the manual where
> HP/Agilent/Keysight owns up to this and describe how it changes the
> measurement.
> ___
> time-nuts mailing 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] Cheap jitter measurements

[Hal Murray]

kb...@n1k.org said:
> Somewhere in the NTP algorithm, there is a “zero error” estimate. GPS
> modules have the same thing buried in them. A GPS module (like NTP as
> described above) can only *express* a PPS modulo some clock rate. GPS
> modules get around this with a firmware hack. They simply tell you what the
> error was. It is a simple way to get out of the “I need a 10 GHz clock
> source” problem. No need for FPGA’s or any other guck. You just do an
> estimate and report it. It then would work on any hardware and let you do
> the sort of measurements we’re talking about.

The GPS offset is a kludge to work around not being able to control the local 
oscillator.

> Now - *can* that be done with NTP??  Who knows…. 

The kernel clock has a knob so the same concept doesn't apply.

The API  for the kernel clock can be read to a ns.  I don't see ntpd having 
much use for finer grain than that.  I should look at the source to see what 
the internal details look like.

If ntpd decides the clock needs correcting, it tells the kernel to do the 
work.  The kernel offsets the clock rate knob by 500 PPM, so it takes 2000 
microseconds to adjust the clock by 1 microsecond.  It would be possible to 
read the correction-left and adjust the time by that amount.

I think it would be possible to make similar adjustments by post processing 
the data.  I'd have to double check to make sure I understand what is in 
loopstats.  If now, we could fix it.


-- 
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] Looking for IEEE-488 codes and formats for Datum 9700AT Programmable Time System

[Forrest Christian (List Account)]

Just curious, is there by chance a removable eprom or other programmable
device on these boards?

Assuming a fairly verbose scpi like command interface, I've occasionally
had luck reverse engineering a command set by looking through an eprom dump
for a list of commands?

Also, does this by chance respond to the standard scpi commands like *IDN?
and *TST?

On Mon, Apr 9, 2018, 12:24 PM Bill  wrote:

> I have two of these with 488  interfaces.
> Would appreciate any 488 info you get.
> br...@otelco.net
>
> -Original Message-
> From: Bob kb8tq
> Sent: Saturday, April 07, 2018 10:27 PM
> To: lee...@aol.com ; Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Looking for IEEE-488 codes and formats for Datum
> 9700AT Programmable Time System
>
> Hi
>
> Actually the manual is moot on any sort of remote control. The RS-232
> section refers you to an insert
> in the back of the manual. I’d guess that the 488 stuff was done the same
> way.
>
> Nasty question: Are you sure you have the 488 option installed?  It would
> not be the first piece of gear
> produced that never really got a 488 firmware version …..
>
> Bob
>
> > On Apr 7, 2018, at 11:11 PM, Tom Leedy via time-nuts  >
> > wrote:
> >
> >
> > Hi:
> >
> > I am looking for the IEEE-488 codes and formats for a Datum 9700AT
> > Programmable Time System.  The 9700AT is a 1U time generator and
> > translator with slots in the back that can accept option cards with
> > various functionalities such as -488 and RS-232 interfaces, GPIO, and
> tape
> > searches.  What I need is the character strings to output the time for
> > the -488 interface.  The manual for the unit is here:
> >
> http://www1.symmetricom.com/media/files/support/ttm/product-manual/man-9700at-9710.pdf
> > However, it is silent on the details of the -488 interface.
> >
> > Any help would be appreciated and feel free to contact me offline.
> >
> > Many thanks!
> >
> > Tom Leedy
> > Clarksburg, MD
> >
> >
> > ___
> > time-nuts mailing 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.
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 9, 2018, at 2:19 PM, Achim Gratz  wrote:
> 
> Bob kb8tq writes:
>>> Similarly, the box should be able to give me a pulse at a known time.
>> 
>> how do you set up NTP to do that?
> 
> Not at all, that must be done in the kernel if you want any accuracy at
> all.  But you could modify an existing device driver (for the LPT port)
> to use GPIO instead to give you a PPS out (you'll probably want some
> offset to the true second so it doesn't interfere with the PPS input).
> I think it'd be best to combine a highres timer with some spin-loop to
> keep that PPS pulse closer to the clock (it's been done that way for
> other timing critical stuff before, not really a new idea).  Or, if it's
> only slightly offset from the PPS in anyway, you could piggyback onto
> the PPS reception.
> 
>> In both cases (pulse in and pulse out) the first step is to ask NTP
>> “when was that?”. You still have a pretty big chunk of NTP in the
>> middle of the process …. If NTP only “knows” what is happening (or can
>> control what is happening) to +/- 300 ns. The guts of your data will
>> be limited to the same 300 ns.
> 
> That's not quite how that works.  The resolution theoretically goes down
> to nanoseconds and is ultimately limited by the timer clock.  In the
> case of the rasPi that means about 52ns, but this is swamped by the
> jitter of the interrupt latency.  But you can feed NTP better timestamps
> if you figure out how to get them; on the Beaglebone you can use the RPU
> (Dan Drown has been measuring some latencies that way), on the rasPi you
> could use the VC4 (this is tricky business due to insufficient
> documentation, but the hardware should be capable of scanning the GPIO
> at 250MHz) or even an external TICC.

Somewhere in the NTP algorithm, there is a “zero error” estimate. GPS modules
have the same thing buried in them. A GPS module (like NTP as described
above) can only *express* a PPS modulo some clock rate. GPS modules get
around this with a firmware hack. They simply tell you what the error was. It 
is a
simple way to get out of the “I need a 10 GHz clock source” problem. No need
for FPGA’s or any other guck. You just do an estimate and report it. It then 
would
work on any hardware and let you do the sort of measurements we’re talking 
about.

Now - *can* that be done with NTP??  Who knows….

Bob

> 
> The other option is to use an MCU (or an FPGA) w/ Ethernet and hardware
> timestamping to build a single-purpose NTP stratum-1 box.
> 
> 
> Regards,
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
> 
> SD adaptation for Waldorf rackAttack V1.04R1:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
> ___
> time-nuts mailing 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] Looking for IEEE-488 codes and formats for Datum 9700AT Programmable Time System

[Bill]

I have two of these with 488  interfaces.
Would appreciate any 488 info you get.
br...@otelco.net

-Original Message- 
From: Bob kb8tq

Sent: Saturday, April 07, 2018 10:27 PM
To: lee...@aol.com ; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Looking for IEEE-488 codes and formats for Datum 
9700AT Programmable Time System


Hi

Actually the manual is moot on any sort of remote control. The RS-232 
section refers you to an insert
in the back of the manual. I’d guess that the 488 stuff was done the same 
way.


Nasty question: Are you sure you have the 488 option installed?  It would 
not be the first piece of gear

produced that never really got a 488 firmware version …..

Bob

On Apr 7, 2018, at 11:11 PM, Tom Leedy via time-nuts  
wrote:



Hi:

I am looking for the IEEE-488 codes and formats for a Datum 9700AT 
Programmable Time System.  The 9700AT is a 1U time generator and 
translator with slots in the back that can accept option cards with 
various functionalities such as -488 and RS-232 interfaces, GPIO, and tape 
searches.  What I need is the character strings to output the time for 
the -488 interface.  The manual for the unit is here: 
http://www1.symmetricom.com/media/files/support/ttm/product-manual/man-9700at-9710.pdf

However, it is silent on the details of the -488 interface.

Any help would be appreciated and feel free to contact me offline.

Many thanks!

Tom Leedy
Clarksburg, MD


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



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

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

Re: [time-nuts] Cheap jitter measurements

[Achim Gratz]

Bob kb8tq writes:
>> Similarly, the box should be able to give me a pulse at a known time.
>
> how do you set up NTP to do that?

Not at all, that must be done in the kernel if you want any accuracy at
all.  But you could modify an existing device driver (for the LPT port)
to use GPIO instead to give you a PPS out (you'll probably want some
offset to the true second so it doesn't interfere with the PPS input).
I think it'd be best to combine a highres timer with some spin-loop to
keep that PPS pulse closer to the clock (it's been done that way for
other timing critical stuff before, not really a new idea).  Or, if it's
only slightly offset from the PPS in anyway, you could piggyback onto
the PPS reception.

> In both cases (pulse in and pulse out) the first step is to ask NTP
> “when was that?”. You still have a pretty big chunk of NTP in the
> middle of the process …. If NTP only “knows” what is happening (or can
> control what is happening) to +/- 300 ns. The guts of your data will
> be limited to the same 300 ns.

That's not quite how that works.  The resolution theoretically goes down
to nanoseconds and is ultimately limited by the timer clock.  In the
case of the rasPi that means about 52ns, but this is swamped by the
jitter of the interrupt latency.  But you can feed NTP better timestamps
if you figure out how to get them; on the Beaglebone you can use the RPU
(Dan Drown has been measuring some latencies that way), on the rasPi you
could use the VC4 (this is tricky business due to insufficient
documentation, but the hardware should be capable of scanning the GPIO
at 250MHz) or even an external TICC.

The other option is to use an MCU (or an FPGA) w/ Ethernet and hardware
timestamping to build a single-purpose NTP stratum-1 box.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
___
time-nuts mailing 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] Weird Stuff WareHouse shutting down

[jimlux]

On 4/9/18 5:20 AM, Dave Daniel wrote:
Responding to Jim's post ( I can't find his original post), a 
significant advantage to owning "vintage" instruments is that, in 
general, they may be repaired more easily than later model instruments. 
This fact was my guiding principle when setting up my lab, and that was 
based on Jim Williams' "There's No Place Like Home" article that appears 
as chapter 17 in his book entitled "The Art and Science of Analog 
Circuit Design". The more recent the design of the instrument, the more 
highly integrate is it's circuitry. In many cases, that integration 
manifests itself in the use of VLSI ASICs of one form or another that 
cannot be found, and if one is able to find one to replace a failed 
component, the techniques and tools required to swap it out are 
advanced, perhaps quite advanced. For a corporate enterprise, these 
facilities may be /de rigeur/, but for the home lab, they are, for one 
or more reasons, not feasible and the home lab owner must ship the 
instrument off to some company which can perform the repair or 
calibration at significant cost. I can repair a Tektronix 7104 
oscilloscope. I'm pretty sure I can't repair a Tektronix TDS7104.





This comes up on time-nuts a lot...
(and at work at JPL, because for the most part, we buy equipment, not 
rent it, and the original project ate the whole cost - there's no 
concept of "amortization and depreciaton" - it's just how the govt works)


Yes, the ability to repair is useful, and I'll not deny the pedagogical 
value of older, less "automated" instruments - nothing beats a slotted 
line  (or lecher wires) to understand VSWR, etc.


At JPL we have piles of HP8663 signal generators - a fine piece of gear, 
but all more than 20-25 years old - and they're all slowly dying off. 
Likewise, we have tons of HP portable spectrum analyzers, all with 
screens that are hardly readable. But that creates a problem - we have 
racks of equipment that *depend* on the idiosyncracies of those 8663s, 
and because no project wants to redesign the entire test campaign, we 
keep scrounging to find the last few working ones.


If your time is "free", then the hours it takes to track down a 
replacement transistor with the right properties, solder it in, etc. 
makes it a good deal - *if and only if* you didn't have something else 
more interesting to work on.


I'm fairly busy these days, and while resurrecting test gear was 
something I did when I was younger and poorer, today, I don't think I'd 
make that choice.   I am more interested in making the measurement, than 
in learning more about the innards of 30 year old test equipment.  And 
I'd rather spend my time learning the idiosyncracies of modern 
inexpensive equipment - that $900 SignalHound is a pretty nifty piece of 
gear, even if it is "Windows only" and I have to run a VM to talk to it. 
 Likewise, my $500 Ten-Tec VNA won't go to 50 GHz like the 8510 I used 
to use at work (the one where the sweeper hiccups periodically and locks 
up, and is "not economically repairable), but it's a lot cheaper than a 
FieldFox and serves the need I had for it at the time (measuring mutual 
Z between antennas).

___
time-nuts mailing 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] Weird Stuff WareHouse shutting down

[Bob kb8tq]

Hi

> On Apr 9, 2018, at 9:30 AM, jimlux  wrote:
> 
> On 4/8/18 8:20 PM, Glenn Little WB4UIV wrote:
>> The USB stuff has no front end and stability and calibration is highly 
>> questionable..
> I'm thinking here of the $1K sort of device - traceable cal, quite stable, 
> etc.
> 
> Not the $20 RTL-SDR
> 
> 
>> How can you discriminate between mixes within the USB device and the signal 
>> of interest?
> 
> The same way you can distinguish on a full up analyzer - you change the input 
> attenuator and see if the relative heights of the peaks change.
> 
> 
> 
>> I will take my 141T or my 8566 over USB every time.
>> Rather lug a little weight around and know what I am seeing on the display 
>> is what is really out there.
> 
> A little?
> 
>> There is a reason that usable SAs have weight to them and USB devices do not.
> 
> Monolithic RF ICs have made it possible to get very good performance in a 
> smaller package.
> Your 141T or 8566 have a fair bit of size and mass to run the CRT and user 
> interface.
> 
> To be fair, one should take the size of the computer you're running the 
> USB pod with and add that.
> 
> One thing where the USB pods don't necessarily do as well is on the tunable 
> preselector filters or on the number of attenuator steps.

The reason they can get away with that is their dynamic range. As number of 
real ADC bits goes up, the performance
improves. That was true back when RF ADC’s in spectrum analyzers cost thousands 
of dollars. It is still true today. You
still pay for performance. What you get for $2,000 is not what you get for $20. 
That said, if you are after a device that 
covers the HF to  VHF range, they just keep getting cheaper. There is more 
involved than just the ADC. To do well you
need things like a good clock system. If you happen to be … errr …. frequency 
oriented, the modern stuff locked up 
to a GPSDO can do some amazing things. 

Bob


> 
> 
> I'd have to go look at something like a Keysight/Agilent FieldFox or the 
> Anritsu equivalent to see what sort of front end design they use - for all 
> intents and purposes these are a tablet computer and 2 port VNA/Spectrum 
> Analyzer in one (two)hand-held device.
> 
> 
> 
> 
> 
>> Glenn
>> On 4/8/2018 6:58 PM, Andy ZL3AG via time-nuts wrote:
>>> On 9/04/2018, at 3:52 AM, jimlux wrote:
>>> 
 Test equipment tends to be aged - Unless you have a particular need for a 
 HP 600 series microwave signal generator, there are probably better 
 sources available much cheaper that use more modern components. In this 
 day and age, I don't think people should suffer through 141T spectrum 
 analyzers or even a 8568- Spend your money an a nice USB unit instead.
 
>>> Blasphemy!
>>> 
>>> 
>>> ___
>>> time-nuts mailing 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] ADEV dead time w/ HP 53131A & TimeLab

[Tom Van Baak]

Dave,

> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure.

True. Try a fancy TIA (time interval analyzer) or MDA (modulation domain 
analyzer) instead.

Or consider a high-res (tens of ps) timestamping counter capable of 1000 
samples per second. The Pendulum CNT-91 may work. Also look into the Agilent 
53230A which has a zero deadtime timestamping mode. The venerable SR620 is also 
capable of 1 kHz measurement rate, but I'm not sure if that's internal sampling 
or sustained data rate via GPIB. The TICC (designed by JohnA, distributed by 
TAPR) would also work to 1 kHz sampling if you rewrote the Arduino code.

What kind of oscillator is it that you're trying to measure? Pendulum? Tuning 
fork? TCXO? Some SiLabs thing? That may make a huge difference in the type of 
gear you need or the measurement model.

What timing resolution do you need at 1 ms sampling rates?


> But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail.

If zero dead time is important then make single-shot time interval measurements 
instead of using frequency or period mode. I do almost all my GPS/1PPS logging 
that way, using a 53131A like yours. But, as you surmise, you don't get 
anywhere near a 1 kHz sampling rate.


> I'm still looking for the part in the manual where
> HP/Agilent/Keysight owns up to this and describe how it changes the
> measurement.

By now there's a lot of literature, both marketing and technical, that 
describes in detail how regression-based frequency counters work. The 53131A 
was designed in the 90's before that literature was written.

There's a key footnote in the manual from which you can infer all of this. For 
a summary see this posting, and the GIF:
https://www.febo.com/pipermail/time-nuts/2013-August/079647.html

Also if you look at the specifications pages (e.g., under RMS resoluion) you'll 
see a more explicit reference to the counter making 200,000 measurements per 
second. Putting all this together it's clear this counter does precise 
single-shot time measurements (compatible with ADEV) but it does 
regression-based frequency/period measurements, which may or may not be 
perfectly compatible with ADEV.

/tvb

- Original Message - 
From: "David Burnett" 
To: 
Sent: Sunday, April 08, 2018 6:29 PM
Subject: [time-nuts] ADEV dead time w/ HP 53131A & TimeLab


> Hi time-nuts,
> 
> I'm doing oscillator-related research for my PhD and found this list
> recently. It's been a great resource in trying to refine my freq
> measurement setup and in starting to understand what's really going on
> inside my lab equipment.
> 
> I've been trawling the archives and have a question about measuring ADEV
> accurately with the Agilent 53131A frequency counter I have on hand. From
> the comments on this list and elsewhere, and the fact that TimeLab will
> talk to my 53131A directly, I have the impression one can use the 53131A
> for period measurements with which to calculate ADEV. But from GPIB command
> sniffing it looks like there's a lot of dead time between measurements:
> -- In period or freq mode* measurements take an extra ~130ms longer than
> gate time to return (but this seems to produce the correct measurements for
> TimeLab);
> -- in time interval mode they take about ~20ms;
> -- in totalize mode they take about 5ms, in keeping with "200 measurements
> per second" advertised in the brochure, but of course this is a simple
> counter and one loses the resolution of a reciprocal counter or anything
> smarter added in.
> 
> Is it just generally assumed everyone is making period measurements on time
> scales long enough that any instrument dead time is ignorable? Or is
> TimeLab and everyone else silently applying the correction factor as
> described by the Barnes & Allan NIST paper (NIST technical note 1318)? Or
> is there a configuration mode I'm missing that prints measurements with
> more regularly? TimeLab's GPIB commands seem to be limited to "get current
> measurement" so I might not have the box set up right to start with.
> 
> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure. But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail. I suspect
> someone will recommend that I get a time-stamping/continuous measurement
> box, which is probably the best solution. But I'm hoping there's a way
> around that 

Re: [time-nuts] Weird Stuff WareHouse shutting down

[jimlux]

On 4/8/18 8:20 PM, Glenn Little WB4UIV wrote:
The USB stuff has no front end and stability and calibration is highly 
questionable..
I'm thinking here of the $1K sort of device - traceable cal, quite 
stable, etc.


Not the $20 RTL-SDR


How can you discriminate between mixes within the USB device and the 
signal of interest?


The same way you can distinguish on a full up analyzer - you change the 
input attenuator and see if the relative heights of the peaks change.





I will take my 141T or my 8566 over USB every time.
Rather lug a little weight around and know what I am seeing on the 
display is what is really out there.


A little?

There is a reason that usable SAs have weight to them and USB devices do 
not.


Monolithic RF ICs have made it possible to get very good performance in 
a smaller package.
Your 141T or 8566 have a fair bit of size and mass to run the CRT and 
user interface.


To be fair, one should take the size of the computer you're running 
the USB pod with and add that.


One thing where the USB pods don't necessarily do as well is on the 
tunable preselector filters or on the number of attenuator steps.



I'd have to go look at something like a Keysight/Agilent FieldFox or the 
Anritsu equivalent to see what sort of front end design they use - for 
all intents and purposes these are a tablet computer and 2 port 
VNA/Spectrum Analyzer in one (two)hand-held device.








Glenn


On 4/8/2018 6:58 PM, Andy ZL3AG via time-nuts wrote:

On 9/04/2018, at 3:52 AM, jimlux wrote:

Test equipment tends to be aged - Unless you have a particular need 
for a HP 600 series microwave signal generator, there are probably 
better sources available much cheaper that use more modern 
components. In this day and age, I don't think people should suffer 
through 141T spectrum analyzers or even a 8568- Spend your money an a 
nice USB unit instead.



Blasphemy!


___
time-nuts mailing 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] Cheap jitter measurements

[Bob kb8tq]

Hi

> On Apr 9, 2018, at 2:53 AM, Trevor N.  wrote:
> 
> Bob kb8tq wrote:
>> Hi
>> 
>> Without the ability to put out a “known good” time pulse there is no quick 
>> way to 
>> check NTP. GPS modules suffer a similar issue. They put out a pulse and a 
>> “correction” (sawtooth error) to tell you what they just told you. Doing the 
>> same 
>> sort of thing with NTP may be possible. 
>> 
>> Indeed the process of correcting this sort of data is open to a bit of 
>> debate. It does 
>> give you a way to get around the “hey, all I can do is 300 ns” issue. With 
>> GPSDO’s
>> the correction is part of the standard firmware. It would be nice if one of 
>> the NTP 
>> guru’s popped up with an equivalent process. 
>> 
>> One *could* monitor various bits and pieces of the OS’s timing generation 
>> system. 
>> Somehow that does not seem quite as much fun as looking at the whole result 
>> all
>> at once. Indeed it might be the only way to get it all worked out.
>> 
>> Bob
> 
> Linux has a pps output driver (pps_gen_parport), but  I've never used
> it. A while back  I added an output mode to the Linux pps_parport
> driver: 
> https://github.com/retroman/pps_parport_polled 
> that I will eventually get around to using with the palisade(trimble)
> NTP driver.
> 
> My modified driver's polled input mode has an input-to-echo delay of
> 1.16 to 1.93 microseconds (measured with an old Keithley 775 counter)
> on my machine which has a parallel card attached directly to the pci-e
> port on a sandybridge processor.  Interrupt mode echo delay is 3.8 to
> 4.3 microseconds when the machine is lightly loaded with occasional
> spikes of 5 to 7 us. When the machine is idle delay falls to
> 3.5-4.1us.
> Port read and write delays are equal at about 820ns each. I think that
> pci-express always uses 'split transactions'  so reads can sometimes
> seem to take only half the time depending on the input pulse time
> relative to the start time of a read request.  Delays increase to
> ~1200ns when attached to the chipset pcie ports.

Does NTP generate a “correction” output that tells you when it things the 
pps went out? If the pps is just coming off the clock architecture, it will 
show you part of what’s going on, but not all of it.

Bob

> ___
> time-nuts mailing 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] Weird Stuff WareHouse shutting down

[Dave Daniel]

Responding to Jim's post ( I can't find his original post), a 
significant advantage to owning "vintage" instruments is that, in 
general, they may be repaired more easily than later model instruments. 
This fact was my guiding principle when setting up my lab, and that was 
based on Jim Williams' "There's No Place Like Home" article that appears 
as chapter 17 in his book entitled "The Art and Science of Analog 
Circuit Design". The more recent the design of the instrument, the more 
highly integrate is it's circuitry. In many cases, that integration 
manifests itself in the use of VLSI ASICs of one form or another that 
cannot be found, and if one is able to find one to replace a failed 
component, the techniques and tools required to swap it out are 
advanced, perhaps quite advanced. For a corporate enterprise, these 
facilities may be /de rigeur/, but for the home lab, they are, for one 
or more reasons, not feasible and the home lab owner must ship the 
instrument off to some company which can perform the repair or 
calibration at significant cost. I can repair a Tektronix 7104 
oscilloscope. I'm pretty sure I can't repair a Tektronix TDS7104.


DaveD

On 4/8/2018 4:58 PM, Andy ZL3AG via time-nuts wrote:

On 9/04/2018, at 3:52 AM, jimlux wrote:


Test equipment tends to be aged - Unless you have a particular need for a HP 
600 series microwave signal generator, there are probably better sources 
available much cheaper that use more modern components. In this day and age, I 
don't think people should suffer through 141T spectrum analyzers or even a 
8568- Spend your money an a nice USB unit instead.


Blasphemy!


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




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap jitter measurements

[David J Taylor via time-nuts]

There is a program for the RPi which handles the PPS input for NTP and can 
produce an output on a GPIO pin here:


 https://vanheusden.com/time/rpi_gpio_ntp/

but it's user-mode so of limited use.  Perhaps the OP could adapt it?

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


___
time-nuts mailing 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] Cheap jitter measurements

[Trevor N .]

Bob kb8tq wrote:
>Hi
>
>Without the ability to put out a “known good” time pulse there is no quick way 
>to 
>check NTP. GPS modules suffer a similar issue. They put out a pulse and a 
>“correction” (sawtooth error) to tell you what they just told you. Doing the 
>same 
>sort of thing with NTP may be possible. 
>
>Indeed the process of correcting this sort of data is open to a bit of debate. 
>It does 
>give you a way to get around the “hey, all I can do is 300 ns” issue. With 
>GPSDO’s
>the correction is part of the standard firmware. It would be nice if one of 
>the NTP 
>guru’s popped up with an equivalent process. 
>
>One *could* monitor various bits and pieces of the OS’s timing generation 
>system. 
>Somehow that does not seem quite as much fun as looking at the whole result all
>at once. Indeed it might be the only way to get it all worked out.
>
>Bob

Linux has a pps output driver (pps_gen_parport), but  I've never used
it. A while back  I added an output mode to the Linux pps_parport
driver: 
https://github.com/retroman/pps_parport_polled 
that I will eventually get around to using with the palisade(trimble)
NTP driver.

My modified driver's polled input mode has an input-to-echo delay of
1.16 to 1.93 microseconds (measured with an old Keithley 775 counter)
on my machine which has a parallel card attached directly to the pci-e
port on a sandybridge processor.  Interrupt mode echo delay is 3.8 to
4.3 microseconds when the machine is lightly loaded with occasional
spikes of 5 to 7 us. When the machine is idle delay falls to
3.5-4.1us.
Port read and write delays are equal at about 820ns each. I think that
pci-express always uses 'split transactions'  so reads can sometimes
seem to take only half the time depending on the input pulse time
relative to the start time of a read request.  Delays increase to
~1200ns when attached to the chipset pcie ports.
___
time-nuts mailing 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] Weird Stuff WareHouse shutting down

[Hal Murray]

drkir...@kirkbymicrowave.co.uk said:
> I think people learn more with old test equipment.  I know someone who has a
> 1 GHz LeCroy scope,  as well as a high end Agilent, but can't seem to
> measure the simplest of signals, that I could easily measure with a 50 year
> old scope. 

With modern scopes, you just push the button.  1/2 :), but the one on my 
Rigol scope is labeled "Auto".


Many years ago, my boss used to use a scope when interviewing technicians: 
scramble the knobs, then watch how they sort things out.


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